Das ganze ist mäßig unterhaltsam. Was vielleicht nicht so klar herauskommt ist, dass es bis heute keinen wirklichen Konsens darüber gibt, was objektorientiert eigentlich bedeutet. Weiters ist das dominierende Paradigma eine Art komponentenbasierte, prozedurale Programmierung in der Objekte im Wesentlichen mit Datensätzen gleichgesetzt werden. So gesehen wäre es fair, wenn man Objekten erst einmal eine Chance gäbe, bevor man sie verurteilt…

Softwareentwicklung kann nicht hinter einer Schnittstelle aus User Storys versteckt werden.

Nur wenn Softwareentwickler und Fachabteilungen eng zusammenarbeiten, so Feathers, erhält man im Endeffekt brauchbare Software.

Mehr dazu im Artikel Some History about Iterative Development auf meinem englischsprachigen Blog…

Faszinierende Einsichten über die Natur des Ingenieurwesens und den Umstanden, dass auch in scheinbar exakten Wissenschaften wie der Mathematik Faustformeln (Heuristiken), und nicht glasklare Logik die Entscheidungen der Forscher bestimmen.

Der Vortrag hat nur einen kleinen Schönheitsfehler: Die Aussage „Alles ist eine Heuristik!“. Man sollte sich von der Eloquenz und Reputation des Vortragenden hier nicht blenden lassen, denn offensichtlicherweise ist ein Tisch ein Tisch, ein Sessel ein Sessel und eine Heuristik eine Heuristik. Diese triviale Einsicht bin ich persönlich nicht bereit aufzugeben! Prof. Koen hätte hier auf Boëthius hören sollen: Wenn du geschwiegen hättest, wärest du Philosoph geblieben.

Ansonsten ist der Vortrag äußerst unterhaltsam und lehrreich und alle beschriebenen Erkenntnisse gelten natürlich auch uneingeschränkt für Softwareentwickler.

Die fundamentale Regel des Softwareentwurfs

… more what you’d call ‘guidelines’ than actual rules

Capt. Barbossa in „Pirates of the Caribbean: The Curse of
the Black Pearl“ (dt.: „Der Fluch der Karibik“).

Die „4 minus Analogien“ -Regel

Wie wir im 6. Teil gesehen haben sind Analogien die Bausteine der Wahrnehmung. Identifizieren der Analogien eines Problems ist der erste Schritt zur Lösung. Code-Strukturen zu identifiziren, die Analogien repräsentieren, sind Teil der Kenntnisse eines erfahrenen Programmierers. Unser Gehirn hat sich dahingehend entwickelt, Netzwerke für das Langzeitgedächtnis aufzubauen (siehe Teil 3). Netzwerke, die für das effiziente Auffinden von Informationen und das minimieren des Aufwandes für das Umlernen optimiert sind. Die Konsequenz dieser Entwicklung ist, dass wir lediglich vier Code-Elemente oder weniger zu einem gegebenen Zeitpunkt verarbeiten können. Die einzige Ausnahme ist die Anzahl von Varianten einer Analogie.

Wir können eine Einkaufsliste unabhängig von ihrer Länge verstehen, da wir wissen, dass wir alle Elemente der Liste gleich behandeln können (z.B. finden und einkaufen). Wir werden also instinktiv alle Varianten als ein Element in einer Analogie gruppieren. Damit ergibt sich die fundamentale Regel des Softwareentwurfs als:

Software sollte in Chunks aus maximal vier Elementen Gruppiert sein, wobei eine beliebige Anzahl von Varianten von Analogien erlaubt sind.

Da wir die Definition der Psychologen für Chunking verwenden (siehe Teil 2), ist die Forderung nach geringer Kopplung und hoher Kohäsion (gemäß dem Einzelzuständigkeitsprinzip) automatisch erfüllt. Das bedeutet natürlich nicht, dass beispielsweise eine Klasse nur vier Methoden haben darf. Es ist auch erlaubt, Methoden in Chunks von vier Methoden oder weniger zusammenzufassen, dabei ist wieder eine beliebige Anzahl von Varianten von Analogien erlaubt.

Software zu Chunks zusammenzufassen ist eine durchaus offensichtliche Form der Strukturierung von Code und wird daher in zahlreichen Quellen beschrieben. Ein Erklärungsmodell, das erlaubte Ausnahmen beschreibt hingegen nicht. Das klassische Beispiel ist das eines einzelnen, einfachen Verhaltens basierend auf unterschiedlichen Datentypen, das aber keine eigene Klasse benötigt. In diesem Fall ist eine einfache Switch-Anweisung besser geeignet.

