Clean Code Developer: 1. Roter Grad - Erfahrungen

Meine 21 Tage im roten Grad sind heute zu Ende gegangen. Eine Zusammenfassung der Prinzipien und Praktiken sind in meinem Post vom 13. April 2010 zu finden. Hier meine Erfahrungen und Meinungen...

3. Ergebnisse
3.1. Don't Repeat Yourself (DRY)

• Status: grün
• Meine Meinung: Ich achte insgesamt stärker auf Copy&Paste. Wenn ich Code-Passagen kopieren möchte, überlege ich immer erst, ob sich das Kopieren nicht sinnvoll vermeiden lässt. Alternativen:
  
  • Code in gemeinsam benutzte Methode einpacken,
  • Code in gemeinsam benutzte Hilfsklasse extrahieren,
  • beide Code-Abschnitte zusammenfassen (Original und Kopie-Ziel).
• Tools: Zur automatischen Prüfung von DRY kommen zwei Tools in Frage:
  
  • CPD als Teil von PMD, http://pmd.sourceforge.net/cpd.html
  • Checkstyle, Regel "StrictDuplicateCode", http://checkstyle.sourceforge.net/
• Erkenntnisse:
  
  • Checkstyle-Regel "StrictDuplicateCode": Das Limit muss auf mindestens 24 Zeilen hochgesetzt werden (Default: 12 Zeilen), um keine Warnungen wegen des Copyright-Headers im Projekt LunaRCP zu bekommen. Folgende Dinge schränken jedoch die Benutzbarkeit stark ein:
    
    • Javadoc-Zeilen werden nicht ignoriert.
    • Es sind keine definierten Ausschlüsse möglich, wie z.B. bei PMD.
    • Die Prüfung ist nicht zuverlässig. Teilweise werden Code-Passagen auch nach Änderungen noch als dupliziert angezeigt. "Rebuild All" konnte das Problem nicht lösen.
  • Die Checkstyle-Regel "StrictDuplicateCode" wurde nach der Durchführung einiger Code-Verbesserungen wieder deaktiviert. Aber auch CPD bringt hier keine besseren (brauchbareren) Ergebnisse. Der automatisierte Einsatz im Nightly Build macht aus meiner Sicht derzeit keinen Sinn.

3.2. Keep it simple, stupid (KISS)

• Status: grün
• Meine Meinung: Ich liebe KISS! Und ich halte nicht viel von Lösungen, die unnötig kompliziert sind und z.B. Erweiterungspunkte auf Vorrat vorsehen, nur weil man sie ja vielleicht irgendwann in ferner Zukunft mal brauchen könnte.

3.3. Vorsicht vor Optimierungen!

• Status: grün
• Meine Meinung: Optimierungen führe ich grundsätzlich nur durch, wenn offensichtlich Bedarf besteht. Ich mag keine "Optimierung auf Vorrat". Zu jeder Optimierungsaktion gehört ein vorheriges CPU- und/oder Memory-Profiling.

3.4. Favour Composition over Inheritance (FCoI)

• Status: gelb
• Meine Meinung: Dieses Prinzip habe ich während des roten Grades nur selten angewandt, was aber sehr an den bearbeiteten Aufgabenstellungen lag (sehr wenig Neuentwicklungen). Dieses Prinzip muss ich in Zukunft noch mehr verinnerlichen.

3.5. Die Pfadfinderregel beachten

• Status: grün
• Meine Meinung: Im Tagesgeschäft beachte ich die Pfadfinderregel. Immer, wenn eine Code-Passage "komisch" aussieht, d.h. einen "smell" hat, verbessere ich den Code. Im roten Grad habe ich verstärkt auf DRY, KISS und FCoI geachtet.

3.6. Root cause analysis

• Status: grün
• Meine Meinung: Diese Regel beachte ich im Normalfall. Die Suche nach der wirklichen Ursache kostet langfristig gesehen viel weniger Zeit als die andauernden Workarounds.

3.7. Ein Versionskontrollsystem einsetzen

• Status: grün
• Meine Meinung: Subversion ist seit längerem im Einsatz, inkl. der Verwendung von Tags und Branches.

3.8. Erste Refaktorisierungsmuster anwenden

• Status: grün
• Meine Meinung: Verwende ich seit Ewigkeiten. Die am meisten verwendeten Refaktorisierungen der Eclipse IDE sind bei mir: "Methode extrahieren", "Klasse extrahieren", "Umbenennen", "Verschieben", "Konstante extrahieren", "Methoden-Signatur verändern".

3.9. Täglich reflektieren

• Status: grün
• Meine Meinung: Die tägliche Reflektion über die getane Arbeit musste ich mir erst angewöhnen. Ich sehe sie mittlerweile als ein gutes Mittel an, um sich direkt vor dem Feierabend nochmal zu fragen, was man heute alles erledigt hat und welche Punkte eventuell noch offen sind. Die offenen Punkte trage ich in meine persönliche To-Do-Liste für den nächsten Tag ein, damit ich mir die Dinge nicht merken muss (d.h. nicht in den Feierabend mit nach Hause nehme) und nichts vergesse.