Codeoptimierung: Wurzel allen Übels

Das erste mit dem Softwareentwickler in Projekten anfangen, ist die Optimierung ihres Codes. Wahrscheinlich dient dies als Beweis ihres Könnens. Klar, Optimierungen sind sind immer ein Fall für erfahrenen Entwickler. Aus diesem Grund ist dieses Streben nach optimiertem Code von Beginn an verständlich. Nur was nützt schneller (dazu kommen wir in einem andern Post) Code der schnell Fehler produziert aber nicht die gewünschte Funktion? Durch die aufwendige Fehlersuche und Fehlerbehebung kostet das oben beschriebene Vorgehen mehr Entwicklungszeit im Vergleich zum normalen Entwickeln. Was lernen wir daraus, Optimierungen sind prima, wenn man sie nicht macht.

The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

Aus agiler Entwicklungssicht sind Optimierungen erst notwendig, wenn sie notwendig sind. Optimierungen sind Teil des Refactoringprozesses in der agilen Softwareentwicklung. Wichtiger ist die Verständlichkeit und die Wartbarkeit des Codes. Aber zurück zur Optimierung, der erste Schritt bei der Optimierung ist es, festzustellen das es ein Problem gibt, dass durch Optimierung gelöst werden kann, der zweite Schritt ist es das entsprechende Verhalten der Software zu dokumentieren und ein Testset aufzubauen mit dem die Ergebnisse nachvollziehbar sind. Im dritten Schritt wird das Problem analysiert (Profiling) und die beste Stelle (Bottleneck) zur Optimierung gefunden. Erst im vierten Schritt wird der Code optimiert. Dann wird der Effekt der Optimierung mittels des Testsets dokumentiert (fünfter Schritt). Die Optimierung von Code besteht aus folgenden Schritten:

1. Feststellen und Dokumentieren das es ein Problem gibt.
2. Definieren eines Testsets und Dokumentieren der Ergebnisse für den nichtoptimierten Code.
3. Analyse des Problems z.B. mittels Profilings und finden der Codestelle für die Optimierung.
4. Optimieren des Codes.
5. Dokumentation der Ergebnisse des optimierten Codes mit Hilfe des Testsets.

Und eins sollte man nie vergessen, die Entwicklungszeit die in eine Optimierung fliesst, muss durch den Optimierungsgewinn gerechtfertigt sein.

CCD: clean code developer

Viele Dinge in diesem Blog thematisieren die täglichen Probleme. Auch gibt es paar etwas grundlegendere Beiträge nur leider keine grundlegende Verarbeitung dieser Dinge. Ich hatte mir das alles auf einen späteren Zeitpunkt verschoben. Das ist dann wohl zu spät. Aber ich freue mich auf die folgende Webseite hinzuweisen: CCD: clean code developer bzw. auf das Interview.

Ich glaube alle Prinzipien dieser Seite kann ich gutes Gewissens empfehlen, weil ich sie aus meiner Erfahrung selbst anwende und meinen Studenten rate. Die dort beschriebenen Prinzipien lassen sich durch eine Reihe von Werkzeugen sinnvoll unterstützen. Dazu werde ich demnächst einen Beitrag schreiben.

Test Driven Development (TDD) Vorlesung - Einführung

Bei iTunes gibt es den etwas weniger bekannten Bereich iTunes U. Dort können Universitäten Podcast oder Videopodcast veröffentlichen. Hier habe ich unter anderem eine Vorlesung von RWTH Aachen zu Thema Test Driven Development  von Prof. Jan Borchers (Link) gefunden. Auch wenn dort Xcode als Entwicklungsumgebung verwandt wird, so ist es doch eine gute Einführung in das Thema für Leute die sich das erste Mal mit dem Thema beschäftigen wollen. Leider enthält diese Vorführung einen sehr entscheidenden Fehler. Es wird hier demonstriert wie man Test schreibt. Was fehlt ist, wie man den Code schreibt. Bei TDD ist das schreiben von Code nicht equivalent zum schreiben von herkömmlichen Code, das hängt mit den kurzen Round-Trip-Zeiten zusammen, d.h. zwischen schreiben eines Test und dem schreiben des dazugehörigen Codes vergeht sehr wenig Zeit, z.B. eine Minute auch wird dort nur beiläufig angerissen, wie Test zu schreiben sind. Dies hat aber aus meiner Erfahrung einen entscheidenden Einfluss auf den späteren Code. Aber solche Dinge könnte man ja schon als Vertiefung des TDD ansehen. Sauberer wäre es schon gewesen, die wichtigen Dinge des TDD gleich am Anfang zu erwähnen:

• Test first
• Kurze Round-Trip-Zeiten
• Boundary Test
• Testen mit falschen Parametern (Fehlerbehandlung)
• Einbeziehung von Code-Überdeckung
• Übergang vom Black-Box-Testen zum White-Box-Testen

Test Driven Development (TDD)

Letztens wurde ich gefragt, wie ich das Problem löse, schwer testbare Klassen zu testen. Eine Möglichkeit wären natürlich Mock-Objekte, also Objekte die fürs Testen gewisse Funktionen als Dummy bereitstellen ggf. auch Datenbanken mit Testdaten aufbauen. Dies ist zwar etwas aufwendiger als das schreiben reiner Tests aber sonst nicht weiter aufregend. Da diese Antwort scheinbar nicht ausreichte, war meine nächste Antwort, dass das Objektmodell dann wohl fehlerhaft wäre und man dort ansätzen müsste. Diese Antwort war wohl nichts für Verfechter der reinen Objekt-orientierten Analyse und Entwurfs. Es wurde daraufhin auch deutlich, dass das Gegenüber unter Extreme Programming (XP) und TDD wohl nur als eine Technik wie z.B. Hibernate verstanden. XP und TDD sind an dieser Stelle mehr, sie sind ein Wechsel bei der Art und Weise wie Software entwickelt wird. Das heisst natürlich nicht, dass sich XP, TDD und Objekt-orientierte Softwareentwicklung sich ausschliessen. XP und TDD sind die nächste Evolutionsstufe der Softwareentwicklung, der Objekt-orientierten Softwareentwicklung.