switch (operand) {
        case MULTIPLY:
            return first * second;
        case DIVIDE:
            return first / second;
        case ADD :
            return first + second;
        case SUBTRACT :
            return first - second;
    }

Diese Switch-Anweisung braucht auch dann nicht in eine eigene Klasse ausgelagert zu werden, wenn sie mehr als vier Case-Anweisungen enthält. Schließlich sind alle Case-Anweisungen Varianten der Switch-Analogie. Da unser Gehirn alles, was es als Analogie erkennt, zusammenfasst, führt das zu keiner kognitiven Überlastung.

Wie wir im vorhergehenden Teil gesehen haben, ist das die Struktur einer Analogie, also folgt es der „4 minus Analogien“ -Regel. Mehr als vier Elemente einzufügen belastet den Leser damit, dass er selbst Elemente zu Chunks zusammenfügen muss. Ohne die Anleitung, die der Autor dem Leser durch die Strukturierung des Codes zur Verfügung stellt könnte der Leser zu einer anderen Aufteilung kommen oder er könnte überhaupt Schwierigkeiten haben, eine Aufteilung zu finden. Das kann zu Missverständnissen führen und diese führen nicht selten zu Fehlern.

Chunking und Analogien mögen einen Einblick in die Kunst des Programmierens geben, vermögen aber nicht alles zu erklären. Beispielsweise ähnelt Joshua Bloch’s Erbauermuster [mehr noch Fluent Interfaces, wie sie Martin Fowler beschreibt] der Struktur nach geschriebener Sprache und dass trotz der Einschränkungen eines stark beschränkten Vokabulars.

    customer.newOrder()
            .with(6, "TAL")
            .with(5, "HPK").skippable()
            .with(3, "LGV")
            .priorityRush();

Die Struktur des Codes, die ein Fluent Interface ermöglicht, kommt geschriebener Sprache sehr nahe.

Schlussfolgerungen

Code verständlich zu gestalten ist das primäre Ziel für einen Großteil der Entwurfsprinzipien in der Softwareentwicklung. Um zu verstehen, was „Einfachheit“ im Zusammenhang mit Softwareentwicklung bedeutet, müssen wir die Prozesse und deren Beschränkungen verstehen lernen, die es uns ermöglichen Quellcode zu verstehen. Das kognitive Modell kann auch von Neulingen verstanden und gelernt werden, denn man kann zur Veranschaulichung Beispiele „aus dem richtigen Leben“ verwenden, die auch Nichtprogrammieren vertraut sind.

Die Konzepte der Kognition sind die Fundamente hinter den Entwurfsprinzipien. Das erlernen des kognitiven Modells ist allerdings kein Ersatz dafür, Entwurfsprinzipien zu erlernen und zu verstehen, aber es reduziert die nötige Erfahrung, die der Neuling benötigt, um herauszufinden, unter welchen Umständen er welches Prinzip umsetzen soll. Die daraus entstehende Verbesserung unseres Codes wird uns helfen, die Kosten für Wartung und Support zu reduzieren.

Analogiemuster in Software

Die offensichtlichste Art Analogien in Software zu implementieren ist die Verwendung von Interfaces und abstrakten Klassen (siehe einfache Analogien und Regelanalogien in der Aufzählung unten im vorhergehenden Teil), allerdings kann man Analogien auch auf andere Art darstellen.

Bitte berücksichtigen Sie, dass die Codebeispiele in diesem Abschnitt Beispiele für die Strukturierung von Code darstellen. Sie zeigen, wie der Code aussehen könnte aber nicht notwendigerweise wie er aussehen sollte. Eine gute Richtlinie für das Identifizieren von Analogien ist, wenn man „erraten“ kann, wie der Code logisch fortgesetzt werden kann, wenn das Verhalten um eine neue Variante erweitert werden soll.

Der folgende Code zeigt Beispielsweise das Kontotyp-Attribut für unterschiedliche Terminbörsen als Varianten (Eurex, Liffe, etc.).

