Default Values

Um Default Values gibt es immer wieder Diskussion unter Softwareentwicklern und oft sieht man das es scheinbar nicht ausreichend darüber nachgedacht wurde. Bezüglich der Default Values haben sich folgende zwei Regeln bewährt:

1. Ein guter Name, der keinen Interpretationsspielraum lässt.
2. Less Surprising Value

Hier ein Beispiel, in Kafka  gibt es ein  Replaction-Factor=1 der dazu benutzt wird die Replikation der Kafka Topics zu konfigurieren um so eine robuste Umgebung zu erhalten.

Was ist daran nun sub-optimal?

1. Schnellen Programmierern werden leicht übersehen das es sich um den Faktor und nicht die Anzahl der Replikas handelt. So könnte man annehmen das es mindesten ein Replika gibt. Diese Annahme trügt, beim Wert 1 gibt keine Topic Replikation, weil 1 * 1 = 1 ist . Besser wäre wenn das Property nicht Replica-Factor heissen würde sondern Replica-Count. Der Softwareentwickler muss nicht die Hürde der Multiplikation überwinden. Je weniger mentale Barrieren, desto besser.
2. Der Wert ist 1, das klingt erstmal gut. Trotzdem würde ich erwarten, das wenn man Kafka einsetzt, das die Replikation aktiv ist und das ist hier nicht der Fall. Besser wäre also hier der Wert 2 als Default Value.

The 2nd Most Important Task of a Software Developer

The most import task of a software developer is to write code. Well, this answer was pretty easy. Really, yes! But what is second most important skill. I ask my colleagues, first guy says, watching youtube - nice but wrong, 2nd guy: write good documentation - good shot but also wrong.
For me and I'm confident that I'm right, the second most important task of a software developer is to delete code. The first important task is to write code and the second important task is to delete code.
I don't mean delete bugy code, I mean delete working code. Why should you do this?

We have limited time and limited count of developer, this means, we have a more or less constant velocity developing code. If our code base grows, we spend time for maintenance code an we have less time for developing new features, an so on and so on util we reached standstill.

To avoid the standstill, we suggest following tasks to reduce the code size, it a little bit like the Simplify your Life Literature

1. remove dead code
2. refactor code to build simpler and shorter code
3. reimplement code in an effective way, change tools, ... 
4. delete working code if there is users don't require the function anymore

If somebody say's that we keep this function because, we may use them - then remove the code. The word may is the indicator to remove the code. If we delete to much code, don't worry. Most of the times it cheaper to rewrite a little peace of code instead of keeping all old code fragments.

Here some link illustrating the problems:

1. Linux Maintainer needed, because of heavy load and huge Code base http://www.golem.de/news/linuxcon-dem-linux-kernel-fehlen-maintainer-1510-116749.html
2. Linux is planning to remove EXT3 filesystem http://www.pro-linux.de/news/1/22532/ext3-dateisystemtreiber-soll-aus-linux-entfernt-werden.html

Avoid double software development? No!

In the many cases of software development like this, double work is a better opportunity. Reasons there for:

1)
If you try to avoid double work, you have to spend significant time to collect the requirements and to coordinate the work. You don’t reduce the time you need to develop a working software solution. Let me illustrate that, if you speak every week with 8 people for 1,5h for four weeks, then you have spend 60h of working time plus one week for software development, makes total 100h. If two developers build two solution, you spend only two weeks, total 80h. One additional reason, too much and too less communication frustrates developers easily.

2)
If you develop two proper working solutions, you can decide for better solution. This means, if you has developed only one solution, your chance is 50% to have the worst solution. If you select one solution from two, you chance is 100% to have not the worst solution.

My advise is in the first develop round, every team are allowed to develop his own solution. This mean share nothing. In the next round,  the development teams can decide to switch to one solution, to the better one or to decide to develop an better third solution with the experiences of booth early versions.

Vortrag auf der Konferenz Developer World 2015

