Software-Entwickler, die belesen sind haben Sprichwörter im Kopf, die einen hohen Informations- und Wahrheitsgehalt besitzen. Diese Sprichwörter helfen bei der täglichen Arbeit und geben Halt bei der Umsetzung komplexer Software. Dieser Blogbeitrag zitiert Sprichwörter aus der Literatur und versucht eine eigene Interpretation und zusätzliche Informationen wiederzugeben.
When in doubt, leave it out (Joshua Bloch)
Joshua Bloch hat dieses Sprichwort im Rahmen der API-Entwicklung "How to Design a Good API & Why it Matters" geprägt. Eine API muss bei der Publizierung stabil sein. Die spätere Änderung einer API ist nicht möglich, weil eine Änderung die Verwender der API stark beeinflussen würde. Im Zweifel über eine API-Funktion ist es deshalb besser, die Funktion nicht in die API mit aufzunehmen.
Ich bin der Meinung, dass man das Sprichwort verallgemeinern kann. Es sollten nur der Quellcode und die Konfigurationen in ein Softwareprodukt aufgenommen werden, welcher der Autor der zu entwickelnden Applikation erfasst hat. Diese Aussage klingt zunächst einmal selbstverständlich, ist es allerdings keineswegs. In komplexen Software-Projekten spielt nicht nur die Programmierung eine Rolle, sondern auch die verwendeten Frameworks und ganz besonders die Laufzeitumgebung. Ein Entwickler muss also die verwendeten Frameworks und deren Schwachstellen kennen und die Laufzeitumgebung beherrschen. In der Laufzeitumgebung ist die richtige Transaktionssteuerung und das angemessene Locking passend zur Architektur der Applikation zu wählen. Gerade in diesen Bereichen treten immer wieder Probleme nach der Umsetzung einer Applikation auf, die sich durch schlechte Performanz bis hin zum Stillstand einer Applikation bei Last äußern.
Bei diesem Sprichwort hat auch die "Root Cause Analysis" eine Bedeutung. Ein Entwickler läuft auf einen Meilenstein zu und es sind noch bekannte Probleme in einer Software vorhanden, die das Ziel des Meilensteins gefährden. In diesem Szenario ist es besser, das Ziel zu reduzieren, als eine nicht stabile Implementierung in ein Produkt fliessen zu lassen. Keinesfalls sollte man einen Workaround akzeptieren, sondern dem Problem auf den Grund gehen, als Change Request (CR) markieren und in der Folge in das Produkt übernehmen.
Fake it till you make it (Kent Beck)
Dieses Sprichwort ist einer der Eckpfeiler von TDD. Ausgehend von Unit-Tests eine Software mit Mock-Objekten, die von einem Mock-Framework (zum Beispiel: Mockito oder EasyMock) stammen, schrittweise aufzubauen.
Unit-Tests, die auf Mocks basieren, sind notwendig, aber nicht immer ratsam. Im Java EE Umfeld können durch den leichtgewichtigen Ansatz auch Unit-Tests geschrieben werden, die direkt die Facade einer Applikation ansprechen. Bei diesem Szenario, gibt es keinen Unterschied zwischen einer Client-Applikation und dem Unit-Test. Beide Komponenten verwenden die gleiche Facaden-Schnittstelle. Last mit Unit-Tests über die Facade zu produzieren ist dabei durchaus möglich.
Make it work then make it right (Kent Beck)
Im TDD Kontext arbeitet man auf Basis dieses Sprichwortes. Ausgehend vom roten Balken eines Unit-Test arbeitet man sich zu einem grünen Balken vor, der einen erfolgreichen Testlauf signalisiert. Dabei spielt die Qualität eines Quellcodes zunächst eine untergeordnete Rolle. Ziel ist es, den grünen Balken zu sehen. In der Folge wird die Qualität des Quellcodes schrittweise durch Refactoring verbessert, wobei zwischen den einzelnen Schritten immer wieder der Unit-Test ausgeführt wird. Fehler werden durch das Häufige ausführen des Unit-Tests sehr früh bei der Programmierung gefunden.
Das Sprichwort ist auch dem Umstand geschuldet, dass selbst der erfahrenste Entwickler nicht jede Funktionalität im ersten Schritt in bester Qualität und ohne Fehler schreibt. Fehler dürfen deshalb bei der Programmierung zunächst einmal gemacht werden. Die Quellcode-Qualität muss nicht sofort stimmen. Nach der Fehlerfreiheit, darf allerdings in keinem Fall das Refactoring vergessen werden. Die Kombination aus Refactoring und wiederholbaren Unit-Tests geben dem Entwickler ein sicheres Gefühl. Durch das Vorgehen in kleinen Schritten, ist man stets zufrieden ohne dabei durch die Komplexität einer Software frustriert zu werden.
Three strikes and you refactor (Martin Fowler)
Mit diesem Sprichwort drückt Martin Fowler aus, dass ein Refactoring drei Auslöser haben kann. Refactorings sollen demnach stattfinden, wenn eine Software um neue Funktionalitäten ergänzt wird, ein Fehler zu finden ist oder bei einem Quellcode Review.
Wesentlich bei dem Sprichwort ist, dass Martin Fowler das Refactoring und Unit-Tests zum Verstehen des Quellcodes nutzt. Durch das Refactoring des Quellcodes wird das Verständnis für den unter Umständen fremden Quellcode und dessen Transparenz gefördert.
If it stinks, change it (Grandma Beck decorated by Kent Beck and Martin Fowler)
Dieses Sprichwort ist eine deutliche Aufforderung einen "Code Smell" durch Refactoring zu bereinigen. Martin Fowler hat in seinem Buch "Refactoring - Improving the Design of existing code" Code Smells identifiziert und Patterns zum Auflösen der Code Smells definiert. Ein Refactoring kann auf Basis dieser Patterns standardisiert ablaufen ohne die Angst haben zu müssen, dass man sich im Quellcode verläuft. Ein temporäres Verlaufen, wäre allerdings nicht sonderlich tragisch, weil das Refactoring durch Unit-Tests unterstützt wird, die die Sicherheit geben, eine Software nicht zu verschlechtern.
When you get a bug report, start by writing a unit test that exposes the bug (Martin Fowler)
Ausgedrückte Mechanik! Nicht lange überlegen, was könnte das für ein Fehler sein. Nicht rätseln, forschen und verzweifeln. Einfach mal die Entwicklungsumgebung starten und einen Unit-Test schreiben. Schrittweise das Problem identifizieren. Ausdrücklich nicht in der Masse des Software-Produktes untergehen. Befreit kleine Schritte gehen, den roten Balken als notwendig empfinden mit dem Ziel die grüne Farbe zu sehen und den Fehler zu bereinigen.
Think of the boundary conditions and concentrate your tests here (Martin Fowler)
Das die Grenzfälle eines Softwareproduktes interessant sind, lernt man sehr früh in dem Feld der Softwareentwicklung. Dieses Sprichwort ist diesem Grundsatz geschuldet. Werden Grenzfälle in einer Software überschritten, äußert sich das häufig dramatisch durch einen Serverabsturz und dem Totalausfall einer Software. Typisch hierfür sind Ressourceprobleme durch Speicherüberlauf und Laufzeitprobleme durch Deadlocks. Man bedenke allerdings, dass selbst eine NullPointerException eine Serveranwendung aus dem Tritt bringen kann bzw. eine Kettenreaktion auslöst, die zum Sturz eines Servers führt.
In diesem Sprichwort, schwingt der Umstand mit, dass Quellcode, der besonders kritisch ist, besonders ausgiebig getestet werden soll. Die Angst, dass man nicht alle Fälle einer Software testen kann, soll dabei nicht davon abhalten Tests zu schreiben, die die meisten Fehler abfangen. Es ist besser nicht alle Tests und sogar unvollständige Tests zu schreiben, als gar keine Tests zu schreiben!
Lesen, Lesen, Lesen! In diesem Sinne, können die Sprichwörter der einschlägigen Literatur bei der Softwareentwicklung hilfreich sein!