public String getAccountType(String account) {
    if(exchange.equals("EUREX"))
        return getEurexAccountType(account);
    if(exchange.equals("LIFFE"))
        return getLiffeAccountType(account);
    if(exchange.equals("MONEP"))
        return getMonepAccountType(account);

Es ist hier einfach zu erraten, wie der Code für die Französische Terminbörse MATIF erweitert werden muss:

    if( exchange.equals("MATIF") )
        return getMatifAccountType(account);

Auf den ersten Blick sieht das Erraten dieser Erweiterung wie das Ergebnis von Erfahrung in der Softwareentwicklung aus. Tatsächlich ist es aber das Ergebnis von Erfahrung im Erkennen von Analogien und diese Fähigkeit erlernen wir bereits in unserer Kindheit! Die unbewusste Annahme, dass der Leser analoge Strukturen erkennen und erstellen kann (die die Anforderungen an die Anwendung widerspiegeln) ist zweifellos eine zentrale Fähigkeit, die auch von Softwareentwicklern verlangt wird, die den Code zum ersten Mal zu Gesicht bekommen (im vorletzten Teil haben wir diese Entwickler Neulinge genannt).

Im folgenden Abschnitt werden zahlreiche Sprachmittel von Java vorgestellt, die dazu verwendet werden können, Analogien darzustellen. Diese Sprachmittel sind natürlich auch in anderen Programmiersprachen vorhanden und abhängig von den Sprachmitteln ist in vielen Sprachen natürlich noch mehr möglich.

Attribute-Only-Analogien

Die einfachste Art einer Attribute-Only-Analogie ist eine Hashtabelle (Map). In diesem Beispiel werden die einzelnen Terminbörsen als direkte Analogien (siehe letzter Teil unten) gesehen. Das einzige Attribut von Interesse ist dabei das Land, in welchem sich die Börse befindet:

static Map exchangeCountry = new HashMap();

static {
    exchangeCountry.put("EUREX","Germany");
    exchangeCountry.put("CBOT","US");
    exchangeCountry.put("LIFFE","England");
    //can guess what to do
    //to extend for NYBOT......
}

//usage
public String logMessage(String exchangeName) {
    return "Exchange " + exchangeName +
           " is in " +
            exchangeCountry.get(exchangeName);
}

Statement-Formanalogien

In diesem Fall wird dieselbe Ausführung (Form) für unterschiedliche Felder oder Elemente verwendet, um das Verhalten zu implementieren. Die Ähnlichkeit in der Ausführung (Form) des Statements ist der Schlüssel, durch den der Leser die Analogie erkennt. In diesem Beispiel ist das Überprüfen des Feldes die Analogie und jedes Feld der Klasse benötigt seine Eigene Variante zur Überprüfung desselben.

private Date expirationDate;
private Long contractNumber;
private Double price;
private Double quantity;
private String description;

private boolean isValid()
{
    if(expirationDate == null ||
       !(expirationDate.getTime() > 0))
        return false;

    if(price == null ||
       !(price.doubleValue() > 0))
        return false;

    if(quantity == null ||
       !(quantity.doubleValue() > 0))
        return false;

    //can guess what the code line is
    //for the String parameter
    //"description" ......

    return true;
}

Switch-Analogie

Ähnlich wie bei der Statement-Formanalogie sind die Implementierungen zu Chunks gruppiert, allerdings mit einer formelleren Definition des Typs der Variante. Das Beispiel gibt das Ergebnis unterschiedlicher Operationen zurück, die auf zwei Zahlen angewendet werden sollen (Addition, Subtraktion, etc.)

private int operand;

public double calculate(double first, double second) {
    switch (operand) {
        case MULTIPLY:
            return first * second;
        case DIVIDE:
            return first / second;
        case ADD :
            return first + second;
        case SUBTRACT :
            return first - second;
    }
    return 0;
}

Methodennamen-Analogie

Entweder das Präfix oder das Suffix der Methode wird verwendet, um die Analogie auszudrücken. Das Präfix hat den Vorteil, dass die Gruppierung und damit die Analogie auch dann noch erhalten bleibt, wenn die Methoden alphabetisch sortiert werden. Als Beispiel für die Präfix-Variante dient das Besuchermuster. Im Beispiel für die Gruppierung mithilfe des Suffix wird ein Objekt des Typs Double in unterschiedliche Datentypen umgewandelt. Diese Form ist nützlich, wenn alle Varianten gemeinsame Abhängigkeiten haben, die in der Klasse zu Chunks zusammengefasst werden können.

//example 1 - prefix
public void visitExpression(Node a) {};
public void visitBlock(Node a) {};
public void visitFile(Node a) {};

//example 2 - suffix
Double doubleObj = new Double(0);
double a = doubleObj.doubleValue();
int b = doubleObj.intValue();
long c = doubleObj.longValue();
float d = doubleObj.floatValue();

Methodenparameter-Analogie

Der Typ des Parameters, der an eine Methode übergeben wird, kann die verwendete Variante bestimmen. Das folgende Beispiel berechnet das Maximum zweier zahlen:

float f = Math.max(1.0F, 2.0F);
int i = Math.max(1, 2);
long l = Math.max(1L, 2L);
double d = Math.max(1.0, 2.0);

Klassen-/Interface-Analogie

Die Klassen-/Interface-Analogie erlaubt es, mehrere Elemente (Felder) zu Chunks zusammenzufassen.

abstract class Shape {
    String name; //square, circle etc
    int numSides;
    abstract double area();
}

class Rectangle extends Shape {
    double length;
    double width;

    double area() {
        return (length * width);
    }
}

Anwendungsanalogie

Die Laufenden Instanzen einer Anwendung sind direkte Analogien voneinander. Konfigurationsdateien und Systemeinstellungen sind die Eigenschaften (Merkmale) dieser Analogie.

Multiparadigmen-Design

Die Technik, Analogien in den Anforderungen zu identifizieren und daraufhin die passenden Code-Strukturen auszuwählen wurde erstmals von James Coplien beschrieben (siehe Multi-Paradigm Design for C++). Coplien benutzt allerdings den Begriff Domain für Analogieen und Sub-Domains für Varianten. Solution Domains entsprechen den Analogiestrukturen im Code (auch wenn lediglich formale Strukturelemente wie Interface, Template [das mächtigere Pendant zu Generics in C++] etc. identifiziert werden). Die „commonality and variability analysis“ ist der Prozess, mit dem die Analogien identifiziert werden. Beide, Coplien und Grady Booch (in Object-Oriented Analysis and Design with Applications) beschreiben objektorientiertes Design als „Aufteilen durch Zusammenfassen“. Strukturiertes Design ist die Disziplin des Zusammenfassens aber für Thomas Mullen ist objektorientiertes Design Identifizieren und Kodieren von Analogien. Das sind unterschiedliche aber komplementäre Fähigkeiten, die erworben werden müssen, um Software mit gutem Design zu erstellen.

Im achten und letzten Teil dieser Serie wird die fundamentale Regel des Softwareentwurfs beschrieben und Schlussfolgerungen aus all den Erkenntnissen, die in den vorangegangenen Teilen gewonnen wurden, gezogen.

Die Auswahl von Analogien

Als Analogie bezeichnet man eine Form der Übereinstimmung von Objekten physischer oder abstrakter Natur hinsichtlich gewisser Merkmale.

Für viele Psychologen sind Analogie ein zentraler Punkt menschlicher Intelligenz. Manche eröffnen neue Einsichten (z.B. Niels Bohrs Atommodell, indem die Elektronen um den Kern wie Planeten um die Sonne kreisen), andere erlauben uns, bestehende Kenntnisse in neue Situationen anzuwenden (zum Beispiel, wenn wir lernen, ein Motorboot zu fahren, nachdem wir bereits gelernt haben, ein Auto zu fahren). Laut Douglas R. Hofstadter sind Analogien ein zentraler Punkt menschlicher Erkenntnis. Sie sind die Bausteine für die Art und Weise, wie wir Konzepte verstehen.

Analogies. Quelle: XKCD.

Holyoak & Thagard identifizieren drei weitläufige Kriterien für die Auswahl von Analogien: Ähnlichkeit, Struktur und Zweck. Ein Spieleprogrammierer könnte beispielsweise das Verhalten eines virtuellen Tigers abhängig von seinem mentalen Zustand modellieren (hungrig, verletzt, bedroht). Dabei werden die mentale Zustände des Tigers als Varianten, die in Abhängigkeit davon modellierte Verhaltensmuster (Bewegungen des Tiers, die Wahrscheinlichkeit eines Angriffs) als Strukturelemente Bezeichnet [Varianten von "Tiger" wären dann "hungriger Tiger", "verletzter Tiger", "bedrohter Tiger"].

Der World Wild Fund for Nature (WWF) sieht den Tiger eher vom Standpunkt des Artenschutzes, dabei sind die Umwelt, die Häufigkeit von Nachwuchs, die aktuelle Population etc. die Strukturelemente der Analogie. In der WWF-Analogie ist der Tiger die Variante [eine Variante von "Gattung" zum Beispiel], sowie andere bedrohte Arten wie der Panda. Es ist also der Zweck, der die Auswahl der Analogie für den Spieleprogrammierer und den WWF bestimmt.

Der Tiger und die fünf Schweinchen. Quelle: Say No To Crack.

In der Software kann ein und dieselbe Klasse (oder ein und derselbe Codebestandteil) anderen Codebestandteilen unterschiedliche Analogien zur Verfügung stellen. Ein Datenzugriffsobjekt wird beispielsweise allen Codebestandteilen Lese- und Schreibverhalten zur Verfügung stehen, die Zugang zu gespeicherten Daten benötigen. Codebestandteilen, die mit der Initialisierung der Anwendung betraut sind, wird dasselbe Datenzugriffsobjekt jedoch einen Konstruktor oder eine Methode setDataSource zur Verfügung stellen, über den oder die das Objekt Zugang zur Datenbank bekommt.

Auch in diesem Fall wird die Auswahl der Analogie durch den Zweck (Zugang zu Daten, Initialisierung) bestimmt. Unterschiedlichen Codebestandteilen unterschiedliche Analogien zur Verfügung zu stellen kann die mentale Belastung beim Verstehen einzelner Codebestandteile reduzieren.

Dedre Gentner schlug 1983 einen Algorithmus vor der den Einfluss der Struktur der Analogie auf die Auswahl beschreibt. Gentner unterscheidet vier Kategorien von Analogien:

Diese Kategorien werden in der Softwareentwicklung häufig wie folgt umgesetzt:

• Alle Instanzen einer Klasse direkte Analogien, wobei die Klassendefinition selbst als Abbildung fungiert. Genauso verhält es sich mit den Zeilen einer Datenbanktabelle, wobei in diesem Fall die Spaltennamen als Abbildung dienen.
• Interfaces und abstrakte Klassen können benutzt werden, um die Abbildung von einfachen Analogien zu beschreiben.
• Mit einem parametrisierten Datentyp (Generic, Template) wird häufig eine Regelanalogie ausgedrückt. Die Klasse Set<T> hat selbst keine Informationen darüber, welche Objekte später in die Instanz der Klasse aufgenommen werden. Anstelle des konkreten Typs wird in der Klassendefinition einfach der Platzhalter T verwendet.

Im nächsten Teil folgen den theoretischen Ausführungen konkrete Beispiele.

Code für Neulinge und Experten

Je mehr Erfahrung wir sammeln, desto eher scannen wir den Quellcode, statt ihn zu lesen. In dem Teil unseres Gehirns, indem visuelle Reize verarbeitet werden, werden die eingehenden visuellen Informationen mit Vorlagen aus unserem Gedächtnis verglichen. Diese Vorlagen entstehen in den Monaten und Jahren, in denen wir uns das Expertenwissen über ein Programm aneignen. Diese Vorlagen erlauben es dem Experten, sowohl die Struktur [eines Programms] als auch unübliche oder fehlerhafte Muster unmittelbar zu „sehen“ und zwar so als ob die Verarbeitung unbewusst geschehen würde (siehe Didierjean, Gobet: Sherlock Holmes – An expert’s view of expertise).

Michael Caine und Ben Kingsley als Sharelock Holms und Dr. Watson. In der Gaunerkomödie Genie & Schnauze (engl. Without a Clue) ist Dr. Watson das Genie und Sharelock Holms ein arbeitsloser Schauspieler mit Hang zum Alkohol und zum anderen Geschlecht…

Dadurch ist es für einen Experten vorteilhaft, soviel Code wie möglich in seinem Blickfeld zu haben. Wie wir im vorigen Teil gesehen haben, wird dadurch auch der Effekt der geteilten Aufmerksamkeit reduziert. Wenn hingegen zuviel Code im Gesichtsfeld des Neulings platziert wird, dann ist es möglich, dass in seinem Gehirn eine kognitive Überlastung platzgreift. Neulinge profitieren davon, wenn der Code so strukturiert ist, dass ihre Aufmerksamkeit zu jedem Zeitpunkt auf ein paar Elemente beschränkt bleibt.

Expertenwissen über ein Programm oder über einen Teil davon is nicht auf Programmierer mit großer Erfahrung beschränkt. Natürlich wird es für einen Softwareexperten einfacher sein als für einen Neuling, sich in eine neue Software einzuarbeiten, allerdings wird jeder Programmierer – ob Neuling oder Experte – zum Experten in dem Code, den er selbst schreibt. Schleißlich hätte er nicht die geringste Chance sein Programm überhaupt zum Laufen zu bringen, würden er das zugrundeliegende Problem und die Lösung nicht in allen Einzelheiten verstehen.

Im Übrigen ist das Verstehen eines Programm als Aufgabenstellung vergleichsweise überschaubar, wenn man es beispielsweise mit Aufgabenstellungen der Physik und anderen Disziplinen vergleicht, also ist es üblicherweise eine Frage von Monaten oder einem Jahr bis auch ein unerfahrener Programmierer ein Experte in zumindest einem Teil der Anwendung wird mit der er sich tagtäglich beschäftigt.

Wer kennt sie nicht? Überladene Powerpointpräsentationen. So hat der Autor alles im Blickfeld aber das Publikum wird völlig überfordert. Quelle: The HG2S Training Blog.

Als Beispiel bevorzugen Neulinge üblicherweise eine agressivere Normalisierung als Experten, da durch die Normalisierung Daten in Chunks aufgeteilt werden, was die kognitive Überlastung reduziert. Der Experte hat hingegen verwendet die Vorlagen, die sich sein Gehirn im laufe der Zeit zurechtgelegt hat, um die Chunks unmittelbar zu „sehen“. Eine weitergehende Normalisierung wird er eher als unnötige Abstraktionsschicht wahrnehmen, die ihm das verstehen [des Datenbankschemas] erschwert.

Solange Neulinge und Experten ein und den selben Quellcode lesen und verstehen müssen wird es also immer gegengesetzte Interessen geben. Die ersteren wollen die kognitive Überlastung durch Aufteilen des Codes in Chunks vermeiden, die anderen möchten so viel Code wie möglich auf einmal im Blickfeld haben. Kompromisse auf beiden Seiten sind also unvermeidlich. Es dauert allerdings nicht lange, bis der Neuling zum Experten in der Anwendung wird, an der er arbeitet und dann wird er von der Codestruktur des Experten profitieren, allerdings haben die meisten Teams bei weitem mehr Neuling als Experten.

Alles auf einen Blick: Zwei Klassen mit insgesamt 30.000 Zeilen Code. Quelle: Robert C. Martin.

Die Lösung, die der Mehrzahl der Programmierer dient, bedeutet häufig, dass der Experte eine größere Anzahl an Abstraktionsschichten und damit eine für ihn höhere kognitive Belastung akzeptieren muss. Wenn wir mit ein neues Programm schreiben, beginnen wir mit einer Codebasis die klar und einfach ist, aber da der Code mit der Zeit mehr und mehr Anforderungen erfüllen muss, wächst er kontinuierlich. Da wir, was den Code betrifft, den wir selbst schreiben, zwangsläufig Experten sind, werden wir unbewusst danach trachten, immer möglichst viel Code im Blickfeld zu haben. Code Reviews sind unter anderem dabei nützlich, uns auf unnötige Komplexitäten im Quellcode aufmerksam zu machen, über die wir uns als Autoren des Codes nicht bewusst sind, die aber unseren Kollegen das nachvollziehen des Code erschweren.

Im sechsten Teil dieser kleinen Serie beschäftigen wir uns mit dem umfangreichsten Teil des Papers: Mit Analogien, dem wahrscheinlich wichtigsten Werkzeug menschlicher Intelligenz.

Die kognitiven Belastung beim Lernen

In Studien zum Thema kognitive Belastung werden zwei in diesem Zusammenhang relevante Prinzipien beschrieben: Redundante Informationen und der Effekt der geteilten Aufmerksamkeit. Wenn Informationen hinzugefügt werden, die bereits bekanntes wiederholen, ohne neue Einsichten zu vermitteln, erschwert das das Lernen. Die redundanten Informationen sind nicht unproblematisch, da sie wertvolle Ressourcen im Kurzzeitgedächtnis blockieren können, und so das Lernen erschweren. Beispielsweise beschreibt ein Kommentar für eine einfache Getter- [oder Setter-] Methode etwas, was sich ohnehin zwangsläufig aus dem Quellcode erschließt:

/**
 * @return the user name
 */
public String getUserName() {
    return this.userName;
}

Diese Art Kommentare erschweren sogar das Lesen und Verstehen des Codes, obwohl sie eigentlich das Gegenteil beabsichtigen!

Der Effekt der geteilten Aufmerksamkeit besagt, dass wenn ein Text ein Bild beschreibt und der Text wird an einer anderen Stelle als das Bild positioniert, dann ist es schwieriger, den Text zu verstehen. Das kommt daher, dass das Kurzzeitgedächtnis zusätzliche Informationen über die Verbindung zwischen dem Text und dem Bild zwischenspeichern muss. Das blockiert wiederum die begrenzten Ressourcen im Kurzzeitgedächtnis und damit bleiben weniger Kapazitäten zum Lernen und Begreifen.

Nicht nur Studenten leiden unter kognitiver Belastung. Quelle: n24.de

Oft werden von Programmierern zusätzliche Abstraktionsschichten eingefügt. Damit steigt aber auch die kognitive Belastung für den Leser des Quellcodes, da so neue Verknüpfungen zwischen Code-Bestandteilen entstehen.  Zwischen Abstraktionsschichten hin und her zu navigieren kann zu Zeit- und Kapazitätsproblemen im Kurzzeitgedächtnis führen.

Wenn man beispielsweise die Funktionsweise einer Methode verstehen möchte und dazu zu eine andere Klasse inspizieren muss, dauert das vielleicht ein paar Sekunden (wir erinnern uns, dass Gedächtnisinhalte nur ein paar Sekunden im Kurzzeitgedächtnis bleiben, also zählt jede Sekunde), allerdings muss möglicherweise jede Abstraktionsschicht und deren externe Abhängigkeiten verstanden werden. Das alles benötigt zusätzliche Kapazitäten im Kurzzeitgedächtnis und führt dazu, dass der Ursprüngliche Inhalt aus dem Kurzzeitgedächtnis verschwindet, sodass es keine Möglichkeit mehr gibt, ihn zu trainieren und so ins Langzeitgedächtnis zu überführen.

Wir sind zwar erstaunlich geübt darin, alle diese Informationen durch Chunking im Gedächtnis zu behalten, es gibt da allerdings ein Grenze und wir bekommen keine Warnsignale, wenn wir an diese Granze stoßen oder sie gar Überschreiten. Wir merken das erst, wenn wir uns plötzlich nicht mehr so genau erinnern können, wonach wir eigentlich im Quellcode eigentlich gesucht haben und warum wir an dir Stelle im Quellcode gelandet sind, wo wir uns befinden.

Ein schönes Beispiel für den übermäßigen Einsatz von Abstraktionsschichten und deren negative Auswirkungen auf die Verständlichkeit des Quellcodes ist Jason Tiscioni’s Hello-World-Programm. Durch konsequentes Einfügen von Abstraktionsschichten bläht er dieses einfache Programm…

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}

…zu folgendem auf:

public abstract class AbstractStrategyFactory {
    public abstract MessageStrategy createStrategy(MessageBody mb);
}

public class DefaultFactory extends AbstractStrategyFactory {
    private DefaultFactory() {}

    static DefaultFactory instance;

    public static AbstractStrategyFactory getInstance() {
        if (instance == null)
            instance = new DefaultFactory();
        return instance;
    }

    public MessageStrategy createStrategy(final MessageBody mb) {
        return new MessageStrategy() {
            MessageBody body = mb;

            public void sendMessage() {
                Object obj = body.getPayload();
                System.out.println((String) obj);
            }
        };
    }
}

public class MessageBody {
    Object payload;

    public Object getPayload() {
        return payload;
    }

    public void configure(Object obj) {
        payload = obj;
    }

    public void send(MessageStrategy ms) {
        ms.sendMessage();
    }
}

public interface MessageStrategy {
    public void sendMessage();
}

public class HelloWorld {
    public static void main(String[] args) {
        MessageBody mb = new MessageBody();
        mb.configure("Hello World!");
        AbstractStrategyFactory asf = DefaultFactory.getInstance();
        MessageStrategy strategy = asf.createStrategy(mb);
        mb.send(strategy);
    }
}

Jede Abstraktionsschicht für sich mag nicht übertrieben schwierig zu verstehen sein, wenn man sie isoliert betrachtet, doch wenn wir nicht aufpassen, überschreiten wir leicht die Grenzen des Kurzzeitgedächtnisses und wir kommen durcheinander. Entwicklungsumgebungen können die kognitive Belastung reduzieren, indem sie beispielsweise eine kurze Vorschau auf die Implementierung einer Methode gewähren. Wir können uns auch schriftliche Notizen machen, um nicht den Faden zu verlieren. Natürlich haben zusätzliche Abstraktionsschichten ihre Vorteile (für das Chunking), allerdings sind sie auch immer mit einer zusätzlichen kognitiven Belastung verbunden.

Im nächsten Teil beschäftigen wir uns mit dem Unterschied in der Art und Weise, wie Neulinge und Experten Quellcode lesen und interpretieren.

Die Struktur des Langzeitgedächtnisses und das Problem mit dem Umlernen

Die Speicherung von Gedächtnisinhalten im Langzeitgedächtnis werden erfolgreich als Entscheidungsnetzwerk modelliert. Entscheidungsnetzwerke werden unter anderem dazu verwendet, um Entscheidungsvorgänge, das Entstehen von Konzepten und das Wiedererkennen zu modellieren.

Die Theorie besagt, dass Gedächtnisinhalte in Netzwerke eingebunden werden. Bevor ein neuer Gedächtnisinhalt in ein solches Netzwerk eingefügt wird, wird erst einmal ein passender Ort dafür gesucht. Daraufhin wird das Netzwerk um das neue Element erweitert oder so modifiziert, dass das neue Element hineinpasst. Ein Knoten des Netzwerks hat neben Beziehungen zu anderen Knoten ein Image. Dieses Image kann ein Buchstabe, ein Wort, ein Ton, ein visuelles Bild oder ein Gefühl sein. Wenn Sie schon einmal eine Mind-Map gesehen haben, wird Ihnen das Prinzip vertraut sein.

Eine Mind-Map über Mind-Maps. Quelle: Wikipedia.

