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 […]
Kategorie-Archive: Clean Code Development
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 […]
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) […]
Kontrollstrukturen in der Integration
Die beiden wesentlichen Prinzipien für Clean Code Development sind für uns das IOSP und das PoMO. An version of this article is available here. 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 […]
Struktur folgt Kräften
Strukturen sind, wie sie sind, weil das ihrem Zweck am besten dient. Das gilt für Gebäude, Brücken, Fahrzeuge, Organisationen, Organismen. In der Natur entstehen Strukturen des Lebendigen in einem blinden, evolutionären Prozess. Was überlebt, hat eine genügend gute Struktur. Bei menschengemachten Strukturen sind Strukturen so gut, wie es nach Stand der Erkenntnisse möglich ist. Wie […]
A Different Perspective on a TDD Lesson – Terrain Generation, Part III: Implementation
Implementation follows design. Finally I can sling some code ;-) But where to start? Analysis and design left me with some options. There is not just an Interpolate() method like Robert C. Martin had, but several classes and methods. On the surface of the system under development there are: TerrainGenerator.Interpolate() Terrain.Size Terrain.this[] Terrain.ToArray() And below […]
A Different Perspective on a TDD Lesson – Terrain Generation, Part II: Design
Analysis drives the structure of the solution for the Diamond-Square algorithm from the outside. It defines a syntactic – and semantic – overall contract for the whole. It thus already shapes the code without much creative effort from my side. And it produces criteria to assess if the desired behavior has been achieved. Before I […]
A Different Perspective on a TDD Lesson – Terrain Generation, Part I: Analysis
How to do TDD on a not so simple problem? Robert C. Martin has published a lesson on that tackling the Diamon-Square algorithm for terrain generation. I think that’s a really interesting problem to consider as an exercise in software development to sharpen your skills. Today I presented it to a Clean Code training group […]
Schluss mit defensiver Programmierung
Ein Muster von Trainingsteilnehmern, das ich häufig sehe, wenn wir die Resultate von Übungsaufgaben anschauen, ist das defensive Programmieren. Hier ein Beispiel: Die Übungsaufgabe war die Function Kata fromRoman; es galt also, römische Zahlen in Dezimalzahlen zu konvertieren. Die zu schreibende Funktion lautete int fromRoman(string roman). In einer ersten Iteration sollten nur einziffrige römische Zahlen […]