Mein Anliegen ist es, Wissen und Informationen zu Clean Code und Test Driven Development weiterzugeben. Als Programmierer verbringt man viel mehr Zeit damit fremden Code zu lesen als welchen zu schreiben. Fast immer ist die Codequalität, die man antrifft sehr schlecht. Meistens verstricken sich die Programmierer in unnötige Komplexität. Ich suche Wege zurück zur Simplicity und freue mich auf anregende Diskussionen.
Um mir die von Ralf Westphal in seinem Buch "Handreichungen zum Code-Review" vorgestellten Konzepte, Ideen und Beispiele zu verdeutlichen habe ich das letzte Kapitel "Grade der Testbarkeit" mal Schritt für Schritt nachprogrammiert. Genutzt habe ich dafür ein Gitlab-Repository, dass ihr euch hier anschauen könnt:
Jeder commit spiegelt mehr oder weniger einen Schritt aus dem Kapitel wieder. Um alles "buchgemäß" anschauen zu können, muss es also commit für commit ausgecheckt werden (Erst spät ist mir eingefallen, dass branches evtl. sinnvoller gewesen wären). In den commit messages habe ich grob geschrieben, was warum wie geändert wurde.
Ich hoffe, dass es verständlich ist, das Buch zu lesen hilft sicherlich. Es gibt ein paar Abweichungen aber sonst stimmt es im Großen und Ganzen überein.
Bei den am Schluss sinnvoll übrig zu bleibenden Tests bin ich mir allerdings nicht sicher. Von daher wird es bestimmt noch den einen oder anderen commit geben.
Ich wünsche euch viel Spaß damit und bin für jede Idee, Verbesserung, etc. dankbar,
Es freut mich, dass soviel Übereinstimmung entstanden ist. Was ich an Robert C. Martin mehr mag als seine Bücher, das sind vor allem seine Uncle Bob Videos. Sie sind didaktisch gut gemacht und motivierend. Insbesondere - aber nicht nur - für Geeks und Nerds.
Bei aller Euphorie für Clean Code benötigt die Bewegung Querdenker. Nur kritisches Hinterfragen verhilft zu weiterem Fortschritt.
Hier noch ein Artikel zum Thema Widerstand, der mir gut gefallen hat. Ich hoffe, das ist nicht zu sehr off topic:
Kreative Arbeit ist ohne Spaß nicht zu bewältigen. Judith Andresen hatte dieses Zitat aus dem Top Talk auf den code:talks zum Thema Arbeitsbedingungen in der IT von mir aufgegriffen. In jeder Code-Review-Session lernt mindestens eine Person etwas Neues. Da Weiterbildung im Tagesgeschäft praktisch nicht existiert, bietet ein Code Review eine gute Chance eine kontinuierliche und wohl-dosierte Form des Know-How-Transfers auf einzelne Entwickler zu bringen. Hier steht vor allem das begehrte “Best Practice” Experten-Know-How automatisch im Fokus. Wissen, dass man sich vielleicht gar nicht zugänglich machen kann, weil es auch ein harter und langer Weg ist. Da ist auch jeder froh, wenn er sich so einen Weg sparen kann. Sich gemeinsam über den Code eines aktuellen Projekts auszutauschen, ändert die Einstellung und Denkweise von Entwicklern im Bezug auf logische Operationen, Lesbarkeit und Wartbarkeit. Viel wichtiger ist allerdings, dass in diesem Moment auch der Blick über den Tellerrand in Richtung User Story und Anforderungen an die Applikation geht. Zeiten ändern sich. Jüngere Entwickler kennen sich häufig besser mit neuen Technologien im globalen Software-Trend aus. Diese Entwickler haben auch auf ihren eigenen Rechnern viel aktuellere Setups eingerichtet und bringen sehr wichtiges Know-How in Teams, mit dem man erst in der Lage ist diese neuen Möglichkeiten zu bewerten und auch in den aktuellen technologischen Stack zu integrieren.
ich habe nach einigen Jahren (und einiger DDD-Lektüre und -Praxis ;-) Robert C. Martins »Clean Code« mal wieder gelesen und bin im Kapitel 2 über den Abschnitt »Use Solution Domain Names« gestolpert:
»Remember that the people who read your code will be programmers. So go ahead and use computer science (CS) terms, algorithm names, pattern names, math terms, and so forth. It is not wise to draw every name from the problem domain because we don’t want our coworkers to have to run back and forth to the customer asking what every name means when they already know the concept by a different name.«
Steht das nicht im Widerspruch zur Ubiqitous Language aus dem Domain-driven Design, wo wir doch eine gemeinsame Sprache zwischen Entwicklern und Anwendern schaffen wollen, welche auf der (Problem)-Domäne beruht und sich m.E. auch bis in den Code durchzieht?
Ich teile die Ansicht, dass die üblichen SW-Strukuturierungsansätze und auch die entsprechende Lehre noch sehr technisch sind, weshalb sich DDD auch nach wie vor schwer tut.
Wo wir uns evtl. mißverstanden haben, ist bzgl. Projekt vs. Produkt. Ich halte eine gemeinsame Domänensprache in beiden Ansätzen für absolut notwendig. Nur die Wahrscheinlichkeit, dass eine (gute) gemeinsame Domänensprache entstehen kann, ist m.E. in einem Produkt-Ansatz aufgrund der grundsätzlich langfristigeren Ausrichtung einfach höher, als in einem eher kurzfristigen Projektansatz. Das schließt natürlich nicht aus, dass es in beiden Ansätzen nicht auch jeweils entsprechende Ausnahmen gibt.
Viele Grüße
Michael
Dieser Beitrag kann nicht mehr kommentiert werden.
Stefan