Der Aufbau der Netzwerke geschieht während des Trainings, nachdem diese in das Kurzzeitgedächtnis geladen wurden.Das Antrainieren von neuen Gedächtnisinhalten liegt normalerweise in der Größenordnung von einige Sekunden, allerdings können neue Inhalte das Netzwerk so umstrukturieren, dass Verbindungen zwischen bestehenden Inhalten aufgebrochen werden. Diese existierenden Elemente müssen dann abermals erlernt (umgelernt) werden, damit ein neues Netzwerk entstehen kann, dass alle bereits erlernten Inhalte umfasst. Natürlich ist jedes Umlernen mit einem Zeitaufwand verbunden und es kann für den Lernenden frustriend sein, dabei das Gefühl zu haben, sich rückwärts, also von einer neuen, bedeutsamen Erkenntnis weg zu bewegen.

Bertrand Meyer’s Erwiterungsprinzip kann man als Echo jenes mentalen Prozesses sehen, der danach trachtet, den Aufwands des Umlernens zu reduzieren. Vom Standpunkt der Evolution ist das durchaus sinnvoll. Wenn ich beispielsweise jemanden sehe, der sich vor schmerzen windet, nachdem er eine schwarze Eidechse mit gelben Flecken gegessen hat,  habe ich eine größere Überlebenschance (und damit die Chance, meine Gene weiterzugeben), wenn ich solche Reptilien meide.

