Get best of the week

Was ich bei der Arbeit an meinem ersten Großprojekt gelernt habe

Vor acht Monaten begann ich, eine Anwendung auf Electron zu schreiben. Um diese Aufgabe zu meistern, musste ich drei separate Unteranwendungen entwickeln, die in verschiedenen Umgebungen ausgeführt werden. Im Folgenden werde ich darüber sprechen, was ich mir auf dem Weg gemacht habe.



Binder in seiner ursprünglichen Form

Kontext


Bevor ich mich mit den Details befasse, werde ich zunächst einige allgemeine Informationen bereitstellen, die zum Verständnis der Situation erforderlich sind. Anfang 2019 begann ich, nach einem Praktikum zu suchen, wie es das Koop-Programm für meinen Abschluss vorschreibt. Bis April habe ich Dutzende von Lebensläufen verschickt, von denen jeder auf einen bestimmten Arbeitgeber zugeschnitten war, und insgesamt genau null Antworten erhalten. Sie können sich vorstellen, wie ich darauf reagiert habe - meine Hände sanken, es schien, als wäre ich für nichts geeignet und überhaupt keine Arbeit wert. Aber anstatt diese Gefühle überwiegen zu lassen, habe ich mich entschlossen, mir selbst zu beweisen, dass ich noch etwas weiß und mich für einige Stellen bewerben kann. Am Ende fand ich heraus, dass ich tatsächlich weniger weiß als ich erwartet hatte.

Ich begann meine Projekte zu überarbeiten, um eines zu finden, das sich in etwas Großes und Komplexes verwandeln lässt, das mich anspornen könnte. Schließlich habe ich mich für Binder entschieden - damals eine einfache Webanwendung, mit der Sie Dateien von Onedrive, Google Drive und Dropbox gleichzeitig verwalten konnten. Ziel war es, einen Sicherungsdienst zu entwickeln, dessen Funktionalität mit dieser Dreifaltigkeit vergleichbar ist, abzüglich der Möglichkeit, Dateien an andere Benutzer zu übertragen.

Der Anfang des Weges


Wahrscheinlich hätte ich das Projekt überhaupt nicht abgeschlossen, wenn ich mir nicht von Anfang an einige Wahnziele gesetzt hätte. Der erste Meilenstein, den ich für mich selbst festgelegt habe, war die Erstellung einer funktionierenden Alpha-Version zu meinem Geburtstag, die ich Mitte Juli feiere. Ich habe sofort mit der Arbeit begonnen. Anfang Mai erstellte ich einen Binder-Klon und begann, ihn in Teile zu zerlegen, wodurch viele Funktionen weggeworfen wurden, die ich nicht mehr benötigte. Im Allgemeinen habe ich eine völlig anständige Anwendung genommen und sie irgendwo auf Tutorial-Ebene in einen einfachen Code umgewandelt.

Ich habe mich für die Tatsache entschieden, dass ich vier separate Bewerbungen schreiben werde. Der erste ist ein Client, der nativ auf dem Computer des Benutzers funktioniert. Die zweite ist eine API mit einem Backend, die das Senden sicherer Anforderungen erleichtert. Drittens der Cloud-Dienst, der für die Integrität aller darauf gespeicherten Daten verantwortlich ist. Und schließlich eine "Marketing" -Webseite, denn ein Produkt kann nicht ohne eine schimmernde Website auskommen.

Und jetzt beginnt der Spaß


Gut, gut, gut, ich gebe zu: Alles, was ich bisher gesagt habe, hat nichts mit Electron zu tun, geschweige denn mit der Entwicklung von Großanwendungen. Aber ich musste den Kontext klären, damit Sie verstehen, woher ich mein Wissen habe. Hier sind fünf wichtige Lektionen, die ich für mich selbst gelernt habe:

# 1 Verwenden Sie unbedingt traditionelle Strukturen für das Frontend und das Backend, da die Kommunikation zwischen Prozessen eine dumme Sache ist

Öfter als ich möchte, bin ich ausgeflippt, weil primitive Interprozesskommunikation in Electron (und jetzt wieder in Psycho) implementiert ist. Ja, die Interprozesskommunikation ist überhaupt nicht dafür ausgelegt, eine Datenabstraktion im Sinne von Javascript durchzuführen, mit der Darstellung von Funktionen als Objekte und so weiter. Aber wie viel einfacher wäre es! Anstatt eine minimalistische Client-Anwendung zu erstellen, während sich das Haupt-Code-Array im Hauptprozess befand, musste ich klar trennen, was mit dem Benutzer interagiert und was nicht. Das Kriterium, anhand dessen ich festlegte, was in den Hauptprozess und was in den Renderprozess einfließen würde, wurde als einfache Frage formuliert: Dient dieser Code irgendetwas? Die Fragmentgröße spielte keine Rolle. Wenn er andere Codestücke bediente,ging dann zum Hauptprozess. Die einzige Ausnahme war der Endpunkt des Stripe-Zahlungssystems. Aus Sicherheitsgründen wollte ich, dass es so nah wie möglich am Benutzer liegt.

№2 Die Aufrechterhaltung der Integrität von Daten ist sehr, sehr schwierig.

Bis ich mit der Arbeit an Binder begann, verstand ich nicht, wie schwierig es war, sicherzustellen, dass alle Daten, die von einer beliebigen und beeindruckenden Anzahl von Benutzern stammen, immer korrekt und zugänglich waren. Und nur eine sichere Speicherung für sie bereitzustellen, ist keine leichte Aufgabe, aber jetzt soll ich trotzdem alles validieren und sicherstellen, dass es keine Widersprüche zu anderen Daten gibt, ohne eine Ahnung zu haben, was die Daten sind ?!

Natürlich übertreibe ich hier ein wenig, aber das Wesentliche des Problems ist nicht verzerrt. Die Validierung sollte so früh wie möglich in den frühesten Stadien erfolgen und dann wiederholt werden (in bescheidenerem Umfang), wenn der Datenstrom voranschreitet. Die Aufrechterhaltung der Konsistenz wird einfacher, wenn Sie bei jeder Änderung der Daten ein Transaktionsmodell verwenden. Um ehrlich zu sein, gibt es neben den Daten selbst auch eine Vielzahl von Metadaten, die nicht viel einfacher zu verwalten sind. Es schien immer eine gute Idee zu sein, eine Funktion zu schreiben, die Benutzerdaten liest und dann Integritätsprüfungen durchführt. Aber nach langem Überlegen kam ich zu dem Schluss, dass sich die geheimen Eingänge nicht von den Eingangstüren unterscheiden - der ganze Unterschied besteht darin, wer sie benutzt.

Nr. 3 Schnittstellen - wie Schuhe, die auf Bestellung genäht werden



Eine großartige Möglichkeit, eine schöne, gut funktionierende Benutzeroberfläche zu erstellen, besteht darin, sie als ein Paar individueller Schneiderschuhe zu betrachten (oder als Anzug, der auf die Form zugeschnitten ist, spielt keine Rolle). Die erste Frage, die ich mir stellte, als ich mit dem Design für Binder begann: Wer wird sich die Anwendungsoberfläche ansehen? Hinweis: Ich habe nicht darüber gesprochen, wer die Schnittstelle verwenden wird. Dies sollte die zweite Frage sein, da alles genau an das Aussehen gebunden ist. In der Vergangenheit habe ich viele Projekte durchgeführt, und ich kann Ihnen mit vollem Vertrauen sagen: Die Leute wollten auf Ihre Bewerbung spucken, wenn sie nicht so aussieht, wie sie sollte.



Ich begann damit, kleine Entwürfe in einem Notizbuch zu machen (mit einem Kugelschreiber, weil ich die Gewohnheit habe, ständig an meinen Ideen zu zweifeln). In den ersten Entwürfen lag der Schwerpunkt auf der allgemeinen Struktur der Benutzeroberfläche, und erst dann habe ich im weiteren Verlauf detailliert beschrieben, wie jede der „Seiten“ aussehen sollte. Meiner Meinung nach sind die präsentierten Informationen nicht so wichtig wie ihre Lesbarkeit.

Nr. 4 Es gibt nicht viel Fehlertoleranz

Ich weiß nichts über dich, aber ich von dem Gedanken, dass die API abstürzen wird, nachdem ich die Zahlung akzeptiert habe, bricht ein kalter Schweiß durch. Als ich anfing, am Zahlungssystem zu arbeiten, sagte ich mir: "Jetzt können Sie es sich nicht leisten, einen einzigen Fehler zu verpassen." Ich habe sichergestellt, dass während des gesamten Prozesses Sicherheitsmechanismen implementiert werden: von dem Moment an, in dem die API eine Anforderung zum Kauf eines Servicepakets erhält, bis Stripe die Zahlungsinformationen an das Ereignisbenachrichtigungssystem weiterleitet und das Paket aktiviert wird. Diese Art von Paranoia verlangsamt natürlich den Entwicklungsprozess, aber ich bereue nichts. Ich habe jedoch immer vollständige Informationen darüber, wann die Zahlung eingegangen ist, welchen Zweck sie hat und welchen Status die Maßnahmen haben, die darauf folgen sollen.

Nr. 5 Nicht perfekt? Nicht beängstigend

Ich bin ein Perfektionist, und meine Versuche, etwas Atemberaubendes zu erschaffen, geraten oft außer Kontrolle und führen zu endlosen Nitpicking-Aktionen in jeder Codezeile und bezweifeln, ob sie ein Existenzrecht haben. Ich muss immer wieder mit mir selbst kämpfen, was noch wichtiger ist - Effizienz oder Lesbarkeit. In den ersten Monaten hatte ich mein Sehvermögen noch nicht erhalten und verstand nicht, dass vieles, wofür ich Energie aufgewendet habe, tatsächlich keinen praktischen Nutzen hat - es geht darum, ein Produkt herzustellen, das mit einem ruhigen Geist verwendet werden kann und nicht verletzt wird für eine prestigeträchtige Auszeichnung. Es ist lustig, dass meine fünfte Lektion teilweise gegen die vierte geht, aber es ist sogar gut. Die vierte Lektion erinnert mich an Vorsicht und Aufmerksamkeit für die Erwartungen der Benutzer, und die fünfte setzt Grenzen, damit ich nicht hängen bleibe.eine Funktion endlos verbessern.

Bevor wir uns verabschieden


Sie haben meinen Artikel bis zum Ende gelesen und möglicherweise bemerkt (gut oder nicht), dass Binder noch nicht voll funktionsfähig ist. Zum Zeitpunkt des Schreibens veröffentlichte ich gerade die erste öffentliche Version (Beta 4). Ich bin nicht besonders geneigt, Binder in ein vollwertiges Produkt zu verwandeln, habe es aber dennoch so entwickelt, dass es wie eine normale Anwendung funktioniert - plötzlich werden Ambitionen von mir übernommen. Eine schillernde Webseite kann hier bewundert werden .

Alles, was ich für Open Access für sicher hielt, wurde auf der Projektseite von GitHub veröffentlicht. Dort werde ich Updates veröffentlichen (und dort können Sie den Client herunterladen, damit er sich selbst aktualisiert). Ah, nun, hier sind die Statistiken, die ich für vier Unteranwendungen zusammengestellt habe, um meiner Eitelkeit zu schmeicheln:

Binder-Local (Client auf Electron)



Binder-Web (hübsche Webseite)



In den verbleibenden beiden Fällen habe ich aus Sicherheitsgründen nicht automatisch mit dem Zählen von Codezeilen begonnen.

Binder api

  • JavaScript: 21 Dateien, 4117 Zeilen
  • Andere Dateien: ~ 150 Zeilen

Binder-Mongo (Dienst zur Überprüfung der Integrität)

  • JavaScript: 16 Dateien, 2374 Zeilen
  • Andere Dateien: ~ 140 Zeilen

Gesamtzahl der Codezeilen: 30.015

More articles:


All Articles