Wer möchte kann mich auf der Developer World Konferenz (Link) am 17.4.2015 in Hannover erleben. Zusammen mit Uwe Beßle halte ich den Vortrag: Erfahrungsbericht: Testen von nichtfunktionalen Anforderungen im E-Commerce bei OTTO Hamburg
Das Testen funktionaler Anforderungen ist heute Standard in der Softwareentwicklung und wird gut durch Software unterstützt. Nichtfunktionale Anforderungen werden dagegen derzeit oft nicht ausreichend getestet. Am Beispiel von OTTO.de wird gezeigt, wie verschiedene nichtfunktionale Anforderungen, wie Performance, Lastverhalten sowie Robustheit systematisch als Qualitätskriterien getestet werden können. Es werden Vorgehen, Tests, Tools und Integration in den Entwicklungsprozess beschrieben.

Link zum Konferenzprogramm.

Code Weaving

Wie immer verursacht der Tiobe-Index immer eine heftige Diskussion unter Softwareentwicklern über die Sinnhaftigkeit des Index und die Erstellung eben dieses Index. Warum ist meine Lieblingssprache nur so weit unten. Das kann doch nicht sein. Wie wird dieser Index eigentlich erstellet.

2014: JavaScript wurde zur Sprache des Jahres. Keine wirkliche Überraschung, bei dem was sich hier in den letzten Jahren getan hat, Unit-Tests, Paketmanager, bessere Libs, hübsche Visualisierungen. JavaScript ist überall mit dabei. Verlierer des Rankings ist sicher Groovy, das es nicht mal in die Top 50 geschafft hat.

Neben diesem Ranking entspann sich die Frage, warum die Softwareentwickler nicht die für das Problem am besten geeignete Sprache einsetzen und die gesamt Applikation zusammenweben aus den Codestücke der verschiednen Programmiersprachen. Das entspricht dann einer Best-of-Beed-Strategie. Der Vorteil, man hat immer das optimale Tool bzw. Programmiersprache um ein Teilproblem zu lösen. Hier ein Beispiel, man steuert eine Servierfarm via Python macht REST Calls mit CURL, verarbeitet numerische Daten mit R. Das alles wird dann zusammen gewoben mit BASH, Ant oder dem Jenkins. Zusätzlich erhält man so eine einfache und sehr gut testbare, modularisierte Software. Aber der Nachteil, es bedarf sehr viel Know-Hows um diese Software zu warten.

Code Weaving ist damit sehr gut für die effiziente Erstellung von Prototypen oder PoC (Proof of Concept) geeignet. Es ist danach sehr einfach für normale Softwareentwickler diesen Code in eine Zielsprache wie Java zu übertragen. Nebenbei können die Daten aus dem PoC als Testdaten für Unit- und Integrationstest genutzt werden. Die scheinbar doppelte Arbeit rentiert sich sehr schnell, weil die Entwicklung des Zielsystems wesentlich schneller und in höherer Qualität möglich ist.

Make it run, make it right, make it fast.

Drei Grundsätze der Programmierung: "Make it run, make it right, make it fast.". Wichtig ist, dass sich hierbei um ein Periodisierung geht. D.h. zuerst muss das Programm laufen, erst wenn es läuft, mache es schön, dass es deinen eigenen Ansprüchen genügt und dann erst, zu aller letzt, mache es schnell.

Objektorientierung: Warum braucht man Getter und Setter.

