Wie man Software entwirft

Wie schreibt man eigentlich Software?
– Nun, man tippt einfach den Code.
Und wie weiß man welchen Code man schreiben muss?
– Äh…

OK, die Antwort auf diese Frage wird etwas länger. weiter lesen »

Warum wir manchmal unterschiedlicher Meinung sind

Also nicht generell, sondern als Entwickler. Vielleicht hätte ich auch sagen sollen “Warum Software-Entwicklung nicht Mathe ist”. Aber auch das wäre missverständlich. Es geht mir um folgendes:

Bekanntlich sehe ich Softwareentwicklung als das ständige Ausbalancieren von Prinzipien oder Daumenregeln. So gern es wir uns auch vielleicht wünschen würden, es gibt kein allgemeines Patentrezept für gute Software. Es gibt kein allgemeines Kochrezept, keinen Algorithmus o.ä. nach dem wir uns richten könnten und der uns ein gutes Ergebnis garantieren würde.

Zumal “gut” auch wieder nur schwer fassbar ist. Einzelne Aspekte einer Software lassen sich messen. Manche ganz gut (Größe in LOC), manche mit Aufwand (z.B. Performance) andere nur mit Abstrichen (Kopplung, Usabiliy, Wartbarkeit, …). Wir sind also auf Heuristiken wie “Erfahrung”, “Bauchgefühl” und eben “Meinung” angewiesen. Natürlich kann man versuchen, alles irgendwie zu quantifizieren und auf Basis historischer Projektdaten eine Metrik für “Güte” zu definieren. Man kann das tun. Inwieweit das zielführend ist, ist jedoch wieder eine andere Frage [1].

Wie gesagt: Softwareentwicklung ist das Ausbalancieren von Daumenregeln, man könnte auch “Kräften” sagen. Diese Kräfte ziehen in verschiedene Richtungen und wir müssen ein Kräftegleichgewicht finden. Das Problem ist nur, dass wir nur sehr schwer sagen können, wie stark diese Kräfte nun sind.

Die folgenden Aussagen wird vermutlich kaum ein Entwickler ernsthaft anzweifeln:

• Einfach ist besser als kompliziert (KISS)
• Allgemeingültig/generisch ist besser als speziell
• Goto ist böööse (goto statement considered harmful)
• Globale variablen sind böööse (global variable considered harmful)
• Starke Bindung, lose Kopplung
• …

Die Frage ist nur: Wie stark sind diese “Kräfte”? Und hierbei gehen die Meinungen auseinander. Wenn Entwickler also unterschiedlicher Meinung sind, dann hängt das selten daran, dass bestimmte Effekte/Prinzipien/Kräfte/Daumenregeln generell angezweifelt werden. Vielmehr streitet man sich um die Bewertung derselben. Ist in diesem konkreten Fall Allgemeingültigkeit oder Einfachheit wichtiger? Lieber eine technisch kompliziertere Lösung nehmen, die mehr kann oder besser eine einfache, die ihre Einschränkungen hat? Lieber ausnahmsweise mal ne globale Variable nehmen und dadurch den Code etwas einfacher machen oder darauf verzichten und damit die Kopplung reduzieren?

Es ist also meist nicht so, dass einer recht hat und der andere unrecht. Oft kann man guten Gewissens beide Positionen vertreten. Das macht entsprechende Diskussionen natürlich nicht immer einfach, weil man nicht wie in Mathe sagen kann “Da ist der Fehler, du hast unrecht”. Das kann anstrengend sein. Dennoch sind solche Diskussionen wichtig, denn sie helfen, eine passende Lösung für die gegebene Problematik zu finden und außerdem lernt man auch sie eine ganze Menge.

[1] IMHO sind Metriken in gewissem Umfang schon sinnvoll. Inwieweit ist aber wieder eine Bewertungsfrage.

Softwareentwicklungs-Prinzipien: Eine Übersicht

Ich hatte ja schon angekündigt, dass ich mein Versprechen auf den letzten Delphi-Tagen in Raten erfüllen werde. Immer mal wieder landet etwas zu den Softwareentwicklungs-”Daumenregeln” oder -Prinzipien hier im Blog. Vielleicht werde ich die Artikelserie irgendwann in ein Tutorial packen oder auf andere Weise verarbeiten. Mal sehen.

Zuerst aber ist mal ein grober Überblick notwendig und diesen möchte ich hier geben.

Wie schon mehrfach erwähnt, sehe ich Softwareentwicklung als das ständige Ausbalancieren von “Daumenregeln” oder “Prinzipien”. Solche Daumenregeln gibt es eine ganze Menge. Ich hab bisher schon so an die hundert dieser Regeln zusammengetragen und werde die hoffentlich auch bald mal sortieren und hier posten. Diese Daumenregeln können sehr unterschiedlich sein. Manche sind sehr allgemein, andere hingegen auf ganz bestimmte Probleme spezialisiert. Viele dieser Daumenregeln, sind einfach nur Spezialisierungen oder Abwandlungen anderer, aber es ist auch nicht selten, dass sich einzelne Regeln widersprechen. Es ist dann jeweils ein geeigneter Mittelweg, ein Kompromiss zu suchen. Man kann diese Regeln auch als Kräfte betrachten, die in unterschiedliche Richtungen ziehen. So gesehen ist das Ziel ein Kräftegleichgewicht.

