Stimmen Sie nicht zu, etwas zu entwickeln, das Sie nicht verstehen.

Seit Anfang 2018 bin ich als Teamleiter / Chefentwickler / leitender Entwickler tätig – nennen Sie es, wie Sie möchten, aber der Kern der Sache ist, dass ich die volle Verantwortung für eines der Module und alle Entwickler, die daran arbeiten, trage. Diese Position eröffnet mir eine neue Perspektive auf den Entwicklungsprozess, da ich an einer größeren Anzahl von Projekten beteiligt bin und aktiver an Entscheidungen teilnehme. Kürzlich habe ich, dank dieser beiden Umstände, unerwartet erkannt, wie stark das Maß an Verständnis den Code und die Anwendung beeinflusst.

Der Gedanke, den ich ausdrücken möchte, ist, dass die Qualität des Codes (und des Endprodukts) eng damit verbunden ist, wie gut die Menschen, die das Design übernehmen und den Code schreiben, sich bewusst sind, was sie tatsächlich tun.

Vielleicht denken Sie jetzt: "Danke, Kapitän. Natürlich wäre es gut zu verstehen, was man da eigentlich schreibt. Sonst könnte man genauso gut eine Gruppe Affen engagieren, die zufällig auf die Tasten haut, und sich damit zufrieden geben." Und Sie haben vollkommen recht. Daher gehe ich davon aus, dass Sie sich dessen bewusst sind, dass es unerlässlich ist, eine grundlegende Vorstellung davon zu haben, was man tut. Dies könnte man als Basisverständnis bezeichnen, und wir werden es nicht im Detail erörtern. Stattdessen werden wir uns damit beschäftigen, was genau verstanden werden muss und wie es sich auf die Entscheidungen auswirkt, die Sie täglich treffen. Hätte ich diese Dinge im Voraus gewusst, hätte ich mir viel Zeit und fragwürdigen Code erspart.

Obwohl Sie hier unten keinen einzigen Code-Zeilen sehen werden, halte ich dennoch alles, was hier gesagt wird, für sehr wichtig, um qualitativ hochwertigen, ausdrucksstarken Code zu schreiben.

Erste Stufe des Verständnisses: Warum funktioniert es nicht?

Entwickler erreichen dieses Niveau oft sehr früh in ihrer Karriere, manchmal sogar ohne jegliche Unterstützung von außen – zumindest ist das meine Beobachtung. Stellen Sie sich vor, Sie erhalten einen Bug-Report: Eine Funktion in der Anwendung funktioniert nicht, sie muss repariert werden. Wie würden Sie vorgehen?

Das Standardverfahren sieht folgendermaßen aus:

1. Finden Sie den Codeausschnitt, der das Problem verursacht (wie das geschieht, ist ein separates Thema, das ich in meinem Buch über veralteten Code behandle)
2. Änderungen in diesen Codeausschnitt vornehmen
3. Sicherstellen, dass der Bug behoben ist und keine regressiven Fehler aufgetreten sind

Jetzt konzentrieren wir uns auf den zweiten Punkt – die Änderungen im Code vorzunehmen. Es gibt zwei Ansätze für diesen Prozess. Der erste: Verstehen, was genau im aktuellen Code passiert, den Fehler identifizieren und beheben. Der zweite: Auf gut Glück vorgehen – zum Beispiel +1 in eine Bedingung oder Schleife einfügen, prüfen, ob die Funktion im gewünschten Szenario nun funktioniert, dann noch etwas ausprobieren und so weiter bis in alle Ewigkeit.

Der erste Ansatz ist der richtige. Wie Steve McConnell in seinem Buch Code Complete erklärt (übrigens kann ich es sehr empfehlen), sollten wir jedes Mal, wenn wir etwas im Code ändern, in der Lage sein, zuverlässig vorherzusagen, wie sich dies auf die Anwendung auswirkt. Ich zitiere aus dem Gedächtnis, aber wenn ein Bugfix nicht wie erwartet funktioniert, sollte Sie das ernsthaft alarmieren und Sie sollten Ihren gesamten Handlungsplan in Frage stellen.

Zusammenfassend lässt sich sagen, dass man, um einen soliden Bugfix durchzuführen, der die Codequalität nicht verschlechtert, sowohl die gesamte Struktur des Codes als auch die Quelle des spezifischen Problems verstehen muss.

Die zweite Ebene des Verständnisses: Warum funktioniert es?

Diese Ebene wird viel weniger intuitiv erfasst als die vorherige. Ich habe sie als noch unerfahrener Entwickler von meinem Chef gelernt und habe sie anschließend oft selbst Neulingen erklärt.

Stellen Sie sich vor, Sie erhalten gleichzeitig zwei Fehlerberichte: Der erste betrifft Szenario A, der zweite Szenario B. In beiden Szenarien läuft etwas schief. Daher kümmern Sie sich zuerst um den ersten Fehler. In Anlehnung an die Prinzipien, die wir für das erste Verständnislevel aufgestellt haben, vertiefen Sie sich gründlich in den Code, der mit dem Problem zusammenhängt, und klären, warum er das Verhalten der Anwendung in Szenario A beeinflusst. Schließlich nehmen Sie sinnvolle Anpassungen vor, die genau das gewünschte Ergebnis liefern. Alles läuft bestens.

Dann wechseln Sie zum Szenario B. Sie wiederholen das Szenario, um den Fehler auszulösen, aber — Überraschung! — jetzt funktioniert alles wie geplant. Um Ihre Vermutung zu bestätigen, setzen Sie die Änderungen zurück, die Sie bei der Fehlerbearbeitung von A vorgenommen haben, und Fehler B tritt wieder auf. Ihr Bugfix hat beide Probleme gelöst. Wie praktisch!