Feuersalamander. Quelle: Wikipedia.

Wenn ich daraufhin jemaden eine schwarze Schlange mit gelben Flecken essen sehe, der diese Mahlzeit gut verträgt, möchte ich mich daran erinnern, das Schlangen bekömmlich sind, ohne dass ich darauf vergesse, das Eidechsen giftig sind. Ich möchte also, dass mein Geist offen für Erweiterungen aber [wo es notwendig ist] geschlossen für Änderungen ist und das ist genau das, was das Erweiterungsprinzip aussagt.

Wie bereits im letzten Artikel erwähnt hat sich unser Gehirn dahingehend entwickelt, dass es den Aufwand für das Suchen von Gedächtnisinhalten und für das Umlernen minimiert. Wenn wir also unseren Code so strukturieren, dass er unserem Langzeitgedächtnis ähnelt, wird er leichter und schneller von anderen verstanden werden. Entwicklungsprinzipien geben uns einen Einblick in die Art und Weise, wie unser Gehirn funktioniert, ganz im Gegensatz zu Regeln, die auf mathematischen Verfahren beruhen.

Vereinfachtes kognitives Modell. Quelle: Thomas Mullen.

Im nächsten Teil beschäftigen wir uns mit der kognitiven Belastung beim Lernen und worauf man aufpassen muss, wenn man diese Belastung soweit wie möglich reduzieren möchte.