Das was ich hier schreibe, ist keine für alle Ewigkeiten gültige Wahrheit, an der nicht gerüttelt werden darf. Im Übrigen bin ich der Meinung, dass es so etwas gar nicht gibt. Aus nahe liegenden Gründen werde ich hier also meine persönliche Sichtweise auf die Softwareentwicklung darstellen. Man darf hier gerne anderer Meinung sein. Vieles ist Ansichtssache und auch wenn manche der Prinzipien (nicht aber alle) weithin anerkannte Lehrmeinung sind, sollte man trotzdem überlegen, ob man diese nachvollziehen kann. Im Übrigen wird man diese hier vorgestellten Daumenregeln nur dann wirklich anwenden können, wenn man die für zumindest einigermaßen sinnvoll erachtet.

Ich beziehe mich hier hauptsächlich auf objektorientierte Softwareentwicklung, prinzipiell gilt das meiste aber auch für andere Programmierparadigmen, bzw. sind leicht auf solche übertragbar. Jetzt will ich erstmal einen groben Überblick über die meiner Meinung nach wichtigsten Prinzipien geben. Genaueres folgt dann irgendwann mal in einzelnen Artikel zu den jeweiligen Prinzipien.

Die drei obersten Daumenregeln

“Die obersten drei Regeln der Softwareentwicklung”, wie ich sie hier mal nennen will, beschreiben, wie man mit den ganzen hier vorgestellten Regeln umgehen soll. weiter lesen »

The Tradeoff Game

Wie ich schon mehrfach erläutert habe, sehe ich Softwareentwicklung als das ständige Ausbalancieren von Prinzipien oder “Daumenregeln”. Es gibt eine ganze Menge solcher Daumenregeln (ich hab mal an die hundert solcher gesammelt) und ich hab vor, diese nach und nach hier mal vorzustellen.

Einige dieser Regeln ergänzen sich, manche sind spezieller als andere oder einfach nur eine andere Sichtweise auf eigentlich das selbe Prinzip. Viele aber widersprechen sich auch. Ein typisches Beispiel wären folgende beiden Prinzipien:

1. mache deine Software generisch, damit sie auch leicht mit geänderten Anforderungen klar kommt; kurz: allgemeingültig ist besser als speziell
2. mache deine Software einfach, damit sie leicht verständlich ist (KISS); kurz: einfach ist besser als kompliziert

Es wird wohl kaum jemand in Abrede stellen, dass beides wichtige Prinzipien der Softwareentwicklung sind. Wir alle wollen am liebsten einfachen Code der trotzdem sehr viel kann. In der Regel werden wir so etwas aber nicht haben können. Je generischer man versucht zu programmieren, desto komplexer wird der Code. Letztendlich streben beide Prinzipien also in unterschiedliche Richtungen. Es gilt dabei immer einen Mittelweg zu finden.

Man kann diese Daumenregeln auch als “Kräfte” bezeichnen. Dann wäre das, was wir suchen, eine Art Kräftegleichgewicht. Die Kräfte können unterschiedlich stark sein und so liegt das Gleichgewicht nicht immer in der Mitte. Außerdem gibt es meist mehr als zwei Kräfte, die es zu betrachten gilt.

Oft sind die Gewichtungen aber auch subjektiv. Manche Entwickler werden Einfachheit wichtiger finden, andere finden Generizität wichtiger. Es gibt dann mehrere “richtige” Lösungen. Aber alle werden darüber übereinstimmen, dass eine Lösung, die beide Prinzipien missachtet, eine schlechte ist. Komplizierte Software, die nur einen ganz bestimmten Spezialfall abdeckt und sich nicht auf andere Probleme anpassen lässt, wollen wir in der Regel nicht haben [1]. Wir suchen also eine Art Pareto-Optimum. Welche pareto-optimale Lösung jetzt für ein konkretes Problem gewählt werden sollte, hängt von vielen Faktoren ab. Zum einen von den konkreten Anforderungen für die zu entwickelnde Software, zum anderen aber auch projektabhängige Einflüsse wie Vorlieben, Kenntnisse und Fähigkeiten der Teammitglieder und sogar der Teamorganisation.

Dieses Ausbalancieren bezeichne ich gerne als “Tradeoff Game”. weiter lesen »

Code Smells: Wenn Code anfängt zu stinken

Jeder, der schon eine Weile programmiert, wird die Situation kennen: Man liest Code (entweder fremden oder eigenen) und es läuft einem kalt den Rücken runter, die Zehnägel stellen sich auf und man will nur noch wegsehen. Wer das noch nie erlebt hat, sollte einfach mal seine ersten Programmierversuche wieder herauskramen.

Mancher Code scheint einfach zum Himmel zu stinken. Treffenderweise nennt man so etwas “Code Smell”. Letztens habe ich bei Nick Hodges von einem Stackoverflow-Thread über solche Code Smells gelesen.

Ich dachte mir, das passt wunderbar zu der an den Delphi-Tagen angekündigten (und leider immer noch nicht wirklich begonnenen) Artikelserie zu den Prinzipien der (objektorientierten) Softwareentwicklung. Wahrscheinlich werde ich zu jedem diskutierten Prinzip – wenn möglich – ein paar Code-Smells als abschreckendes Gegenbeispiel benennen. Hier aber erstmal ein paar allgemeine Gedanken zu Code Smells:
weiter lesen »