Clean Code Developer: 2. Oranger Grad - Erfahrungen

Puhhh, der orange Grad hat sich sehr in die Länge gezogen. Nicht etwa weil ich ständig das Armband auf die andere Seite hätte wechseln müssen, sondern eher weil ich so wenig zum Programmieren gekommen bin. Zum Jahresende 2010 war's dann endlich geschafft und schon Anfang Februar 2011 komme ich dazu, den Blog nachzuziehen. Eine Zusammenfassung der Prinzipien und Praktiken sind in meinem Post vom 07. Juni 2010 zu finden. Hier meine Erfahrungen und Meinungen...

3. Ergebnisse
3.1 Single Level of Abstraction (SLA)

• Status: gelb
• Meine Meinung: Beachte ich meist "aus dem Gefühl heraus". Dieses Prinzip muss ich in Zukunft noch mehr verinnerlichen.
• Erkenntnisse:
  
  • Eine manuelle Überprüfung, ob dieses Prinzip eingehalten wurde, ist sehr mühselig. Eine automatische Überprüfung ist unmöglich.
  • Man sollte beim Lesen einer Methode auf sein Bauchgefühl hören und bei Bedarf dann genauer hinsehen, ob SLA eingehalten wurde.
    

3.2 Single Responsibility Principle (SRP)

• Status: grün
• Meine Meinung: Im Tagesgeschäft beachte ich diese Regel. Immer, wenn ich neue Funktionalität zu einer Klasse hinzufüge, frage ich mich vorher, ob dies noch zur Aufgabe der Klasse gehört oder nicht.
• Erkenntnisse:
  
  • Natürlich ist man manchmal versucht, noch eine "Kleinigkeit" zu einer Klasse hinzuzufügen, aber hier muss man Disziplin wahren...

3.3 Separation of Concerns (SoC)

• Status: gelb
• Meine Meinung: Ich achte insgesamt stärker auf die Einhaltung von SoC. Manchmal ist es nicht einfach, die verschiedenen Belange sauber zu trennen, so dass ich in berechtigten Fällen durchaus der pragmatischeren Lösung den Vorzug gebe.
• Erkenntnisse:
  
  • Die Aspektorientierte Programmierung scheint hier das Mittel der Wahl zu sein.
  • Meine persönlichen Erfahrungen mit der AOP waren bisher allerdings eher ernüchternd bis frustrierend. Die Integration in die Eclipse IDE funktionierte nicht richtig und das Zusammenspiel mit RCP bzw. OSGi ist ein einziger Alptraum. Natürlich gibt's da haufenweise tolle Präsentationen von smarten Consultants zu dem Thema, aber ich halte die Kombination RCP / OSGi / AOP im Moment nicht für praxistauglich.

3.4 Source Code Konventionen

• Status: grün
• Meine Meinung: Code-Konventionen sind vorhanden und werden seit längerer Zeit schon angewendet. Es existiert ein schriftliches Regelwerk plus Konfigurationen für Checkstyle und PMD. Beide Tools werden sowohl in der Eclipse IDE, als auch im Nightly Build ausgeführt.

3.5 Issue Tracking

• Status: grün
• Meine Meinung: Wird seit längerem bereits eingesetzt und hat sich ohne Frage bewährt.
• Tools:
  
  • früher Mantis, http://www.mantisbt.org/
  • aktuell Trac, http://trac.edgewall.org/
  • und die Tracker der SourceForge-Projekte

3.6 Automatisierte Integrationstests

• Status: gelb
• Meine Meinung: Automatisierte Integrationstest sind nur wenige vorhanden. Die Integrations- und Unit-Tests werden aktuell in den Nightly Build integriert.
• Tools:
  
  • Hudson, http://hudson-ci.org/
  • JUnit, http://www.junit.org/
  • Ant, http://ant.apache.org/
  • Eclipse Test Framework (ETF), http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.test/testframework.html?view=co
  • PDE Test Utilities, http://www.eclipse.org/articles/Article-PDEJUnitAntAutomation/index.html#PDE_Test_Utilities
• Erkenntnisse:
  
  • Seit Eclipse Helios wird JUnit 4 vom automatischen PDE-Build unterstützt.

3.7 Lesen, Lesen, Lesen

• Status: gelb
• Meine Meinung: Vom Java-Magazin und Eclipse-Magazin lese ich jede Ausgabe, Blogs nur bei Bedarf und Fachbücher max. 2 pro Jahr. Mehr ist zeitlich leider nicht drin.

3.8 Reviews