Es lernt jeder, wenn man objektorientiert Programmiere, greifet man auf die Objekteigenschaften mit Hilfe von get (lesen) und set (schreiben) Methoden zu. Wenn ich mit Java programmiere kann ich mir diese Methoden automatisch erstellen lassen, wenn ich Eclipse nutze. Andere Sprachen (Groovy, PHP) bieten an dieser Stelle ein bisschen Magic an, dort braucht man diese Methoden gar nicht mehr selbst erstellen, sondern sie sind da, das ist noch bequemer. Doch einmal stellt mir ein anderer Entwickler die Frage, wozu brauchen wir Getter und Setter? Ich war sprachlos und dachte eine Weile darüber nach. Die Antwort ist, in der Regel braucht man sie nicht, weil sie keinerlei Logik enthalten. Viele Datenklassen (Domain Objekte) sind reine Datenkontainer, wozu brauch ich da noch Getter und Setter? Sie haben keinen Nutzen, sie sind überflüssig. Sie nur zu implementieren um einer Vorschrift zu genügen ist Unsinn. Ich habe jetzt aufmerksam in meinen Code geschaut und ich hatte einige wenige Getter und Setter. Sie enthielten irgend welche Logik, sonst waren meine Klassen durch den Konstruktor konfiguriert oder die Klasse war Zustandslos, als ein mehr ein Service. Fazit, ich brauche keine leeren Getter und Setter, sie bieten keinen Mehrwert, sie sind überflüssig und nutzlos. Ich werde sie auch nicht vermissen.

Indikatoren fürs Refactoring

Refactoring ist in der Agilen Welt ein immer währender, fortlaufender Vorgang. Trotzdem gibt es in vielen Projekten Phasen des Refactorings. Woran erkennt man, das Refactoring dringend angeraten wird:

• Zu viele globale Variablen
• Der Programmierer sagt: "Die Methode kann ich nicht testen."
• Das Projekt verwendet veraltete Bibliotheken oder Plugins
• Hidden Features, niemand weiss von diesem Feature
• Nicht benutzte Features
• Es gibt Integrationstest an Stelle von Unit-Tests
• Vererbung und Abstrakte Klassen (in den meisten Anwendungsfällen)
• Verstoss gegen Clean Code wie:
• Code Duplikate, Verstoß gegen die DRY Regel
• Case Anweisungen mit den Werten 1, 2, 3 ... (Java)
• Eval Anweisungen in JS
• Methoden mit Boolean Parametern
• Zu lange Klassen oder Methoden
• Methoden mit drei oder mehr Parametern
• Methoden mit Parametern die als Ausgabe die dienen

Die Liste ist nicht vollständig, bitte gebt mir Feedback zur Erweiterung der Liste.

Au weia, ich habe die falsche Datei überschrieben ...

was nun, ich habe eine wichtige Datei im Projekt überschrieben und im Subversion liegt auch nur eine alte Version. Eclipse liegt lokale Kopien von den Daten an die man bearbeitet. Wenn man eine solche lokale Kopie wiederherstellen will, muss man im Package Explorer einen Rechtsklick auf die Datei machen und dann in das Menü Restore from Local History ... (siehe Bild).

Damit hat man das erste Problem gelöst, aber da hinter jedem kleinen Problem ein grosses Problem steckt, muss auch dieses Problem gelöst werden. Es zeigt sich also, dass die Richtlinien fürs Codemanagement unvollständig sind oder unzureichend umgesetzt werden. In der Regel gilt, nach jeden Bug Fixing, nach jeden Feature oder nach jedem Refactoring sollte das SVN Repository aktualisiert werden. Übrigens kann man auch sehr einfach ein lokales SVN aufsetzen (Setup a Subversion Server in 4 Minutes). Wenn sich dies nur schwierig im eigenen Entwicklungsprozess umsetzen lässt, dann sollte man einen Blick auf Git werfen.

Nutzen von UML

"Ich stelle fest, dass es zwei Wege gibt, ein Software-Design zu erstellen, entweder so einfach, dass es offensichtlich keine Schwächen hat, oder so kompliziert, dass es keine offensichtlichen Schwächen hat."

T. Hoare

