Patterns

Überblick

Motivation

Es soll vorkommen, dass man in der Softwareentwicklung Probleme lösen muss. Und es soll vorkommen, dass man ein Problem, dass man schonmal gelöst hatte, nochmal lösen muss. Und es soll vorkommen, dass sich manche Probleme ähneln. Typischerweise versucht man, wenn man ein Problem zum zweiten Mal lösen muss, schneller zu sein als beim ersten Mal. Das nennt sich “lernen”.

Aber es gibt noch eine weitere Möglichkeit, beim zweitem Mal Arbeit zu sparen: Wiederverwendung. Besteht die Lösung eines Problems in einem Stück Code, dann kann man diesen verallgemeinern (parametrisieren) und beim zweiten Mal einfach hernehmen und benutzen. Das Ergebnis ist dann eine Prozedur, eine Klasse oder allgemein: ein Modul.

Aber auch, wenn die Lösung nicht in einem Stück Code besteht, sondern in einer bestimmten Herangehensweise, einer bestimmten Strukturierung oder Idee, so kann man sie wiederverwenden. Das Gegenstück zum Modul, dem wiederverwendeten Code, ist das Pattern bzw. Muster, sozusagen die wiederverwendete Idee. weiter lesen »

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 »

Gefangen, nicht gefunden! #12

Informatik

• 10 things non-technical users don’t understand about your software. Kommt natürlich stark auf die Zielgruppe drauf an. Wenn die Zielgruppe aber wirklich DAUs mit einschließt, trifft die Auflistung wohl ganz gut die möglichen Probleme. (via)
• Manchmal denke ich, dass die Java API unnötig kompliziert ist. Sie ist in Teilen wirklich sehr flexibel. Man kann damit auch komplexe Aufgaben recht schön lösen. Nur für die einfachen Aufgaben, die ständig vorkommen, braucht man eben auch ne Menge Code. Und das finde ich unschön. Um ne md5-Checksumme zu bilden reicht beispielsweise ein Funktionsaufruf bei weitem nicht aus. Da das Berechnen eines Hash-Strings aber wohl eindeutig zu den Standardaufgaben gehört, wäre hier eigentlich eine Convenience-Funktion, die einfach nur das tut, sinnvoll. Nur gibt es sie nicht. (Oder ich hab sie nicht gefunden.) Man muss ich das selbst schreiben. Was für ein Quark. Und jetzt weiß ich auch, wie sich dieses Problem nennt: Turing Tarpit.
• Die Delphi-Tage rücken näher. Die Agenda steht mittlerweile mehr oder weniger fest, denke ich. Um 12:00 Uhr bin ich an der Reihe. Leider parallel zu “Online-Updates mit Delphi”, was mich auch interessiert hätte. Murpheys Gesetz…
• Ich merk immer wieder, dass Ward’s Wiki eine wahre Fundgrube ist. Wer immer mal wissen wollte, was OO ist, findet hier, dass sich die Fachwelt darüber auch nicht einig ist. Aber es ich schon ganz interessant die einzelnen Positionen zu lesen. Ich halte es da ja tendenziell mit Nygaard. OO ist vor allem eine Denkweise und nicht irgendwelche Sprach-Features.

Anderes

• “Weil, so schließt er messerscharf, // nicht sein kann, was nicht sein darf.” Kennt jeder. Aber wo kommt das her? Da her: Die unmögliche Tatsache
• Ganz interessant: Der Pauli-Effekt.