Das Clean Code Developer Wertesystem
Clean Code Developer haben ein Wertesystem. Es besteht aus den im folgenden beschriebene vier Werten.
Evolvierbarkeit
Software wird in der Regel über lange Zeiträume betrieben. Während dieser Zeit ändern sich die Rahmenbedingungen, müssen Features ergänzt werden. Im Idealfall kostet die Implementierung eines Features einen festen Betrag, der unabhängig davon ist, wann es realisiert wird. In der Praxis steigt der Preis allerdings für ein Feature, je später es realisiert wird. Am Anfang sind Features preiswert, am Ende ist es gar nicht mehr möglich Features zu ergänzen, weil niemand mehr durchblickt. Die Software wird weggeworfen und neu entwickelt. Je einfacher die Software an geänderte Rahmenbedingungen angepasst werden kann, desto höher ist ihre Evolvierbarkeit. Aber Evolvierbarkeit ist kein Selbstzweck, das führt uns zum nächsten Wert, der Produktionseffizienz.
Korrektheit
Software muss funktional korrekt sein. Ein Buchhaltungsprogramm muss die Buchungen ordnungsgemäß verbuchen, eine Tabellenkalkulation muss richtig rechnen. Aber auch die nicht-funktionalen Anforderungen müssen erfüllt sein. Das Programm muss schonend mit Ressourcen wie Speicher, Prozessorzeit, Plattenplatz etc. umgehen, die Antwortzeiten müssen in einem erträglichen Rahmen liegen. Erst wenn alle Anforderungen erfüllt sind ist die erstellte Software korrekt.
Produktionseffizienz
Am Ende spielen natürlich auch die Entwicklungszeit und der Preis der Software eine Rolle. Und der ist höher, wenn die Produktion der Software nicht effizient erfolgt. Das beginnt bei manuellen Arbeitsschritten, die nicht automatisiert werden und endet bei hohen Fehlerraten die mehrmaliges Nachbessern erfordern. In letzter Konsequenz bedeutet Produktionseffizienz, dass die Software über Jahre oder gar Jahrzehnte weiterentwickelt werden kann statt irgendwann wieder von vorne beginnen zu müssen. Gleichzeitig reduziert eine hohe Produktionseffizienz die Anfälligkeit für Fehler.
Reflexion
In einer jungen Wissenschaft wie der Informatik ist es wichtig, stets neue Erkenntnisse zu berücksichtigen. Dazu ist Reflexion auf allen Ebenen erforderlich. Angefangen beim Reflektieren über die Implementation beim Pair Programming, das tägliche Reflektieren des Teams, die Reflexion nach jeder Iteration, bis hin zur Reflexion der gesamten Branche über ihr Tun. Ohne Reflexion keine Weiterentwicklung.
Prinzipien und Praktiken
Das Wertesystem leitet Clean Code Developer in ihrer täglichen Arbeit. Es enthält keine Problemlösungen, sondern definiert Rahmenbedingungen für Problemlösungen. Die vier Werte sind für eine konkrete alltägliche Umsetzung jedoch zu abstrakt. Daher haben wir Bausteine zusammengetragen, die jeweils mindestens einen der Werte befördern. Diese konkreten Bausteine teilen wir in zwei Kategorien:
- Prinzipien: CCD-Prinzipien sind die grundlegenden Gesetzmäßigkeiten für die Strukturierung von Software. Sie sind entweder zu anderen Rahmenbedingungen orthogonal oder ihnen übergeordnet. Code sollte immer im Einklang mit einer maximalen Zahl von Prinzipien sein. Natürlich haben sie nicht "die Macht" von Naturgesetzen, denen niemand zuwiderhandeln kann. Aber sie sind mit ihnen in Bezug auf die Softwareentwicklung gleichauf in ihrer Fundamentalität. Wo ein Prinzip nicht eingehalten wird, tritt also nicht unbedingt sofort ein negativer Effekt ein, aber kurz- bis mittelfristig bleiben Zuwiderhandlungen nicht ohne Schmerz. Der drückt sich in Mühe beim Codeverständnis aus oder im hohen Aufwand, um Änderungen einzubringen. Ultimativ ist er, wenn Software nicht mehr evolvierbar ist. Ob ein Prinzip eingehalten wurde, kann man dem Code immer ansehen.
- Praktiken: Praktiken sind Verhaltensweisen, die ständig zum Einsatz kommen. Sie beschreiben, was Clean Code Developer praktisch tun. Motto der Praktiken: "Tue es immer so. Jeden Tag, jederzeit." Es sind handfeste Handlungsanweisungen, die u.U. des Einsatzes von Werkzeugen bedürfen. Ob einer Praktik gefolgt wird, kann man dem Code nicht immer ansehen.
Prinzipien
- Don´t Repeat Yourself (DRY): CcdRoterGrad
- Keep It Simple, Stupid (KISS): CcdRoterGrad
- Vorsicht vor Optimierung: CcdRoterGrad
- Favour Composition over Inheritance (FCoI, OOP): CcdRoterGrad
- Single Level of Abstraction: CcdOrangerGrad
- Separation of Concerns (SoC): CcdOrangerGrad
- Sourcecode-Konventionen: CcdOrangerGrad
- SOLID
- S-ingle Responsibility Principle (SRP): CcdOrangerGrad
- O-pen-Close Principle (OCP, OOP): CcdGruenerGrad
- L-iskov Substitution Principle (LSP, OOP): CcdGelberGrad
- I-nterface Segregation Principle (ISP, OOP): CcdGelberGrad
- D-ependency Inversion Principle (DIP, OOP): CcdGelberGrad
- Principle of Least Astonishment: CcdGelberGrad
- Information Hiding Principle (IHP): CcdGelberGrad
- Tell, don´t ask: CcdGruenerGrad
- Law of Demeter (LoD, OOP): CcdGruenerGrad
- Entwurf und Implementation überlappen nicht: CcdBlauerGrad
- Implementation spiegelt Entwurf: CcdBlauerGrad
- You Ain´t Gonna Need It (YAGNI): CcdRoterGrad, CcdBlauerGrad
Praktiken
- Pfadfinderregel: CcdRoterGrad
- Root Cause Analysis: CcdRoterGrad
- Versionskontrolle: CcdRoterGrad
- Tägliche Reflexion: CcdRoterGrad
- Issue Tracking: CcdOrangerGrad
- Refaktorisierungen
- einfache: CcdRoterGrad
- komplexe: CcdGelberGrad
- Automatisiertes Testen
- Integrationstests: CcdOrangerGrad
- Unit Tests: CcdGelberGrad
- Testattrappen: CcdGelberGrad
- Code Coverage Analyse: CcdGelberGrad
- Komponentenorientierung
- Inversion of Control Container: CcdGruenerGrad
- Contract-first Design: CcdBlauerGrad
- Komponentenwerkbänke: CcdBlauerGrad
- Test Driven Development/Design: CcdBlauerGrad
- Statische Codeanalyse: CcdGruenerGrad
- Automatische Produktion
- Übersetzung und Test: CcdGruenerGrad
- Setup und Deployment: CcdBlauerGrad
- Iterative Entwicklung: CcdBlauerGrad
- Fortbildung
- Lesen, Lesen, Lesen: CcdOrangerGrad
- Teilnahme an Fachveranstaltungen: CcdGelberGrad
- Erfahrung weitergeben: CcdGruenerGrad
- Code Reviews: CcdOrangerGrad
- Messen von Fehlern: CcdGruenerGrad