UML ist ein wichtiges Thema in der Ausbildung von Informatikstudenten an den Universitäten. Deshalb ist es nicht verwunderlich, dass alle Uni-Absolventen glühende Verfechter von UML sind. Aber wie sieht es mit der Bedeutung von UML in der Programmierrealität aus? Dazu hatte ich eine kleine nicht repräsentative Umfrage in der Java Usegroup gestartet und möchte hier die Ergebnisse zusammenfassen.
Obwohl eine Mehrheit kein oder kaum UML einsetzt, sind sowohl die Probleme als auch gute Werkzeuge bekannt. Häufig wird UML eingesetzt zum Dokumentieren, zur internen und externen Kommunikation und zur Anforderungsanalyse. UML wird auf einem hohen Abstraktionslevel eingesetzt. Neben diesen Anwendungen gab es auch Forderungen an UML bzw. an die UML-Werkzeuge. Die wichtigsten sind die Integration in die IDEs, die Möglichkeit des Roundtrips und damit einer agilen Entwicklung mit UML. UML wird als statisch und kompliziert in der Anwendung wahrgenommen. Damit stellt sich die Frage, liegt dies an UML oder an den Werkzeugen?

Der richtige Umgang des Programmierers mit Passwörter

Viele Anwendungen wie der Apache Webserver oder andere haben ein eigenes Passworthandling. Trotzdem ist man als Programmierer machmal gezwungen sich selbst um das Handling der Passwörter kümmern. Die meisten selbstentwickelten Lösungen der Programmierer sind oft mäßig bis unzureichend. Das liegt auch daran, dass es während des Informatikstudiums keine oder nur selten entsprechende Vorlesungen oder Seminare gibt. Hier jetzt ein paar Regeln Regeln zum besseren Umgang mit Passwörtern.

• Akzeptiere nur ausreichend lange Passwörter um Brute Force Attacken zu erschweren. Zur Zeit gelten Passwörter mit 8 und mehr Zeichen als akzeptabel.
• Passwörter sollten nicht mit dem Benutzernamen identisch sein. Das wäre zu leicht zu erraten.
• Passwörter sollten nicht Personennamen sein und auch möglichst kein normales Wort sein, auch sollte man nicht nur die Jahreszahl an eine Personennamen hängen. Diese Passwörter können durch Wörterbuch-Attacken ermittelt werden. Sinnvoll wäre immer eine Etropieprüfung der Passwörter.
• Das Passwort sollte kein Tastaturmuster ala QWERTZU sein. Diese Passwörter sind auch anfällig für Attacken.
• Passwörter sollten vom Programmierer nie als Klartext gespeichert werden. Passwörter sollten immer mit einer sicheren Hash-Funktion verarbeitet werden. Anschliessend wird dann der Hash-Wert gespeichert. Z.B. gelten zur Zeit SHA2 und MD5 als sicher. Durch das hashen ist es einem Eindringling nicht möglich die Passwörter im Klartext zu ermitteln.
• Zusätzlichen Schutz bietet der Einsatz eines Salt. Dieser Salt wird dann zusätzlich zum Hash-Wert des Passworts gespeichert. Der Salt verhindert den Angriff von Eindringlingen via Rainbow Table.

