Heute bin ich im Newsletter von golem.de auf das Online-Buch „Scrum-Kompakt“ von itemis gestoßen, was ich jedem LessCoder als Einführung und Referenz zu Scrum ans Herz legen kann.

» Weiterlesen: Gegenwind

Heute war ich in Karlsruhe in einem Workshop im Rahmen der Entwicklertage. Thema: „Durchstarten – Agile Softwareentwicklung mit Hibernate, Spring, Eclipse„. Ich habe diesen Workshop bewusst gewählt, da sie laut Beschreibung den Anspruch hat, agile Praktiken anhand dieser Technologien zu zeigen. Das hat sie auch voll erfüllt, keine Frage.
Allerdings sah ich mich auch in meiner Meinung bezgl. der „Geschwätzigkeit“ dieses Technologiestacks voll bestätigt. DRY ist anders. Es handelte sich um eine für einen Workshop vorbildhaft große Beispielapplikation, an der wir diverse agile Methoden praktizierten, also Einarbeitung in ein fremdes Projekt, Feautererweiterung im Sprint, Bugfixing von Legacy-Code usw.

» Weiterlesen: Agile Softwareentwicklung mit Hibernate, Spring, Eclipse

Ich habe schon oft über das Phänomen nachgedacht, aber noch nie einen passenden Begriff dazu gefunden. Und gestern auf dem JUG-KA-Vortrag fiel er endlich: „Ravioli Code“
Der Begriff „Spaghetti Code“ sollte bekannt sein. Er beschreibt die Unübersichtlichkeit von Code aufgrund wilden Hin- und Herspringens.
„Ravioli Code“ beschreibt, dass der relevante Businesscode über zu viele kleine (in diesem Fall Java-)Klassen verteilt ist und man sich deshalb den Programmablauf mühsam aus all diesen „herausfischen“ muss. Also bspw. um am Ende 25 Zeilen Businesslogik zu verstehen ist es notwendig, das Zusammenspiel von 10 verschiedenen Klassen zu analysieren.
Ich bezeichne dieses Symptom, das m.E. in der Javawelt oft anzutreffen ist, gerne als „Over-Engineering“, und ist mit ein Grund für die Idee von LessCode.
Ich bin mir sicher, dass das alles etwas weniger dramatisch wäre, wenn die Sprachsyntax von Java endlich mal Closures bekäme, aber nichtmal für Java 7 wird es wohl so sein.

» Weiterlesen: Ravioli Code

Ein anderes Flurthema auf der JUG-KA war mal wieder statisch vs. dynamisch typisierte Programmiersprachen (konkret: Ruby und Python vs. Java)
Die Java-Fraktion fühlt sich sicher dank Typüberprüfung schon zur Compilezeit oder während der Code-Erstellung und  fühlt sich wohl durch die IDE, die Code Completion und die Refactoring Tools.

» Weiterlesen: Statische vs. Dynamische Typisierung: Overengineering im Kleinen?

Gestern abend war ich auf einer Veranstaltung der Java-User-Group Karlsruhe.
Das Thema war „Testgetriebene Entwicklung – vom Dogma zum Pragmatismus“ vorgetragen von Martin Schneider und allein schon durch die ähnlichen Taglines (LessCode proklamiert „Pragma statt Dogma“), musste ich mir das anhören.
Beeindruckend fand ich die systematische Erfassung der „test smells“ (analog der „code smells“ von Kent Beck): Es geht um die Kategorisierung von nicht optimalen Tests. Z.B. gibt es Tests, die deshalb nicht gut sind, weil sie zuviel auf einmal testen, weil sie ein zu komplexes Testsetup erfordern, Tests die kopiert und nur wenige Zeichen abgeändert werden oder Tests, die nur manchmal fehlschlagen (Eine Auflistung findet sich z.B. hier)

» Weiterlesen: Vortrag JUG Karlsruhe: Extremes Testen