Thoughts on agile software development
Jens 
Die Enums in Java sind eine typsichere Alternative zu den früher verwendeten Konstanten. Mit solchen Konstanten hat man die üblichen Probleme, dass man sie überall fehlerhafter Weise einsetzen oder anstelle der Konstanten andere Werte des Typs verwenden kann. Besser also der Einsatz von Enums, die als echter Typ nur die definierten Konstanten zulassen. Enums erlauben … Read more
Haben Sie manchmal auch das Gefühl, dass ihre Kollegen Angst vor boolschen Ausdrücken haben? So mancher scheint die De Morganschen Gesetze wie die dunklen Zauberkünste einer Morgan le Fay zu fürchten. So bleiben dann auch Ausdrücke, wie der folgende, für Ewigkeiten im Programmcode. Häufige verweisen die Entwicklern auf den Optimierungen des Compilers, wenn sie ihre boolschen Ausdrücke … Read more
Was hat ein Familienausflug mit agilen Teams zu tun? Vielleicht schauen wir einmal zwei Familien dabei zu. Die erste Familie spaziert durch den Wald, die begeisterten Kinder laufen vor und fallen zurück, aber der gesamte Tross ist stetig und zügig unterwegs. Die Stimmung locker und alle gut gelaunt. Obwohl die Kinder auch immer wieder hinter … Read more
schaut man in die Ansammlungen von Unit Tests, die sich im Laufe der Zeit in Projekten anhäufen, stellt man häufig folgendes fest: Es ist nicht klar, was alles getestet wird. Weder der Name noch der Inhalt der Methode lassen direkt auf den Zweck schließen Die Konstruktion der Testdaten ist in andere Klassen ausgelagert Der Abgleich … Read more
Manche Entwickler halten Copy&Paste für das schlimmste Anti-Pattern in der Software Entwicklung. Leider muss man ihnen sagen, dass es noch schlimmer geht. Cargo Cult Programming ist die Verwendung von Pattern ohne sie zu verstehen. Dabei kopieren die Entwickler bestehenden Programmcode in der oft irrigen Annahme, dieser Programmcode wäre notwendig. Der folgende Programmcode entstammt einer tatsächlichen existierenden … Read more
“Never assume software developer skills when stupidity will suffice“
Jens Kaiser
Basierend auf Hanlon’s Razor und dem Paretoprinzip, besagt diese Regel, dass man grundsätzlich von fehlerhaften Sourcecode ausgehen sollte. Man investiert ansonsten zu viel Zeit, um nicht vorhandene Design-Pattern oder absichtsvolle Algorithmen zu entdecken.