Prinzipiell sollte man beim Schutz von Daten immer mehrere Verteidigungslinien aufbauen und sich nicht allein auf eine Schutzmassnahme verlassen. Oft zieht ein Einbruch weitere Einbrüche nach sich, wie z.B. auch bei der Apache Foundation (http://www.golem.de/1004/74458.html).

7FHFWF5TMNZC

Brownfield Projekte

Nicht alle Projekte starten auf einer grünen Wiese oft oder meistens beziehen sich Projekte auf vorhandene Software, den so genannten Brownfield Projekten. Wie kann man trotz dieser existierenden und oft laufenden Software die Grundsätze der CCD (Clean Code Developer). Mit diesem Thema beschäftigen sich zwei Artikel auf Heise Developer. Ich denke vielen Entwicklern werden einige Dinge bekannt vorkommen.

Joel on Software

Es ist schon erstaunlich, dass viele Entwickler ähnliche Probleme haben, zumindest die Guten :-D. Hier ein interessanter Blog: Joel on Software von Joel Spolsky. Joel Spolsky ist ein ehemaliger Fallschirmjäger und Microsoftentwickler. Ob es zwischen diesen Fähigkeiten einen Zusammenhang gibt? In dem Blog geht es um gutes und natürlich schlechtes Projektmanagement aber auch um Programmierdinge (z.B. Blähsoftware, Bytes oder der Joel-Test). Einige Beiträge von 2000 bis 2009 sind auch auf Deutsch verfügbar. Man kann auch bei der Übersetzung helfen. Spontan meine liebste Stelle:

...

Aber ich mache mir nicht über die Tage Sorgen, an denen ich "nur" zwei Stunden arbeite. Es sind die Tage, an denen ich gar nichts tue.

...

Interessant ist auch der Joel-Test, obwohl er schon fast 10 Jahre alt ist, erfüllen immer noch nicht alle Softwarefirmen den Test. Selbst wenn man den Test nicht kennt, so ist sein Inhalt doch für alle guten Programmierer keine Überraschung sondern sollte der Normalfall sein.

Die Forderung des Test eines One-Click-Build passt gut zu Maven und Ant und zu diesem Blog. Ja und ich habe einen zweiten Monitor.

CCD: clean code developer

Viele Dinge in diesem Blog thematisieren die täglichen Probleme. Auch gibt es paar etwas grundlegendere Beiträge nur leider keine grundlegende Verarbeitung dieser Dinge. Ich hatte mir das alles auf einen späteren Zeitpunkt verschoben. Das ist dann wohl zu spät. Aber ich freue mich auf die folgende Webseite hinzuweisen: CCD: clean code developer bzw. auf das Interview.

Ich glaube alle Prinzipien dieser Seite kann ich gutes Gewissens empfehlen, weil ich sie aus meiner Erfahrung selbst anwende und meinen Studenten rate. Die dort beschriebenen Prinzipien lassen sich durch eine Reihe von Werkzeugen sinnvoll unterstützen. Dazu werde ich demnächst einen Beitrag schreiben.

Vereinheitlichung von GUIs komplexer Applikationen

In vielen komplexeren Projekten hat man das Problem das verschiedene Leute GUI-Teile implementieren. Das führt in vielen Fällen zu einer inkonsistenten GUIs. Dieses Problem kann man auf verschiedenen Wegen angehen. Der Weg 1 wäre einen eigenen Style Guide zu entwickeln und umzusetzen. Dieser Weg erzeugt sehr gute Resultate ist aber aufwendig. Bei der Umsetzung in Java hat man zusätzlich das Problem, dass einige Anforderungen des Style Guides in den Java-Klassen selbst umgesetzt werden müssen andere Dinge hingegen eine Anpassung des Look and Feels (L&F) erfordern.
Der 2. Weg ist pragmatischer und wesentlich einfacher und schneller umzusetzen, dafür sind die Resultate nicht ganz so gut, stellen aber in den meisten Fällen eine wesentlich Verbesserung gegenüber der Ausgangssituation dar. Folgende Regeln sind dafür umzusetzen:

• Verwendung möglichst wenigen Layout Manager z.B. BoxLayout, wenn komplizierter ist und sonst BorderLayout bzw. FlowLayout für Button-Reihen
• Einen Entwickler montiert bzw. überarbeitet der alle Oberflächen
• Convenience Methoden z.B. wenn man Textabschnitte bold setzt
• Minimale und sehr einfache Klassen die alle Entwickler nutzen z.B. für Fenster, dort sind dann Font, Rahmen und Layoutmanager werden schon richtig gesetzt
• Kreuzprüfung der GUI-Teile, d.h. die Entwickler testen die GUI-Teile die von anderen Entwicklern erstellt wurden

Diese Punkte garantieren kein einheitliches L&F der Oberflächen aber sie wirken Wunder und kosten fast nix. Ein weiterer wichtiger Punkt wenn es um das Interface zwischen Maschine und Mensch geht ist die Usability. Aus meiner Sicht ist es wichtig nicht nur in den Evaluationsphase Usability-Tests einzusetzen sondern schon in der Konzeptionsphase. Usability sollte den Entwicklungsprozess begleiten. Hier der Link zur bekanntesten Usability-Web-Seite. ES lohnt sich immer auf dieser Seite zu stöbern.

Develop your developers

Tests ein mal anders. JavaBlackBelt ist ein Community-Website, die Test und Kurse zu vielen aktuellen Themen bietet. Diese stammen primär aus dem Bereich der Java-Programmierung. Je nach dem, wie viele Examen man erfolgreich absolviert hat bekommt man einen entsprechenden, farbigen Gürtel. Der schwarze Gürtel ist dann der höchste zu erreichende Gürtel. Natürlich stellt sich bei einigen Test die Frage, wie relevant sie in der Praxis sind und ob es sich bei dem Code nicht um gefährlichen Code (potentieller Bug) handelt. Trotzdem ist es aus meiner Sicht eine sehr gelungene Site.

Log4J Pattern Layout

Oft hat man beim Logging das Problem, dass ein Logmeldung länger ist als eine Zeil auf dem Bildschirm. Das führt dazu dass diese lange Zeile am Bildschirmrand umgebrochen wird. Für den Programmierer ist dies auf den ersten Blick nicht immer zu sehen, wo die Zeile weitergeht. Für mehr Übersichtlichkeit kann man durch folgendes Pattern sorgen:

< layout class="org.apache.log4j.PatternLayout">
        < param name="ConversionPattern" value="%d [%t] %-5p %c.%M%n: %m%n" />
</layout>

Das ergibt dann folgendes:

2009-07-08 06:59:06,470 [main] INFO  me.alif.App.
App starts up

Bei diesem Pattern wird der Inhalt der Logausgabe, also dass was der Programmierer in die Klammer des Log-Methodenaufruf schreibt, in einer neuen Zeile ausgegeben, die mit einem Doppelpunkt beginnt. Dies führ aus meiner Sicht zu einer höheren Lesbarkeit der Log-Ausgabe.

Fluent Interface - schlechter Stil hat einen Namen

Gester oder war es Vorgestern bin ich gleich zweimal auf ein Problem gestossen, dass einige Programmierer in einer Codezeile lange, komplexe, häufig ineinander geschachtelte Anweisungen schreiben. In einigen Fällen sieht da sehr elegant aus und es spart Platz, d.h. man muss nicht so viel scrollen im Editor. Diese Art des Code Schreibens hat aus meiner Sicht zwei Mankos, auch wenn ich weniger scrollen muss sinkt die Verständlichkeit des Codes und wenn ein Fehler in dieser Zeile auftritt (Nullpointer in Zeile 137), muss diesen Ausdruck zerlegen um den Bug zu finden. Aus diesem Grund halte ich auch trinäre Ausdrücke für potentielle Fehler.

Daraufhin habe ich in der Newsgroup de.comp.lang.java den Verweis auf die Idee des Fluent Interface gefunden. Die oben beschrieben Art der Programmierung ist kein Fluent Interface. Fluent Interface ist eine elegante Art der Programmierung die vor allem Domain-spezifisch, sehr effizient sein kann. Der Vorteil der Natürlichsprachlichkeit dieser Ausdrücke halte ich nicht unbedingt für einen Vorteil, das mag vielleicht auch mit mit meinen mit Lingo (Macromedia Director, jetzt Adobe Director) gemachten Erfahrungen zusammenhängen. Die Natürlichsprachlichkeit war ja ein Kernfeature von Lingo.

Projektmanagementfehler

Hier ein Sammlung meiner liebsten Projektmanagement-Fehler:

• Es wird eine neue Software  entwickelt die am Markt verfügbar ist, aber in schlechterer Qualität.
• Projekte mit diversen Unterprojekten werden ohne Koordinator versucht.
• Projekte mit diversen Unterprojekten werden ohne Integrationskonzept und ohne Personalaufwand für die Integration versucht.
  
• Einheitliche Richtlinien für grosse Projekte werden nicht entwickelt oder nicht umgesetzt bzw. es wird die Umsetzung wird nicht überwacht.
• Usability wird als Beiwerk in Projekten betrachtet.
• Projektpläne werden nicht an veränderte Bedingungen angepasst.
• Hippe Techniken werden ohne Rücksicht auf die Bedingungen im Projekt eingesetzt.
• Erkannte Architekturfehler werden ignoriert.
• Komplexe Projekte werden ohne Entwicklungsiterationen versucht.
• Zeitverzug in Projekten wird ignoriert, es wird dann auf auf die Selbstheilungskräfte im Projekt gesetzt.
• Man ignoriert elementare Anforderungen des Kunden um sich selbst zu verwirklichen.
• Man lässt den Kunden alles Bestimmen (zu diesem Thema gibt es übrigen eine Simpsons-Folge in der Homer ein Auto entwirft).
• Gute Projektidee werden durch mangelhafte Benutzeroberflächen sabotiert, weil bei der Planung niemanden Aufgefallen ist, dass die Software durch eine GUI bedient werden soll. Selbst nach dem erkennen dieses Problem werden keine Ressourcen in die GUI investiert unter dem Motto "Wir haben eine Software mit den versprochenen Funktionen umgesetzt.", dass Niemand sie bedienen kann ist nicht unser Problem.
• Schwierigkeiten in Projekten werden nicht konsequent angegangen sondern es wird entweder versucht das Problem zu ignorieren (Probleme die ich nicht sehe sind auch nicht da.) oder es wird herum lamentiert und die sich Sachen schöngeredet und versucht es nicht wie einen Fehler aussehen zu lassen.

Ant vs. Maven

Die Frage nach den richtigen Build-Tool. Ja gibt es da überhaupt? Ich habe jetzt über viele Jahre mit Ant gearbeitet und damit auch komplexe Projekte gebaut. Einige Highlights: Integration von C++, Deployment zu verschiednen Tomcat-Instancen, automatische Adaptation an Kunden und parallele Ausführung von Build-Teilen. Ich habe ein gutes Verständinis von dem was Ant kann und wie Ant funkioniert. Etwas was immer wiederkehrte war, das ich zwischen den verschiednen build.xml Dateien Code hin und her kopierte und das ich gleichzeitig begann die Projektstruktur und den Build-Prozess zu vereinheitlichen. Dann kam Maven. Die ersten frühen Versuche schlugen fehl. Die Gründe dafür waren die andere Philosophie von Maven (Convention over Configuration), die Intrasparenz was wann passiert und die Integration in Eclipse erschien mir nich so hilfreich. Ich blieb erst mal bei Ant.
Das nächste Erlebnis war auch nicht viel Besser, trotzdem versuchte ich es noch ein mal. Ich migrierte ein größeres Projekt von Ant zu Maven. Ja es funktionierte. Dafür benutzte ich das Eclipse-Plugin m2eclipse. Alles gut? Ja, aber ich hätte da noch ein paar kleine Wünsche:

• Einfachere Integration fremder Jar's in das Projekt
• Einfache Übernahme der Maven-Konfiguration zwischen verschiedenen Rechnern
• Bessere, einfachere Suche nach Jar's (Dependencies)
• Automatische Mirror-Konfiguration
• Verbinden der Konsolenausgaben (Fehler) mit Eclipse
• Automatisches Deployment von War's via Tomcat Manager
  

Mein Fazit, ich werde weiter auf Maven setzen und spezielle Dinge (Projekt-Adaptation) mit Ant erledigen.

Hier noch eine kleine Ant-Referenz: