5 Schritte zum Programmieren für den nächsten Entwickler

Die meisten von uns denken wahrscheinlich nicht an den Entwickler, der unseren Code verwalten wird. Bis vor kurzem habe ich das auch nicht getan. Ich habe nie absichtlich unverständlichen Code geschrieben, aber ich habe auch nie Hinweise hinterlassen.

Kent Beck über gute Programmierer:

Jeder Narr kann Code schreiben, den ein Computer verstehen kann. Gute Programmierer schreiben Code, den Menschen verstehen können.

Douglas Crockford über gute Computerprogramme:

Es läuft alles auf Kommunikation und die Strukturen hinaus, die Sie verwenden, um diese Kommunikation zu erleichtern. Menschliche Sprache und Computersprachen funktionieren in vielerlei Hinsicht sehr unterschiedlich, aber letztendlich beurteile ich ein gutes Computerprogramm nach seiner Fähigkeit, mit einem Menschen zu kommunizieren, der dieses Programm liest. Auf dieser Ebene sind sie also nicht so unterschiedlich.

Die Entdeckung von Zweck und Absicht ist auch im besten geschriebenen Code schwierig. Alle Hinweise, die der Autor hinterlässt – Kommentare, aussagekräftige Benennungen und Konsistenz – sind für die nächsten Entwickler immens hilfreich.

Ich beginne damit, nach Mustern zu suchen. Muster können an vielen Orten gefunden werden, einschließlich Variablennamen, Klassenlayout und Projektstruktur. Einmal identifiziert, sind Muster Einblicke in die Absicht des vorherigen Entwicklers und helfen beim Verständnis des Codes.

Was ist ein Muster? Ein Muster ist eine wiederholbare Lösung für ein wiederkehrendes Problem. Betrachten Sie eine Tür. Wenn ein Raum Menschen eintreten und verlassen lassen muss und gleichzeitig Isolation bewahren soll, wird das Türmuster implementiert. Das scheint offensichtlich, aber es war nicht immer so. Jemand hat das Türmuster erstellt, das die Türklinke, die Scharniere und die Platzierung dieser Komponenten umfasste. Betreten Sie ein beliebiges Haus und Sie können jede Tür und ihre Komponenten identifizieren. Die Stile und Farben können unterschiedlich sein, aber die Komponenten sind gleich. Software ist dasselbe.

Es gibt bekannte Softwaremuster für häufige Softwareprobleme. 1995 wurde „Design Patterns: Elements of Reusable Object-Oriented Software” veröffentlicht, das häufige Softwaremuster beschreibt. Dieses Buch beschreibt häufige Probleme, die in den meisten Softwareanwendungen auftreten, und bietet eine elegante Lösung für diese Probleme. Entwickler erstellen auch ihre eigenen Muster bei der Lösung von Problemen, auf die sie regelmäßig stoßen. Obwohl sie kein Buch veröffentlichen, können Sie sie identifizieren, wenn Sie genau hinschauen.

Manchmal ist es schwierig, die Muster zu identifizieren. Dies macht das Verständnis des Codes schwierig. Wenn Sie sich in dieser Situation befinden, untersuchen Sie den Code und sehen Sie, wie er verwendet wird. Beginnen Sie einen Neuschreiben. Fragen Sie sich selbst, wie Sie das gleiche Ergebnis erreichen würden. Oft gewinnen Sie beim Durchlaufen des Gedankenprozesses eines Algorithmus Einblick in die Implementierung des anderen Entwicklers. Viele von uns haben die Neigung, das umzuschreiben, was wir nicht verstehen. Widerstehen Sie diesem Drang! Die bestehende Implementierung ist kampferprobt und Ihre nicht.

Einiger Code ist einfach ärgerlich, wenden Sie sich an einen Kollegen – ein zweites Augenpaar hilft immer. Gehen Sie den Code zusammen durch. Sie werden überrascht sein, was die beiden von Ihnen finden werden.

