Was Entropie mit Softwareentwicklung zu tun hat

Obwohl alle vorherigen Posts mit einem Zitat oder einer kurzen Geschichte begannen, werde ich das nicht so weiterführen ;) Nur weil etwas immer so war, heisst das nicht, dass es auch so bleiben muss. Genau so ist es auch in der Softwareentwicklung. Ein weiser Mann hat zum Beispiel erkannt, dass man die Verständlichkeit und Lesbarkeit unseres Codes verbessern kann, wenn man die Funktion «FillAuto» in «BindModel» umbenennt. Der ursprüngliche Name der Funktion sagte überhaupt nichts darüber aus, was im Code passiert. Jeder hat es zwar mit der Zeit gewusst, aber neue Mitarbeiter waren regelmässig verwirrt. Der weise Mann hat es gewagt, eine Tradition in unserem Code zu hinterfragen und eine positive Veränderung herbeizuführen.

Genau darum geht es in diesem Blog-Post. Wir schreiben Code, der Code verändert sich, unser Wissen wächst. Code hat leider eine negative Eigenschaft: Wenn man nicht sehr bewusst herangeht, wird er mit jeder Modifikation komplexer. Die Entropie steigt. Irgendwann kommt der Punkt, wo der bestehende Code den Ansprüchen einer neuen Story nicht mehr genügt. Sei das, weil der ursprüngliche Code nur als Prototyp gedacht war, weil die Performance nicht mehr ausreicht oder wir in der Zwischenzeit neue Patterns eingeführt haben: spätestens hier sollte man eingreifen und fordern, was einem zusteht: die Zeit für ein Refactoring. Aber nicht nur Refactorings tragen zur Qualität bei. Automatisierte Tests, gut definierte Akzeptanzkriterien, sauber durchgeführte Code Reviews und selbstverständlich auch das Mindset haben einen grossen Einfluss.

Plane Zeit für Unit-, Integration- und User-Interface-Tests ein.

Es dauert zwar etwas, die Tests zu schreiben, aber im Gegenzug erhältst du eine Art Versicherung, dass dein Code wie gewünscht funktioniert. Ausserdem hilft der Test später anderen Entwicklern, deinen Code zu verstehen und allfällige Bugs frühzeitig zu erkennen. Und du lernst, Klassen zu entkoppeln und den Code testbar zu halten. Tests schreiben macht dich also zu einem besseren Entwickler! Falls du mehr zu Testing erfahren willst, kann ich diesen Beitrag empfehlen.

Plane genügend Ressourcen für die CATs ein.

CAT = Code reviewen, Akzeptanzkriterien prüfen & Testfälle durchspielen.
Sei dir auch bewusst, dass ein CAT mehr ist als nur ein Code Review. Der Code kann noch so schön strukturiert und verständlich sein. Wenn die Akzeptanzkriterien nicht erfüllt werden, ist die Story nicht komplett. Sieh CATs nicht als Qual, sondern als Herausforderung. Als Reviewer lernst du andere Storys besser kennen und kannst dein Wissen einfliessen lassen. Als Review-Empfänger wirst du auf Probleme und Verbesserungsmöglichkeiten hingewiesen, die dich zu einem besseren Entwickler machen!

Und zu guter Letzt: Sei immer motiviert, möglichst gute Qualität abzuliefern.

Hol dir schon in der Anfangsphase der Story Feedback von anderen Entwicklern und dokumentiere deine Umsetzung und Erkenntnisse, damit auch andere von deinem Wissen profitieren können. Das macht euch alle zu besseren Entwicklern! (und bitte kompiliert euren Code zuerst lokal, bevor ihr etwas ins Repository pusht. Das macht euch zu beliebteren Entwicklern ;))

Wie ihr seht, werdet ihr automatisch bessere Softwareentwickler, wenn ihr motiviert bleibt und stets Wert auf Qualität legt.
Jetzt will ich aber doch noch ein Zitat loswerden:

Programmieren Sie immer so, als wäre der Typ, der den Code pflegen muss, ein gewaltbereiter Psychopath, der weiss, wo Sie wohnen.

Unser Manifest

Unser Manifest überzeugt dich?

Oder es überzeugt dich nicht, aber du möchtest trotzdem bei uns entwickeln? Wir haben folgende Stellenangebote in der Softwareentwicklung:

• Stelleninserat Junior Softwareentwickler
• Stelleninserat Softwareentwickler
• Stelleninserat Senior Softwareentwickler

Grammatik

Wer bemerkt den absichtlich nachsichtig tolerierten grammatischen Fehler in unserem vierten Manifest?