Ein Programmierer, der über Code spricht
Tom schreibt hier, leidenschaftlicher Entwickler für alles, was mit Web und Native zu tun hat. Viele Monde sind vergangen, seit ich angefangen habe, ein paar Zeilen Code zu schreiben. Ein glorreicher „Hello World“-Moment war, und seitdem habe ich viele weitere Zeilen mit viel mehr Code geschrieben, von Echtzeit-Warnsystemen, medizinischen Anwendungen, die Ärzte bei ihren täglichen Aufgaben unterstützen, bis hin zu Multi-Plattform-Meeting-&- Terminverwaltungssoftware. Ich habe dabei auch einiges gelernt, und heute möchte ich einen Aspekt des Codierens teilen, der möglicherweise nicht immer so viel Aufmerksamkeit erhält, insbesondere in schwierigen Zeiten in der Mitte des Projekts. Sprechen wir über die Verantwortung eines Programmierers oder, um genau zu sein, über das Code-Erbe eines Programmierers.
Die Pyramiden von Javascript
Die Aufgabe eines Architekten besteht nicht nur darin, den Grundriss eines Neubaus, die Formen von Wänden, Fenstern und Türen oder die Ausrichtung des Hauses proportional zur Mittagssonne zu definieren. Unter all diesen Dingen weiß der Architekt, dass das Gebäude jahrelang aushalten muss, dass es einer brutalen Natur von starken Winden, starken Regenfällen, kühlen Wintern und heißen Sommern standhalten muss. Oberstes Ziel der Arbeit des Architekten ist es, den Bewohnern des Gebäudes ein sicheres Zuhause zu bieten. Es geht um die Langlebigkeit seiner oder ihrer Arbeit. Alles dreht sich um sein Erbe.
In der Softwareentwicklung geht es in der Regel sehr schnell, insbesondere bei der Arbeit in Startups. Es ist wichtig, neue Funktionen schnell bereitzustellen, auf dem Markt Fuß zu fassen und die Benutzer zu motivieren. Der Fokus während der Entwicklung beschränkt sich in der Regel auf den aktuellen Sprint oder die schnellstmögliche Implementierung dieser einen Funktion mit hoher Priorität.
Doch beim Codieren sollte es nicht darauf beschränkt sein, dass die Tests grün leuchten oder nur die Frist erreicht werden muss. Einmal in freier Wildbahn werden Anwendungen von Menschen genutzt, die sich für ihren Arbeitsalltag auf sie verlassen können. Das Programm, das ich heute baue, ist das Vermächtnis, das ich morgen hinterlasse.
Nehmen wir das Web als Beispiel: Es war noch nie so einfach, über NPM Komponenten zu finden, die die Funktionalität bieten, nach der ich gerade suche. Sie sind schnell installiert und mit dem Rest der Codebasis verbunden. Aber wenn es um die Langlebigkeit meiner Anwendung geht, können Abhängigkeiten von Drittanbietern den gesamten Update-Prozess stoppen, b/c aktualisieren, dass eine Abhängigkeit eine andere daran hindert, zu funktionieren. Es ist ein Balanceakt, zu entscheiden, was ich selbst implementieren, forken oder direkt aus einem Paketmanager installieren möchte.
Code von Drittanbietern kann jedoch in Ordnung sein. Es ist wichtig, einige Faktoren zu überprüfen, bevor Sie die Bibliothek oder das Framework verwenden: Wie gut war die Wartung in der Vergangenheit, wie viele aktive Beiträge gibt es jetzt, ist eine Roadmap verfügbar, die zukünftige Änderungen oder Verbesserungen skizziert, wird das Paket vollständig von der Community verwaltet oder unterstützt von Sponsoren, die bei der Entwicklung helfen?
Wenn ich von externem Code zu meiner eigenen Codebasis übergehe, muss ich mich ständig daran erinnern, während der Entwicklung keine Abstriche zu machen, um ein Ziel schneller zu erreichen. So verlockend es auf kurze Sicht auch sein mag, schlecht geplanter Code wird sich rächen und zurückbeißen. Wenn Sie mehr über Code nachdenken, als ihn zu schreiben, können Sie viele Probleme mildern. Ein Schlüsselfaktor ist hier sicherlich Erfahrung, aber auch Junior-Entwickler sollten die Bedeutung von wartbarem Code von Anfang an verstehen. Was jetzt zu Fehlern führt, wird möglicherweise aufgrund von Projektzeitplänen nie behoben und nur durch Workarounds gelöst, was entweder zu unordentlichem Code, schlechter Benutzererfahrung oder beidem führt.
Mentalität des Maschinisten
Ein weiterer Aspekt des durchdachten Codierens, über den ich schreiben möchte, ist die Zielgruppe einer Anwendung, der Benutzer. Während ich von 9 bis 5 vor dem Bildschirm meines elektrischen Rechenlineals sitze, Codezeilen durchpflüge und mich auf das Thema konzentriere, das mir zugewiesen wurde, ist es schwer zu bedenken, dass meine ganze Arbeit letztendlich von jemandem verwendet werden, der es während der täglichen Arbeit teilweise oder vollständig verwendet. Und es spielt keine Rolle, ob ich eine App für Nicht-Techniker oder APIs für andere Entwickler entwickle – die Dinge, die ich baue, müssen ergonomisch in der Verwendung sein.
Ich weiß aus eigener Erfahrung, dass Benutzer auf seltsame und meist unerklärliche Weise mit Ihrer App interagieren können. Ich als Ersteller neige dazu, „unbeabsichtigtes“ Verhalten meines Dienstes abzulehnen, umso mehr, wenn ich bereits viel Zeit und Energie darin investiert habe. Dabei spielt es eine Schlüsselrolle, das tatsächliche, reale Nutzungsverhalten des Publikums zu verstehen, wenn ich beim Empfang von Feedback einen ruhigen Geist behalte und mich gegebenenfalls dazu zwingen muss, ihm zuzuhören.
Wir als Entwickler leben in einer Welt der Ordnung und Einheitlichkeit beim Codieren, in der eine besondere Art von Physik und Gravitation gilt und wir alle Regeln kennen. Es ist eine Welt, die wir umarmen und vollständig in sie eintauchen können, da wir ihre Schöpfer und Bewohner sind. Aber wenn man Feedback, d.h. Kritik von außerhalb dieser Welt, sieht, führt dies normalerweise zu einer Ablehnung durch Entwickler. Der Umgang mit Anwenderberichten und Optionen muss erlernt und als relevanter Input für die Entwicklung gewertet werden. Es ist eine Lektion, die ich gelernt habe, und es hilft in jeder Phase des Projekts enorm, offen für Veränderungen und Feedback zu sein.
process.exit();
Zusammenfassend sollten Sie nicht nur an den Code denken, den Sie heute schreiben, sondern auch an den, den die Leute in den kommenden Jahren verwenden werden. Treffen Sie überlegte Entscheidungen hinsichtlich der Verwendung externer Codepakete sowie der Struktur und Implementierung des Projekts, sodass das Endprodukt ergonomisch und effizient verwendet werden kann und den tatsächlichen Bedarf der Zielgruppe widerspiegelt. Das Verständnis von Feedback ist der Schlüssel und trägt wesentlich dazu bei, ein Qualitätsprodukt zu liefern, auf das man stolz sein kann.
- Tom