Darauf haben Sie noch nie gerechnet. Sie haben einen Weg gefunden, um den Fehler im Szenario A zu beheben, und haben keine Ahnung, warum das auch im Szenario B funktioniert hat. An diesem Punkt liegt die Versuchung nahe zu denken, dass beide Probleme erfolgreich gelöst sind. Das erscheint logisch, denn das Ziel war schließlich, die Fehler zu beheben, oder? Aber die Arbeit ist noch nicht abgeschlossen: Sie müssen noch herausfinden, warum Ihre Maßnahmen den Fehler im Szenario B behoben haben. Warum? Weil es sein könnte, dass es auf falschen Prinzipien basiert, und dann müssen Sie nach einer anderen Lösung suchen. Hier sind einige Beispiele dafür:

• Da die Lösung nicht gezielt für den Fehler B unter Berücksichtigung aller Faktoren entwickelt wurde, haben Sie möglicherweise unbewusst die Funktion C beschädigt.
• Es besteht die Möglichkeit, dass sich irgendwo noch ein dritter Fehler versteckt, der mit derselben Funktion zusammenhängt, und Ihr Bugfix hängt die korrekte Funktion des Systems im Szenario B daran. Momentan sieht alles gut aus, aber eines Tages wird dieser dritte Fehler entdeckt und behoben. Dann tritt im Szenario B wieder ein Fehler auf, und gut, wenn es nur dort ist.

All das bringt Chaos in den Code, und irgendwann wird es Ihnen wahrscheinlich auf den Kopf fallen – wahrscheinlich genau im ungünstigsten Moment. Sie müssen Ihren Willen zusammennehmen, um sich die Zeit zu nehmen, zu verstehen, warum alles auf den ersten Blick funktioniert, aber es lohnt sich.

Dritte Ebene des Verständnisses: Warum funktioniert es?

Mein jüngstes Aha-Erlebnis hängt genau mit dieser Ebene zusammen, und vermutlich hätte mir dieser Gedanke die größten Vorteile verschafft, wenn ich früher darauf gekommen wäre.

Um es klarer zu machen, betrachten wir ein Beispiel: Ihr Modul muss mit Funktion X kompatibel sein. Sie sind nicht besonders gut mit Funktion X vertraut, aber man hat Ihnen gesagt, dass Sie für die Kompatibilität das Framework F verwenden müssen. Andere Module, die mit X integriert werden, funktionieren genau damit.

Ihr Code hat von Anfang an überhaupt nicht mit dem Framework F zusammengearbeitet, daher wird dessen Implementierung alles andere als einfach sein. Das wird ernsthafte Folgen für einige Teile des Moduls haben. Dennoch stürzen Sie sich voller Elan in die Entwicklung: Wochenlang schreiben Sie Code, testen, bringen Testversionen heraus, erhalten Feedback, beheben Regressionen, entdecken unvorhergesehene Komplikationen, überschreiten die ursprünglich festgelegten Fristen, schreiben noch mehr Code, testen erneut, erhalten Rückmeldungen, korrigieren Regressionen – all das, um das Framework F zu implementieren.

Und irgendwann wird Ihnen plötzlich klar – oder vielleicht hören Sie es von jemandem –, dass das Framework F Ihnen möglicherweise keine Kompatibilität mit Funktion X bieten wird. Vielleicht waren all diese Zeit und Mühe vollkommen umsonst.

Ähnliches ist mir einmal während eines Projekts passiert, für das ich verantwortlich war. Warum ist das passiert? Weil ich nicht gut verstanden habe, worum es bei Funktion X geht und wie sie mit dem Framework F zusammenhängt. Was hätte ich tun sollen? Ich hätte die Person, die die Entwicklungsaufgabe stellt, bitten sollen, mir klar zu erklären, wie der geplante Ablauf zu dem gewünschten Ergebnis führt, anstatt einfach das zu wiederholen, was für andere Module gemacht wurde, oder blind zu glauben, dass das für die Funktion X nötig ist.

Die Erfahrung dieses Projekts hat mich gelehrt, den Entwicklungsprozess abzulehnen, solange wir kein klares Verständnis dafür haben, warum uns bestimmte Aufgaben übertragen werden. Klar und direkt ablehnen. Wenn man eine Aufgabe erhält, ist der erste Impuls, sofort damit zu beginnen, um keine Zeit zu verlieren. Aber die Politik „Projekt anhalten, bis wir alle Details verstehen“ kann die verschwendete Zeit erheblich reduzieren.

Lassen Sie sich nicht unter Druck setzen, um zu beginnen, bevor Sie verstehen, warum das geschieht — widerstehen Sie dem. Zuerst sollten Sie klären, welche Ziele mit dieser Aufgabe verfolgt werden, und entscheiden, ob dieser Weg zu den Zielen führt. Ich habe das alles auf die harte Tour gelernt — ich hoffe, mein Beispiel erleichtert das Leben denen, die das hier lesen.

Vierte Ebene des Verständnisses: ???

In der Programmierung gibt es immer etwas zu lernen, und ich glaube, ich habe nur die Oberfläche des Themas Verständnis berührt. Welche weiteren Ebenen des Verständnisses haben Sie im Laufe Ihrer Jahre mit Code entdeckt? Welche Entscheidungen haben Ihre Code- und Anwendungsqualität positiv beeinflusst? Welche Entscheidungen waren falsch und haben Ihnen eine wertvolle Lektion erteilt? Teilen Sie Ihre Erfahrungen in den Kommentaren.

Quelle: habr.com