Hier sind 5 Tipps zum Hinterlassen von Hinweisen für die nächsten Entwickler

1. Muster
Verwenden Sie bekannte Muster, erstellen Sie Ihre eigenen Muster. Bleiben Sie bei einem konsistenten Paradigma im gesamten Code. Zum Beispiel sollten Sie nicht 3 Ansätze zum Datenzugriff haben.

2. Konsistenz
Dies ist bei weitem der wichtigste Aspekt der Codierung. Nichts ist frustrierender als inkonsistenter Code. Konsistenz ermöglicht Annahmen. Jedes Mal, wenn ein bestimmtes Softwaremuster auftritt, sollte angenommen werden, dass es sich ähnlich wie andere Instanzen des Musters verhält.

Inkonsistenter Code ist ein Albtraum. Stellen Sie sich vor, Sie lesen ein Buch, in dem jedes Wort etwas anderes bedeutet, einschließlich desselben Wortes an verschiedenen Stellen. Sie müssten jedes Wort nachschlagen und große Mengen mentaler Energie aufwenden, um die Absicht zu entdecken. Es ist frustrierend, mühsam und schmerzhaft. Sie werden verrückt! Tun Sie das nicht dem nächsten Entwickler an.

3. Aussagekräftige Benennungen
Dies ist Ihre Sprache. Dies sind die Worte zu Ihrer Geschichte. Weben Sie sie gut.

Dies umfasst Klassennamen, Methodennamen, Variablennamen, Projektnamen und Eigenschaftsnamen.

Nicht so:

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

So:

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

Das erste Beispiel hat 3 hartcodiert in der if-Anweisung. Dieser Code ist syntaktisch korrekt, aber die Absicht der Zahl 3 sagt Ihnen nichts. Wenn Sie sich die Eigenschaft ansehen, gegen die sie ausgewertet wird, können Sie vermuten, dass es wirklich 3 Stunden sind. In Wirklichkeit wissen wir es nicht. Wir machen eine Annahme.

Im zweiten Beispiel setzen wir 3 auf eine Variable namens „feedInterval”. Die Absicht wird klar im Variablennamen angegeben. Wenn seit der letzten Mahlzeit 3 Stunden vergangen sind, ist es Zeit, den Affen zu füttern. Ein Nebeneffekt des Setzens der Variablen ist, dass wir das Fütterungsintervall jetzt ändern können, ohne die Logik zu ändern.

Dies ist ein konstruiertes Beispiel, aber in einem großen Softwareteil ist dieser Code selbstdokumentierend und hilft dem nächsten Entwickler, den Code zu verstehen.

4. Kommentare
Kommentare sind ein zweischneidiges Schwert. Zu viele Kommentare erhöhen die Wartungskosten, zu wenige lassen Entwickler unsicher, wie der Code funktioniert. Eine allgemeine Faustregel ist, zu kommentieren, wenn der durchschnittliche Entwickler den Code nicht versteht. Dies geschieht, wenn die Annahmen nicht offensichtlich sind oder der Code ungewöhnlich ist.

5. Schreiben Sie einfachen Code
Nach meiner professionellen Meinung ist das Schreiben von komplexem Code der größte Fehler unter Entwicklern.

Steve Jobs zur Einfachheit:

Einfach kann schwieriger sein als komplex: Sie müssen hart arbeiten, um Ihr Denken zu klären, um es einfach zu machen. Aber es lohnt sich am Ende, denn wenn Sie dort ankommen, können Sie Berge versetzen.

Komplexität kommt in vielen Formen vor, einige davon sind: Zukunftssicherheit, übermäßig komplexe Implementierungen, zu viel Abstraktion, große Klassen und große Methoden.

Weitere Informationen zum Schreiben von sauberem, einfachem Code finden Sie in Uncle Bobs Buch Clean Code und Max Kanat-Alexanders Code Simplicity

Abschluss

Code zu lesen ist schwierig. Mit ein paar einfachen Schritten können Sie sicherstellen, dass der nächste Entwickler Ihren Code versteht.