Lernen im Doppelpack – Review des ersten Retreat

Clean Code Development und Mountainbiking – das geht zusammen, das befruchtet sich, das macht auch noch Spaß. Anders kann mein Urteil nach 5 Tagen Retreat in Au im Bregenzerwald nicht ausfallen. Aber eins nach dem anderen: Nach einem Urlaub im Hotel Rössle in Au Ende September 2016 hatte ich die Idee, das Lernen von Clean […]

Zukunftsfähigkeit – Checkliste für den Review

Der Motor flüssiger und nachhaltiger Softwareproduktion ist eng getaktetes 360° Feedback. Dazu gehört die Abnahme durch den Kunden bzw. seinen Stellvertreter für die Verhaltensanforderungen einerseits und vorgelagert andererseits ein Review des Codes für die Zukunftsfähigkeit. Der Review gehört zur „Definition of Done“ und wird geleitet durch die Architekturrolle. Um die Zukunftsfähigkeit verlässlich zu überprüfen, sollte […]

Zukunftsfähigkeit IV – Wandelbarkeit/Testbarkeit

Alles könnte gut sein in Sachen Zukunftsfähigkeit, wenn Code korrekt und verständlich ist – wäre da nicht die Fehlbarkeit des Menschen. Bei aller Gewissenhaftigkeit werden Fehler und Irrtümer vorkommen. Auch das beste Feedback wird nicht nur Code von 100%iger Qualität zum Anwender lassen. Bugmeldungen und Nachbesserungswünsche kommen garantiert – allerdings hoffentlich in deutlich geringerer Menge […]

Zukunftsfähigkeit III – Wandelbarkeit/Verständlichkeit

Ob Software schon und noch korrekt ist, wird im Review zurecht zuerst geprüft. Durch mangelhafte Korrektheit ist die Zukunftsfähigkeit des Softwareentwicklungsprozesses unmittelbar kompromittiert. Früher oder später werden Inkorrektheiten im Produktivbetrieb durch Anwender aufgedeckt, gemeldet und führen dann zu Verwirbelungen des Entwicklungsprozesses. Nachbesserungen sind der Feind des Neuen, Wertvollen. Sie kosten nicht nur Kapazität, die für […]

Zukunftsfähigkeit II – Korrektheit/Regressionsfreiheit

Ob Software schon und immer noch zukunftsfähig ist, wird im Review beurteilt. Den führt die Architektenrolle vor der Abnahme durch den Kunden umfassend durch. Geprüft wird auf Korrektheit und Wandelbarkeit Beide Facetten der Zukunftsfähigkeit haben Aspekte, die es getrennt zu betrachten gilt. Bei der Korrektheit ist das zum einen die Maturität. Die ist vorhanden, wenn […]

Zukunftsfähigkeit I – Korrektheit/Maturität

Unsauberer Code erfüllt Anforderungen. Er stellt gewünschtes Verhalten her. Das ist für den Kunden von höchster Wichtigkeit und vergleichsweise leicht zu überprüfen. Clean Code erfüllt dieselben Anforderungen – und noch mehr. Clean Code steht dirty code in Sachen Verhalten in nichts nach. Darüber hinaus jedoch erfüllt er auch noch die Anforderung Zukunftsfähigkeit. Die ist dem […]

Die Anforderungen auf die Füße stellen

Die üblicherweise ausgesprochenen Anforderungen des Kunden an eine Software sind: Funktionalität, z.B. die Software rechnet Effizienz, z.B. die Software rechnet schnell Und zwar in der Reihenfolge, d.h. zuerst muss die Software grundsätzlich die gewünschte Funktionalität haben, dann kann ggf. an ihrer Effizienz geschraubt werden. Schon diese beiden Anforderungen jedoch können nicht immer vollständig erfüllt werden. […]

Grade der Testbarkeit

Testbarkeit ist für mich ein zentrales Kennzeichen für Wandelbarkeit. Wenn Code leicht zu testen ist, dann ist er lose gekoppelt an anderen Code. Die Struktur zu verändern, in der er eingebettet ist, fällt dann leicht. Was getestet werden soll Testbarkeit (durch automatisierte Tests) bezieht sich auf Verhalten. Verhalten ist entweder Funktionalität (z.B. die Software rechnet) […]

Der Papertrail eines Trainings

„Wie läuft eigentlich ein Clean Code Development Training ab?“ werden wir immer mal wieder gefragt. Dann versuchen wir zu beschreiben, wie wir mit Übungen und Diskussion und am Flipchart arbeiten. Clean Code Development braucht hands-on experience, als Trainingsteilnehmer muss man „es“ getan haben. Und zwar nicht zu knapp, in vielen Wiederholungen. Immerhin gilt es, alte […]

Kontrollstrukturen in der Integration

Die beiden wesentlichen Prinzipien für Clean Code Development sind für uns das IOSP und das PoMO. Nach dem Integration Operation Segregation Principle (IOSP) sollen Funktionen (oder allgemeiner: Module) ihre Grundverantwortlichkeit entweder auf die Herstellung von Verhalten durch Logik konzentrieren (Operation) oder selbst keine Logik enthalten, sondern nur andere Module zu einer größeren Einheit integrieren. Das […]