Five Lines of Code (eBook)

Einführung

In sehr jungen Jahren schon brachte mir mein Vater bei zu programmieren. Ich habe über Strukturen nachgedacht, solange ich denken kann. Meine Motivation war es immer, Menschen zu helfen. Dafür stehe ich morgens auf. Lehrberufe haben mich deshalb schon immer gereizt. Als mir an der Universität eine Stelle als Lehrassistent angeboten wurde, habe ich sofort zugegriffen. Und ich hatte einige dieser Stellen. Dann jedoch hatte ich Pech, und in einem Semester gab es nichts, was ich lehren konnte.

Unternehmerisch wie ich bin, gründete ich eine Organisation, in der Studierende andere Studierende unterrichten sollten. Jede und jeder war als Sprecher*in oder Zuhörer*in willkommen, und die Themen reichten von Lektionen, die man aus Hobbyprojekten gelernt hatte, bis zu fortgeschrittenen Themen, die über den Lehrplan der Universität hinausgingen. Ich dachte, so könne ich unterrichten. Ich hatte nicht Unrecht. Wie sich herausstellte, sind Informatikerinnen und Informatiker ein scheues Völkchen, und ich musste fast sechzig Wochen in Folge sprechen, um meine Organisation zum Laufen zu bringen. Ich habe in dieser Zeit viel gelernt, sowohl über meine Themen als auch über das Lehren. Außerdem habe ich mit diesen Vorträgen eine Gemeinschaft von Neugierigen geschaffen. Mit einigen von ihnen sind engste Freundschaften entstanden.

Einige Zeit, nachdem ich die Universität verlassen hatte, traf ich mich mit einem dieser Freunde. Aus Langeweile fragte er mich, ob ich einen Vortrag improvisieren könne, nachdem ich so viele gehalten hatte. »Probieren wir’s aus« war meine Antwort. Wir klappten einen Laptop auf, und ohne eine einzige Pause schrieb ich auf, was zum Beispiel der gesamte erste Teil dieses Buches werden sollte.

Als ich die Finger von der Tastatur nahm, war Ehrfurcht im Blick meines Freundes. Er dachte, das sei meine Demonstration gewesen. Doch ich hatte etwas anderes vor: Ich wollte ihm Refactoring beibringen.

Mein Ziel war ambitioniert. Nach einer Stunde sollte er programmieren können wie ein Meister-Refactorer. Codequalität und Refactoring sind verzwickte Themen. Es war klar, dass wir das nötige Wissen vortäuschen mussten. Ich betrachtete meinen Code und versuchte, Regeln zu finden, deren Befolgen ihn dazu bringen würde, das Richtige zu tun, die aber gleichzeitig einfach zu merken waren. Obwohl er das Fachwissen so nur vortäuschte, machte mein Freund während des Experiments echte Verbesserungen an meinem Code. Das Ergebnis war vielversprechend, und er lernte so schnell dazu, dass ich noch am selben Abend alles aufschrieb, was wir behandelt hatten. Wenn wir an meinem Arbeitsplatz unerfahrene Programmierer anstellten, wiederholte ich die Übung mit ihnen, und langsam sammelte und baute ich die Regeln und Muster für dieses Buch.

Das Ziel: die ausgewählten Regeln und Refactorings

Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn man nichts mehr weglassen kann

– Antoine de Saint-Exupéry

Auf der Welt gibt es Hunderte von Refactorings. Ich habe für dieses Buch nur dreizehn ausgewählt, weil ich glaube, dass tiefgehendes Wissen wertvoller ist als breite, aber oberflächliche Kenntnisse. Außerdem wollte ich eine zusammenhängende Geschichte erzählen, weil das Thema auf diese Weise mental einfacher zu organisieren ist. Dieselben Argumente gelten für die Auswahl der Regeln.

Es gibt nichts Neues unter der Sonne

– Prediger 1, 9

Ich behaupte gar nicht, mir für dieses Buch viel Neues überlegt zu haben, aber ich denke, ich habe vorhandene Dinge auf eine vorteilhafte Art neu kombiniert. Viele der Regeln sind aus Robert C. Martins Clean Code (Pearson, 2008) abgeleitet, aber angepasst, um sie leichter verstehen und anwenden zu können. Viele Refactorings stammen aus Martin Fowlers Refactoring (Addison-Wesley Professional, 1999), wurden aber angepasst, um die Prüfungen des Compilers zu nutzen anstelle einer umfangreichen Testsuite.

Das Publikum und der Weg

Dieses Buch besteht aus zwei sehr unterschiedlichen Teilen. Der erste bietet ein solides Grundwissen über Refactoring und richtet sich an einzelne Programmierende. Das Ziel ist nicht Umfang, sondern Verständlichkeit. Dieser Teil ist für Leserinnen und Leser, die noch an ihrem Grundverständnis von Refactoring arbeiten: Studierende, Berufseinsteigerinnen und -einsteiger und alle, die als Hobby programmieren. Wenn du den Beispielcode anschaust und denkst, dass er leicht zu verbessern ist, dann ist Teil I nichts für dich.

In Teil II konzentriere ich mich mehr auf die Umgebung und das Team. Ich habe die – meiner Meinung nach – wichtigsten Lektionen über Softwareentwicklung in der realen Welt ausgewählt. Einige Themen sind theoretischer Natur: »Mit dem Compiler zusammenarbeiten« (Kapitel 7) und »Folge der Struktur im Code« (Kapitel 11). Andere sind vorwiegend praktisch: »Lerne, das Löschen zu lieben« (Kapitel 9) und »Schlechter Code soll schlecht aussehen« (Kapitel 13). Dieser Teil sollte auch für erfahrene Entwicklerinnen und Entwickler noch Neues enthalten.

Teil I verwendet ein durchgehendes Codebeispiel. Die Kapitel sind so eng miteinander verbunden und sollten in der richtigen Reihenfolge gelesen werden. In Teil II stehen die Kapitel für sich, bis auf einige Querverweise. Wenn du keine Zeit hast, das ganze Buch zu lesen, kannst du dir problemlos die spannendsten Themen aus Teil II herauspicken und separat lesen.

Über das Lehren

Ich habe viel Zeit damit verbracht, über das Lehren nachzudenken. Wissen und Fähigkeiten weiterzugeben, bietet viele Herausforderungen. Lehrende müssen Motivation und Selbstvertrauen vermitteln und zur Reflexion anregen. Das Gehirn des Schülers oder der Schülerin würde lieber Energie sparen und versucht, vom Stoff abzulenken.

Um dieses sich wehrende Gehirn zum Lernen zu bringen, müssen wir zunächst Motivation erzeugen. Dazu präsentiere ich meist eine einfach aussehende Aufgabe. Wenn den Lernenden klar wird, dass sie keine Lösung finden können, treibt die natürliche Neugierde sie weiter. Das ist der Zweck des Codebeispiels in Teil I. »Mach diesen Code besser« klingt wie eine einfache Aufgabe, aber der Code hat bereits eine Qualität, bei der Verbesserungen nicht sofort offensichtlich sind.

Der zweite Schritt ist, den Schülerinnen und Schülern das Selbstvertrauen zu geben, ihr neues Wissen anzuwenden und damit zu experimentieren. Wie wichtig dieser Schritt ist, wurde mir in einem Französischkurs klar. Wenn uns unsere Lehrerin eine neue Phrase beibringen wollte, folgte sie immer denselben Schritten:

1. Sie forderte jeden von uns auf, die Phrase nachzusprechen: pures Nachahmen, um es einmal gesagt zu haben.

2. Sie stellte jedem von uns eine Frage. Wir verstanden die Frage nicht immer, aber aus der Betonung ging hervor, dass es eine Frage war. Da wir keine anderen Werkzeuge hatten, wiederholten wir die Phrase von zuvor. Die Wiederholung gab uns Selbstvertrauen in die Verwendung der Phrase und ein erstes Stück Kontext dafür. Verständnis begann.

3. Dann forderte die Lehrerin uns auf, die Phrase in einem Gespräch zu verwenden. Die Fähigkeit, gelernte Bausteine zu etwas Neuem zusammenzusetzen, ist das eigentliche Ziel der Lehre und setzt Verständnis und Selbstvertrauen voraus.

Ich habe gelernt, dass dieses Vorgehen dem Shuhari entspricht, einem Konzept aus dem japanischen Kampfsport, das auch außerhalb dieses Sports zunehmend populär wird. Es besteht aus drei Teilen: »Shu« ist Nachahmung ohne Frage und Verständnis, »ha« ist Variation – eine kleine Änderung am Erlernten –, und »ri« ist Originalität, das völlige Verlassen des Bekannten.

Shuhari unterstreicht Teil I. Ich empfehle, zunächst den Regeln zu folgen, auch ohne sie zu verstehen. Dann, wenn du den Wert der Regeln verstehst, fang an, sie zu variieren. Und dann, wenn du die Regeln gemeistert hast, kannst du dich mit Code Smells (etwa: »übel riechendem Code«) beschäftigen. Für Refactoring zeige ich Beispiele an echtem Code, und die Lesenden sollen die Änderungen nachvollziehen (Nachahmung). Dann zeige ich dasselbe Refactoring in einem anderen Kontext (Variation). Schließlich präsentiere ich ein weiteres Beispiel, in dem das Refactoring angewendet werden könnte. Ich ermutige die Leserschaft, sich selbst daran zu versuchen (Originalität).

Du kannst dein Vorgehen anhand dieses Buches verifizieren und den Code anhand der Git Tags. Wenn du nicht selbst am Code arbeitest, wird Teil I viel Wiederholung enthalten. Ich möchte dich dazu anhalten, mit den Händen auf der Tastatur zu lesen.

Über den Code

Dieses Buch enthält viele Codebeispiele, sowohl in nummerierten Listings als auch im Fließtext. In beiden Fällen ist Code in nicht proportionaler Schrift gesetzt, wie in diesem Beispiel, um ihn vom Text abzusetzen. Code, auf den sich die...