Neuer Artikel im Eclipse-Magazin

Im aktuellen Eclipse-Magazin (4.2010) ist mein zweiter Artikel zum Projekt LunaRCP erschienen: "Baumkunde für Einsteiger. Navigationsbäume mit LunaRCP erstellen".

BTW, den ersten Artikel hatte ich in Zusammenarbeit mit Manfred Novotny geschrieben. Er war bereits im Eclipse-Magazin 1.2010 erschienen: "Persistenzlego. Hibernate-Integration mit Eclipse RCP".

Clean Code Developer: Armbänder

Super, jetzt sind sie endlich da, die CCD-Armbänder. Bestellt am 1. April (kein Scherz!) und schon geliefert am 23. April.

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.

Clean Code Developer: 0. Schwarzer Grad

Manfred Novotny hatte mich im Januar auf diese tolle Homepage aufmerksam gemacht: Clean Code Developer. Ich kann nur sagen: eine Offenbarung! Endlich eine klare Ansage, was Professionalität in der Software-Entwicklung bedeutet / bedeuten kann / bedeuten könnte (je nach persönlichem Standpunkt). Ein nachvollziehbares und praktisch anwendbares Wertesystem für jeden Software-Entwickler. Obendrein wird eine Sammlung von Prinzipien und Praktiken angeboten, die in verschiedenen Stufen ("Graden") der Entwicklung zum "Clean Code Developer" erlernt und verinnerlicht werden können.

Ich finde das Ganze eine echt tolle Sache und habe deshalb beschlossen, mich ebenfalls auf den Weg zum "Clean Code Developer" zu machen. Gemäß den CCD-Graden befinde ich mich nun also im "Schwarzen Grad". Derzeit stehen dem Übergang zum "Roten Grad" noch einige administrative Aufgaben im Weg, die meine Zeit beanspruchen. Ich werde dann später für jeden CCD-Grad meine persönlichen Erfahrungen hier im Blog festhalten.

How to convert a Maven pom.xml into an Ivy ivy.xml file

If you're using Maven just for resolving dependencies, Ivy might be a good alternative for you. You may convert your pom.xml into an ivy.xml file using the following Ant script:

<project name="convertPomToIvy" basedir="." default="convert"
 xmlns:ivy="antlib:fr.jayasoft.ivy.ant"
 xmlns:ac="antlib:net.sf.antcontrib">

   <path id="antlib.classpath">
       <fileset dir="C:/Program Files/apache-ivy-2.1.0" includes="*.jar"/>
       <fileset dir="C:/Program Files/apache-ivy-2.1.0/lib" includes="*.jar"/>
   </path>

   <taskdef uri="antlib:fr.jayasoft.ivy.ant"
       resource="fr/jayasoft/ivy/ant/antlib.xml"
       classpathref="antlib.classpath"
       loaderref="antlib.classpath.loader"/>

   <target name="convert">
       <ivy:convertpom pomFile="pom.xml" ivyFile="ivy.xml" />
   </target>
</project>

Please note that you may want to adjust the paths to the Ivy JAR files.