Unit Tests, die Maurerschnur der Software Entwickler

Das Zitat “die Unit Tests schreibe ich
immer zum Schluss” hat vermutlich schon jeder Entwickler von einem Kollegen hören müssen. Üblicherweise, wenn man bei einem schwerwiegenden Problem während der Implementierung helfen möchte. Ein kurzer Blick auf die Testergebnisse hilft dann enorm. Häufig zeigen die fehlgeschlagenen Unit Test direkt auf das Problem. Fehlen die Unit Tests, dann müssen sich die Entwickler solange durch GIT Historie und Debugger quälen, bis der eingeschleppte Fehler gefunden ist.

Das Tool

Agile Manifesto

Welcher Software Entwickler kennt nicht die Geschichte vom neuen Tool, das seine Arbeit enorm voranbringen soll. Die Firma schafft für jeden Entwickler eine Lizenz an und alle werden auf das neue Tool geschult. Drehen wir die Uhr dann einige Monate weiter, dann hat sich die Gruppe der Entwickler in mehrere Fraktionen aufgespalten. Eine kleine verschworene Gruppe von Nutzern, eine großen Fraktion von Kollegen, die das Tool unter Ihresgleichen verdammen und einer kleineren Fraktion von Entwicklern, die das Tool nicht mehr benutzen.

@Deprecated Deadlock

Beim Aktualisieren von Bibliotheken finden sich immer wieder Methoden, die nicht mehr zeitgemäß sind. Denn häufig ermöglichen neuere Ansätze kompakteren, einfacheren oder eleganteren Code. Um den Nutzern der Bibliothek das Leben nicht zu erschweren, werden solche Methoden als veraltet (@Deprecated) markiert. Damit beginnt eine Gnadenfrist, in der die Nutzer ihren eigenen Code auf die neuen Alternativen umbauen müssen. Diese Frist endet, wenn die Entwickler der Bibliothek die veralteten Methoden löscht.

Kanban – alles fließt!

Viele Konzepte sind so einfach, dass man kaum Ideen findet um einen neuen Blickwinkel aufzuzeigen. Leider gibt es aber auch kein Konzept, das zu einfach für eine fehlerhafte Nutzung wäre.
Kanban ist eine beliebte Methode in der IT, weil ihre Einführung trivial ist und ein Nutzen schnell erkennbar wird.

Smaugs Einöde

Manche Probleme werden von den Kollegen nur erkannt, wenn wir für sie drastische Vergleiche entwerfen. Ohne die Bilder einer anderen Gefahr vor dem inneren Auge, werden organisatorische Defizite häufig mit einem Achselzucken hingenommen. Wer kennt ihn nicht Smaug den Drachen? In meiner Jugend wussten tatsächlich nur die Liebhaber von Sagen und phantastischen Geschichten von ihm, viele von ihnen genauso computerbegeistert wie der Autor. Seitdem der Hobbit nun, in viel zu vielen Teilen, verfilmt wurde, ist die Geschichte von Smaug ins kollektive Gedächtnis gewandert.

Mikroservice Patterns (Database Per Service)

Mikroservices stellen ein eigenes Architekturkonzept dar, mit denen Anwendungen dezentral und entkoppelt entwickelt und betrieben werden können. Eine große Anzahl von Design Pattern macht es den Entwicklern dabei einfach, gute Architekturen zu erstellen. Die Mikroservices Architektur wirkt sich jedoch nicht nur auf die Software aus, sondern bietet auch viel Potenzial um die Arbeit der Teams zu verbessern. Wie dies im speziellen aussehen kann soll an dem sehr grundlegenden Pattern Database Per Service dargestellt werden.

The Art of Test

Das Testen der Software ist fast genauso wichtig, wie deren Implementierung. Bei der Implementierung von komplexen Systemen müssen Entwickler und Kunden prüfen können, ob das erstellte Werk auch allen Anforderungen entspricht und korrekt arbeitet. Aus diesem Grund werden beide Tätigkeiten beim Test-Driven-Development auch miteinander verbunden. Schwierigkeiten bereitet es häufig, welche Art von Test wann und wie verwendet werden sollte.

Muda – die Mudda aller Missstände

In manchen Diskussionen versteigt sich der Software Entwickler ins Japanische und spricht von Kaizen, Mura und Muri, Seiri und Seiton. Diese Begriffe stammen alle aus dem Bereich des Lean-Managements, mit dem die japanischen Hersteller die Produktionsverfahren revolutioniert haben.

To Cut A Long Story Short

Der Product Owner hat die Aufgabe, dem Development Team zu erzählen, was der Kunde benötigt. Das klingt erst einmal sehr einfach, ist aber eines der größten Probleme der Software Entwicklung.

Ab die Post (Teil 3)

Wer kennt diese Situation als Software Entwickler nicht. Man hat eine nette kleine Idee und statt sie direkt zu implementieren, bespricht man sie mit einem Projektverantwortlichen. Plötzlich wächst die Idee zu irgendetwas heran, das ohne wirklich weiteren Wert zu bieten, mehrere Tage bis Wochen Vorbereitung und Implementierung benötigt. Als junger Entwickler hörte ich, im Zuge einer eigenen kleinen Idee, zum aller ersten Mal von den U-Booten.