Managing Complexity

Angeblich ein Klassiker unter den Büchern über Software soll "Code Complete" von Steve McConnell sein. Es wurde kürzlich als "2nd Edition" neu herausgebracht, und hat auch ein Heim im Internet: Code Complete 2 - Code Complete, Second Edition Im online verfügbaren Kapitel 5 fielen mir folgende Anmerkungen zum Thema "Importance of Managing Complexity" auf:

The goal is to minimize the amount of a program you have to think about at any one time. You might think of this as mental juggling-the more mental balls the program requires you to keep in the air at once, the more likely you’ll drop one of the balls, leading to a design or coding error.

Oh ja, die Problematik kenne ich nur zu gut! Obwohl das Bild, das ich immer vor Augen hatte, ein wenig anders war: Viele, viele Fäden, die ich irgendwie mühsam zusammen halten musste und keinen verlieren durfte! Und man hat ja nur zwei Hände frei, kann vielleicht noch irgendwas unter die Achsel klemmen, vielleicht noch etwas mit dem Fuß balancieren, vielleicht noch.....

Humans have an easier time comprehending several simple pieces of information than one complicated piece. The goal of all software-design techniques is to break a complicated problem into simple pieces. The more independent the subsystems are, the more you make it safe to focus on one bit of complexity at a time. Carefully defined objects separate concerns so that you can focus on one thing at a time.

Ja! Ja! D'accord! Es gelingt sogar schon......manchmal. Ich glaube, dass ich schon ein wesentlich besseres "Gefühl" entwickelte habe ein "complicated problem" in "simple pieces" aufzubrechen, aber es ist jedes Mal wieder ein Unterfangen mit ungewissem Ausgang. Da gibt es kein Patentrezept, es hat eher was mit "Intuition" zu tun (die sich mit jedem Versuch weiter schult, und die auch gerne trügt).

Keeping routines short helps reduce your mental workload.

Ja, unbedingt! D.h., vor nicht zu langer Zeit kam es mir noch sehr merkwürdig und eigentlich übertrieben vor, Ruby-Methoden von anderen mit einigen wenigen Zeilen, manchmal nur einer(!) Zeile Code zu sehen. Inzwischen stört es mich fast schon, wenn eine Methode länger als 10 Zeilen ist, und auch den Einzeiler habe ich inzwischen hingebracht (und ich hatte gute Gründe dafür!):


def meth_for(name)
obj_for(name).method(name)
end


Genau.

Writing programs in terms of the problem domain, rather than in terms of low-level implementation details, and working at the highest level of abstraction reduce the load on your brain.

Ja! Ja? Beispiel? Vielleicht, ja vielleicht, ganz winziges Beispiel, also nur zum Beispiel:
"if doc.savable? then...." => "wenn das Dokument speicherbar ist, dann..." (fast schon Klartext)
im Gegensatz zu
"if doc.parameters.additional_bits.s = 1 then...." => Jedes Dokument hat Parameter, da wurden irgendwann mal noch einige Bits dazugefummelt, von denen eins aussagt, ob das Dokument speicherbar ist, ich glaube, es war, wenn "s" auf 1 gesetzt ist....

-------------------
Nachtrag, weil ich in Tor Norbye's Weblog (SUN Mitarbeiter, der mit dem Project Semplice (Visual Basic for the Java platform) zu tun hat) folgendes entdeckte:

Die Problemdomäne für die Umrechnung von Fahrenheit nach Celsius ist diese Umrechnungsformel:

celsius = (fahrenheit - 32) * 5/9

In Basic könnte man dies bei einem Knopf, der den Inhalt des Textfelds "fahrenheit" in Celsius umrechnet und dann in das Label "celsius" schreibt, so hinterlegen (kaum ein Unterschied):

celsius.text = (fahrenheit.text - 32) * 5/9

Mit Java würde das so aussehen (Wie gut ist die Formel hier noch zu lesen und zu erkennen?):

celsius.setText(Integer.toString((Integer.parseInt(fahrenheit.getText())-32)*5/9));