• Status: gelb
• Meine Meinung: Pair-Reviews sind bei mir nicht möglich. Direkt vor jedem Commit führe ich immer einen Review meines eigenen Codes durch, was sich sehr bewährt hat.

Zurück von der OOP 2011

Wow, nun ist sie leider schon wieder vorbei, die OOP 2011. Es wurde diesmal ein tolles Programm geboten, inklusive einige lebender Legenden, wie z.B. Erich Gamma, Martin Fowler, Tom DeMarco und Gunter Dueck. Spitze!

Clean Code Developer: 2. Oranger Grad - Zusammenfassung

Also, dann auf zum zweiten Grad...

1. Prinzipien
1.1 Single Level of Abstraction (SLA)

Warum? Die Einhaltung eines Abstraktionsniveaus fördert die Lesbarkeit.

• Variablenzuweisung = niedrigstes Abstraktionsniveau, Methodenaufrufe = höhere Abstraktionsniveaus, API-Aufrufe = sehr hohes Level
• Innerhalb einer Methode sollte nur ein Abstraktionsniveau verwendet werden, damit der Code gut lesbar und leicht zu verstehen ist.

1.2 Single Responsibility Principle (SRP)

Warum? Fokus erleichtert das Verständnis. Eine Klasse mit genau einer Aufgabe ist verständlicher als ein Gemischtwarenladen.

• Eine Klasse sollte nur einen Grund für Änderungen haben. Folglich übernimmt eine Klasse genau eine Aufgabe.
• Verletzung des Single Responsibility Principles führt zu Kopplung und erhöhter Komplexität

1.3 Separation of Concerns (SoC)

Warum? Wenn eine Codeeinheit keine klare Aufgabe hat ist es schwer sie zu verstehen, sie anzuwenden und sie ggf. zu korrigieren oder zu erweitern.

• Concerns (Belange) stehen orthogonal zueinander und zur Hauptfunktionalität, z.B. Tracing, Logging, Transaktionalität, Caching
• Concerns in verschiedene Code-Einheiten trennen, im Einklang mit dem Single Responsibility Principle, z.B. DB-Zugriffe von Geschäftslogik trennen
• SoC führt zu loser Kopplung, hoher Kohäsion und gut testbaren Komponenten

1.4 Source Code Konventionen

Warum? Code wird häufiger gelesen als geschrieben. Daher sind Konventionen wichtig die ein schnelles Lesen und Erfassen des Codes unterstützen.

• Namensregeln: Warum? Ohne Namensregeln muss man sich wieder und wieder auf den Stil einzelner Entwickler einstimmen.
• Richtig kommentieren: Warum? Unnötige oder gar falsche Kommentare halten beim Lesen auf. Der Code sollte so klar und deutlich sein dass er möglichst ohne Kommentare auskommt.

2. Praktiken
2.1 Issue Tracking

Warum? Nur, was man aufschreibt, vergisst man nicht und kann man effektiv delegieren und verfolgen.

• Nichts geht verloren, alle Punkte können priorisiert und sortiert werden.
• Tools:
  
  • Mantis, http://www.mantisbt.org/
  • Trac, http://trac.edgewall.org/
  • Bugzilla, http://www.bugzilla.org/
  • JIRA, http://www.atlassian.com/software/jira/
  • weitere...
    

2.2 Automatisierte Integrationstests

Warum? Integrationstests stellen sicher dass der Code tut was er soll. Diese wiederkehrende Tätigkeit nicht zu automatisieren wäre Zeitverschwendung.

• Regressionstests, um Korrektheit von Änderungen sicherzustellen und Angst vor Änderungen zu nehmen
• Automatisierung notwendig, da händisch nicht praktikabel
• Integrationstests oder noch besser Unit Tests durchführen (fernes Ziel: Test Driven Development)

2.3 Lesen, Lesen, Lesen

Warum? Lesen bildet!

• Ziel: immer den neuesten Stand der Entwicklung und der Techniken beobachten
• Vorschlag: mindestens 6 Fachbücher pro Jahr plus Fachzeitschriften und Blogs regelmäßig lesen

2.4 Reviews

Warum? Vier Augen sehen mehr als zwei. Wenn der eine Entwickler dem anderen seinen Code erklärt, tauchen meist Details auf, die bislang nicht bedacht wurden.

• als kontinuierlicher Prozess beim Pair Programming und/oder
• als eigenständiger Prozessschritt beim Code Review

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.

10+1 things they never teach in college about programming

10+1 Dinge, die man nicht an der Uni oder FH lernt: http://www.dzone.com/links/r/101_things_they_never_teach_in_college_about_prog.html

Ja, so isses...