Warum sind so häufig diese extremen Unterschiede in der Zeit Einschätzungen von Programmierern? Und auch wenn das vom Projekt Manager mit 2,5 multipliziert wird ist es dann immer noch so extrem knapp. Ich kann diese Frage leider nicht abschließend beurteilen. Sicherlich kann schlechte Software Qualität dafür ein Grund sein. Aber auch bei neuen Projekten – von Scratch – kommt das leider vor. Dazu habe ich diesen inspirierenden Artikel von Maxime Rouiller gefunden. Wenn ich als Clean Coder Roland Golla, als Dozent Roland Golla für die Entwicklungshilfe NRW arbeite, moderiere ich Code Reviews. Wenn man bestehenden Code aufräumt kommt leider KISS – Keep it stupid simple viel zu kurz. In der agilen Zeit der unbegrenzten Möglichkeiten neigen Webdeveloper leider dazu Software von Anfang an zu komplex zu bauen. Dabei ist eben der leichtere Entwicklungsansatz mit der Unterstützung von regelmäßigen Code Reviews im Team viel effektiver und wirkungsvoller. Ich bin ein Freund von kleinen Features, die schnell implementiert werden. Alles andere macht Probleme.
Anti Pattern The Gas Factory
Anti Pattern The Gas Factory.
Im folgenden Abschnitt gebe ich meine Interpretation des Blogposts wieder. Man kann zu Beginn einer Entwicklung nicht alles bedenken und natürlich stößt man als Entwickler während der Entwicklung erst an den Kern des Problems. Den sogenannten Special Case. Und hier kann es zu dem Fehler der unnötigen Komplexibilität kommen. Wenn man versucht diesen Workaround allen Klassen und Methoden als Lösung für ein Problem zur Verfügung zu stellen. Alle Eventualitäten abzudecken. Das ist nicht nötig. Macht eure Methoden protected und geht mit public Methoden sehr sparsam und genau um. Das will ich an dieser Stelle nicht weiter ausführen. Hinzu kommt natürlich die Möglichkeit, daß es auch bisher kein anderer braucht. Und das ist leider auch in Zukunft sehr wahrscheinlich.
Folgt man nun den „You aren’t gonna need it“ und „Lean software development„, lernt man nichts zu implementieren, was man nicht braucht. Also wird das erst implementiert, wenn es wirklich an 2 Stellen gebraucht wird. Aber Vorsicht! Das heist nicht das man gegen das Single-Responsibility-Prinzip. Das ist übrigens mein Hauptaugenmerk bei Code Reviews. Als Protected Methode auslagern macht Sinn. Aber man braucht es nicht in eine Make-Everything-Ok Methode auszulagern. Und schlechter Code bleibt auch ausgelagert schlecht. Methoden sollen Units werden und mit Unit Tests getestet werden. Wenn man also nun eine Tankstelle hat, die für eine Menge von einem Tank kalkuliert worden ist braucht man nicht mehre Tanks zu bauen, oder einen Multitank Zuleitungssystem zu konzipieren. Das ist das „Anti Pattern The Gas Factory“
Clean Code auf dem Punkt gebracht
Clean Code ist einfach, lesbar und hat Unittests. Und dann gibt es da diesen riesige Thema Clean Code. Mit Regeln und Prinzipien von Robert C. Martin alias Uncle Bob und einer ganzen Reihe weiterer agilen Lichtgestalten. Aber ob man die alle bei seinem irdischen Problemen braucht mag mal dahin gestellt sein. Aber jedes Wissen in dem Bereich bringt einen weiter. Das ist so. Methoden sollen nur eine Aufgabe haben, Konfigurationen ausgelagert werden. Sprachdateien angelegt und immer eine Mehrsprachigkeit möglich sein. Sonst wird der Weg später zu lang. Und unnötige Komplexibilität und auch jede Form von Komplexibilität ist zu vermeiden.
Blogpost der Inspiration – Anti Pattern The Gas Factory
http://blog.decayingcode.com/post/anti-pattern-gas-factory-or-unnecessary
