Thoughts on agile software development
Software Prinzipien
Beginnt man sich mit einer agilen Methode wie Scrum zu beschäftigen, dann lernt man relativ schnell, dass viele Dinge vom Team entschieden werden. Das hört sich im ersten Moment für die Team Mitglieder sehr gut an, bedeutet aber auch, sich einmal mit dem Thema Entscheiden zu beschäftigen.
Dieses Beitrag handelt nicht von dem bekannten Code Smell Refused Bequest (dem ausgeschlagenen Erbe), sondern von den vielen Featuren bekannter und unbekannter Bibliotheken, die in Vergessenheit geraten. Bei manchen dieser Bibliotheken wird man irgendwann auf die unangenehme Art auf die vergessenen Möglichkeiten hingewiesen. So wie jüngst die Bibliothek Log4j2 mit den Security Vulnerabilities CVE-2021-44228, CVE-2021-45046 und CVE-2021-45105.
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.
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.
Die Fehlerbehandlung in der Programmiersprache Java folgt einigen einfachen aber mächtigen Mustern. Dennoch zeigt sich immer wieder die Tendenz, auf erschreckende Weise davon abzuweichen.
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.
Die Anforderungen für einen Entwickler Team muss man sich als einen Baum vorstellen, bei dem zu Beginn nur der Stamm zu sehen ist. Der Rest des Baumes ist in Nebel gehüllt. Das dort oben eine Baumkrone vorhanden sein muss, ist dem Entwickler klar, und einige Äste sind im Nebel verschwommen zu erkennen.
In der objektorientierten Softwareentwicklung können Objekte in zwei unterschiedliche Kategorien eingruppiert werden. Entweder sie sind nicht veränderbar (immutable) oder veränderbar (mutable).
Diese Unterscheidung hat nicht nur eine philosophische Größe, sie zeigt auch Konsequenzen in der tagtäglichen Programmierung. Der Großteil der Klassen, mit dem der Entwickler in Berührung kommt sind Mutables.
“To be or not to be, that is the question” sprach Hamlet und legt damit allen Entwicklern die entscheidende Frage in den Mund “Ist das eine gute Idee oder mache ich hier Blödsinn?”. Die Frage ist leider oft nicht so einfach zu beantworten, es gibt zu viele Grautöne zwischen dem Schwarz und Weiß.
Für viele Entwickler und Manager ist das Thema Eleganz und Schönheit in der Software Entwicklung ein untergeordnetes Thema, falls sie sich überhaupt schon einmal Gedanken dazu gemacht haben. Häufig steht man diesen Begriffen mit einem gewissen Misstrauen gegenüber. Nicht umsonst gibt es den fatalen Aufruf “Schöner machen könnt Ihr später!”, dem in der Regel keinerlei Nacharbeiten folgen.