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.