Clean Code Developer: 1. Roter Grad - Zusammenfasung

"Mit dem roten Grad beginnt der Weg des Clean Code Developers. Ab hier gilt es, einen ersten Teil des CCD Wertesystems in die tägliche Arbeit einzubringen und immer wieder zu üben." Dann wollen wir mal starten...

1. Prinzipien
1.1. Don't Repeat Yourself (DRY)

"Warum? Jede Doppelung von Code oder auch nur Handgriffen leistet Inkonsistenzen und Fehlern Vorschub."

• Copy&Paste ist ein weit verbreitetes Anti-Pattern.
• Ziel: doppelten Code und andere Artefakte erkennen und
• Wiederholungen durch Refaktorisierungen entfernen (sofern nichts dagegen spricht).
• Tools:
• CPD als Teil von PMD, http://pmd.sourceforge.net/cpd.html
• Checkstyle, Regel "StrictDuplicateCode", http://checkstyle.sourceforge.net/
  

1.2. Keep it simple, stupid (KISS)

"Warum? Wer mehr tut als das Einfachste, lässt den Kunden warten und macht die Lösung unnötig kompliziert."

• Einstein: "Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher."
• Eine einfache, klare, leicht verständliche Lösung sollte immer bevorzugt werden.
• Praxis: Reviews und Pair Programming.
  

1.3. Vorsicht vor Optimierungen!

"Warum? Optimierungen kosten immer viel Aufwand. Wer Vorsicht walten lässt, spart oft wertvolle Ressourcen für das, was dem Kunden wirklich nützt."

• M.A. Jackson: Rules of Optimization:
• Rule 1: Don't do it.
• Rule 2 (for experts only): Don't do it yet.
• Verständlichkeit und Evolvierbarkeit vor (minimalen) Performance-Optimierungen.
• Optimierungen nur, wenn vom Kunden gefordert, vom Entwickler zweimal überlegt und mit Profiler-Analyse
  

1.4. Favour Composition over Inheritance (FCoI)

"Warum? Komposition fördert die lose Kopplung und die Testbarkeit eines Systems und ist oft flexibler."

• Gang of Four: "Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'."
• Vererbung: white box, Subklasse abhängig von Elternklasse
• Komposition: black box, klare Schnittstelle, bessere Entkopplung, leichtere Austauschbarkeit
  

2. Praktiken
2.1. Die Pfadfinderregel beachten

"Warum? Jede Beschäftigung mit einem Gegenstand macht ihn zumindest ein kleinwenig besser. Ganz ohne bürokratische Planung. Fundament und Graswurzelansatz für mehr Qualität."

• Pfadfinderregel: "Hinterlasse einen Ort immer in einem besseren Zustand als du ihn vorgefunden hast."
• Nach getaner Arbeit stimmt der Code mit dem Clean Code Development Wertesystem mehr überein als vorher.
• Anti-Pattern: Broken-Windows-Theorie (eine zerbrochene Fensterscheibe führt später zu völliger Verwahrlosung)
  

2.2. Root cause analysis

"Warum? Symptome behandeln bringt vielleicht schnell eine Linderung - langfristig kostet es aber mehr Aufwand. Wer stattdessen unter die Oberfläche von Problemen schaut, arbeitet am Ende effktiver."

• Immer nach der Ursache eines Problems suchen.
• Bei Kenntnis des Wurzelproblems ist die Bereinigung meist weniger aufwändig als eine Symptomkur.
  

2.3. Ein Versionskontrollsystem einsetzen

"Warum? Angst vor Beschädigung eines 'running system' lähmt die Softwareentwicklung. Mit einer Versionsverwaltung ist solche Angst unbegründet. Die Entwicklung kann schnell und mutig voranschreiten."

• Kein Kommentar!
• Tools:
• Subversion, http://subversion.apache.org/
• TortoiseSVN, http://tortoisesvn.tigris.org/
  

2.4. Erste Refaktorisierungsmuster anwenden

"Warum? Code verbessern ist leichter, wenn man typische Verbesserungshandgriffe kennt. Ihre Anwendungsszenarien machen sensibel für Schwachpunkte im eigenen Code. Als anerkannte Muster stärken sie den Mut, sie anzuwenden."

• vgl. Buch von Martin Fowler
• Refaktorisierungen für roten Grad: "Methode extrahieren" und "Umbenennen"
• Tool: Eclipse for RCP/Plug-in Developers, http://www.eclipse.org/
  

2.5. Täglich reflektieren

"Warum? Keine Verbesserung, kein Fortschritt, kein Lernen ohne Reflexion. Aber nur wenn Reflexion auch eingeplant wird, findet sie unter dem Druck des Tagesgeschäftes auch statt."

• Persönliche Entwicklung durch kleinschrittige Planung und Reflexion nach jedem Schritt.
• Die Arbeit so einteilen, dass sie aus Aufgaben besteht, die an einem Arbeitstag zu bewältigen sind.
• Die Arbeit nicht mit in den Feierabend tragen.