Sandi Metz schrieb kürzlich einen Artikel, in dem sie verkündete, dass Duplizierung ist günstiger als die falsche AbstraktionDieser Artikel wirft wertvolle Punkte zu den Kosten spekulativer Verallgemeinerungen auf, ist aber Teil einer langen Reihe von Artikeln, die diese Kosten detailliert beschreiben und anprangern. Mittlerweile sollte es ein alter Hut sein, jemanden die Abstraktion kritisieren zu hören, und doch hält sich das Mem hartnäckig.
Der Aspekt des Artikels von Sandi Metz, auf den ich in diesem Beitrag eingehen möchte, ist der mindset Es fördert die Denkweise, die am meisten darauf reagiert hat. Diese Denkweise ist in Kommentaren sehr häufig zu sehen – einfach die Aufgabe erledigen, mehr nicht. Manchmal ist das angemessen und der richtige Ansatz, aber das Problem ist, dass die Kosten der Abstraktion, insbesondere wenn sie falsch gemacht wird, offensichtlich sind, während die Kosten der „Einfachheit zuerst“-Denkweise nicht so offensichtlich sind. Ich werde nicht auf die spezifischen Kosten von dupliziertem Code eingehen, da diese bereits bekannt sind. Ich werde über die Opportunitätskosten – die verpassten Lernmöglichkeiten.
Gute Entwickler sollten ständig lernen und ihre Fähigkeiten ständig verbessern. Es gibt immer Raum für Verbesserungen. Die wichtigste Fähigkeit für Entwickler ist das Erkennen profitabler Abstraktionen, da dies auf geschulter Intuition beruht. Es erfordert, die Kosten langfristig zu erkennen und Fehler zu machen. Entwickler sollten ihre bisherigen Entscheidungen ständig evaluieren und bei neuen Entscheidungen Risiken eingehen.
Opportunitätskosten sind ein oft übersehener Aspekt technischer Schulden. Der Grund, warum die Anhäufung technischer Schulden im Moment die günstigere Wahl ist, liegt darin, dass man einen Weg einschlägt, für den die Lösung bereits bekannt ist. Man muss nichts lernen, sondern nur den Hack implementieren. Das ist in kleinen Dosen in Ordnung, verpasst aber die Chance, etwas über die Codebasis zu lernen, fehlende Abstraktionen zu entdecken und konzeptionelle Werkzeuge zu entwickeln, die zur Lösung des Problems beitragen können.
Die Entwickler in Sandi Metz' Beispiel hätten also erkennen sollen, dass diese spezielle Abstraktion sie mehr kostete als nützte. Das ist eine gute Erkenntnis – eine wertvolle Lernerfahrung. Welche spezifischen Aspekte der Abstraktion verlangsamten die Entwicklung? Welche Teile verwirrten neue Entwickler und führten dazu, dass sie die Entwicklung verschlimmerten? Diese Fragen hätten sich die Entwickler stellen sollen, um aus der Erfahrung zu lernen.
Unser Entwicklungsteam führt wöchentlich „Tech Talks“ durch. Dabei spricht ein Entwickler über etwas, das er in der Woche gelernt hat, über einen Teil des Codes, der komplizierter war als er sein sollte, und so weiter. Diese Vorgehensweise ist von unschätzbarem Wert für die Förderung einer wachstumsorientierten Denkweise, und die Situation aus Mz. Metz‘ Artikel wäre ein perfektes Beispiel dafür gewesen.
Entwickler sollten sich nicht darauf konzentrieren, einfach nur Code zu produzieren. Wer seine Aufmerksamkeit so einschränkt, entwickelt sich nicht weiter und wird bald von besseren Tools überholt. Stattdessen sollten wir erkennen, dass die Aufgabe eines Entwicklers darin besteht, zu verstehen, welche Abstraktionen sich für die Codebasis als wertvoll erweisen. Das lernt man nur durch Erfahrung.