Clean Coder

Verhaltensregeln für professionelle Programmierer

Robert C. Martin

• Verlag: MITP Verlag
• Jahr: 2014
• ISBN drucken:
  9783826696954
• eBook-ISBN:
  9783826632082
• Thema: Computer Science
• Thema: Computer Science General

Erfolgreiche Programmierer haben eines gemeinsam: Die Praxis der Software-Entwicklung ist ihnen eine Herzensangelegenheit. Auch wenn sie unter einem nicht nachlassenden Druck arbeiten, setzen sie sich engagiert ein. Software-Entwicklung ist für sie eine Handwerkskunst. In Clean Coder stellt der legendäre Software-Experte Robert C. Martin die Disziplinen, Techniken, Tools und Methoden vor, die Programmierer zu Profis machen. Dieses Buch steckt voller praktischer Ratschläge und behandelt alle wichtigen Themen vom professionellen Verhalten und Zeitmanagement über die Aufwandsschätzung bis zum Refactoring und Testen. Hier geht es um mehr als nur um Technik: Es geht um die innere Haltung. Martin zeigt, wie Sie sich als Software-Entwickler professionell verhalten, gut und sauber arbeiten und verlässlich kommunizieren und planen. Er beschreibt, wie Sie sich schwierigen Entscheidungen stellen und zeigt, dass das eigene Wissen zu verantwortungsvollem Handeln verpflichtet. Großartige Software ist etwas Bewundernswertes: Sie ist leistungsfähig, elegant, funktional und erfreut bei der Arbeit sowohl den Entwickler als auch den Anwender. Hervorragende Software wird nicht von Maschinen geschrieben, sondern von Profis, die sich dieser Handwerkskunst unerschütterlich verschrieben haben. Clean Coder hilft Ihnen, zu diesem Kreis zu gehören. Robert C. "Uncle Bob" Martin ist seit 1970 Programmierer und bei Konferenzen in aller Welt ein begehrter Redner. Zu seinen Büchern gehören Clean Code – Refactoring, Patterns, Testen und Techniken für sauberen Code und Agile Software Development: Principles, Patterns, and Practices. Als überaus produktiver Autor hat "Uncle Bob" Hunderte von Artikeln, Abhandlungen und Blogbeiträgen verfasst. Er war Chefredakteur bei The C++ Report und der erste Vorsitzende der Agile Alliance. Martin gründete und leitet die Firma Object Mentor, Inc., die sich darauf spezialisiert hat, Unternehmen bei der Vollendung ihrer Projekte behilflich zu sein. In diesem Buch lernen Sie: Was es bedeutet, sich als echter Profi zu verhalten Wie Sie mit Konflikten, knappen Zeitplänen und unvernünftigen Managern umgehen Wie Sie beim Programmieren im Fluss bleiben und Schreibblockaden überwinden Wie Sie mit unerbittlichem Druck umgehen und Burnout vermeiden Wie Sie Ihr Zeitmanagement optimieren Wie Sie für Umgebungen sorgen, in denen Programmierer und Teams wachsen und sich wohlfühlen Wann Sie "Nein" sagen sollten – und wie Sie das anstellen Wann Sie "Ja" sagen sollten – und was ein Ja wirklich bedeutet Aus dem Inhalt: Verantwortung übernehmen Feindliche Rollen Ein Teamplayer sein Verbindliche Sprache Der Flow-Zustand Schreibblockaden Test Driven Development Das Coding Dojo Akzeptanztests Teststrategien Zeitmanagement Aufwandsschätzungen Umgang mit Druck Mentoring, Lehrzeiten und die Handwerkskunst Werkzeuge und Hilfsmittel

Kapitel 1: Professionalität​

»Lach, Curtin, alter Junge. Das ist ein toller Streich, den uns Gott, das Schicksal oder die Natur gespielt hat, wer immer dir lieber ist. Aber wer oder was ihn auch gespielt hat, hatte jedenfalls Sinn für Humor! Ha!«

Howard, in: Der Schatz der Sierra Madre

So, Sie wollen also professioneller Software-Entwickler werden, nicht wahr? Sie wollen der Welt hoch erhobenen Hauptes zurufen: »Ich bin ein Profi!« Sie wollen, dass man Sie respektvoll betrachtet und Ihnen mit Achtung begegnet. Sie wollen, dass Mütter auf Sie zeigen und ihren Kindern erzählen, dass sie wie Sie sein sollen. Sie wollen das ganze Paket. Richtig?

1.1 Seien Sie vorsichtig, wonach Ihnen verlangt

Professionalität ist ein belasteter Begriff. Sicherlich ist er ein Emblem von Ehre und Stolz, aber eben auch das Kennzeichen für Verantwortung und Haftung. Das geht natürlich beides Hand in Hand. Sie können nicht auf etwas stolz sein und mit Ehre tragen, für das Sie nicht verantwortlich gemacht werden können.

Es ist viel einfacher, unprofessionell zu sein. Wer unprofessionell ist, braucht sich nicht für seine Arbeit verantworten – das überlässt er seinen Arbeitgebern. Wenn so jemand einen Fehler macht, sorgt der Arbeitgeber dafür, dass der Schlamassel behoben wird. Aber wenn ein Profi einen Fehler begeht, richtet er den Schaden wieder her.

Was würde passieren, wenn Ihnen bei einem Modul ein Bug durch die Lappen geht, der Ihre Firma 10.000 Euro kostet? Ein unprofessioneller​ Mitarbeiter zuckt mit den Schultern, murmelt »Dumm gelaufen« und schreibt das nächste Modul. Der Profi würde der Firma einen Scheck über 10.000 Euro ausstellen ^[1]!

Genau, fühlt sich schon etwas anders an, wenn es Ihr eigenes Geld ist, nicht wahr? Aber dieses Gefühl begleitet den Profi die ganze Zeit. Tatsächlich ist dieses Gefühl die Essenz der Professionalität. Weil es, wie Sie sehen werden, bei der Professionalität um die Übernahme von Verantwortung geht.

1.2 Verantwortung​ übernehmen

Sie haben die Einführung gelesen, oder? Falls nicht, blättern Sie bitte noch mal zurück. Darin wird der Kontext aufgestellt für alles, was in diesem Buch noch folgt.

Ich habe erfahren, was es bedeutet, Verantwortung zu übernehmen, als ich die Konsequenzen erlitt, es eben nicht zu tun.

1979 arbeitete ich für eine Firma namens Teradyne. Ich war als »verantwortlicher Ingenieur« für die Software zuständig, die ein mini- und mikrocomputerbasiertes System steuerte, das die Qualität von Telefonleitungen messen sollte. Der zentrale Minicomputer war über 300-Baud-Telefonleitungen (entweder extra dafür reserviert oder als Einwahlverbindung) mit Dutzenden Mikrocomputern als Satelliten verbunden, die die Messgeräte steuerten. Der Code war komplett in Assembler geschrieben.

Unsere Kunden waren die Servicemanager von großen Telefonfirmen. Jeder trug die Verantwortung für 100.000 Telefonanschlüsse oder mehr. Mein System half den Servicebereichsmanagern dabei, Fehlfunktionen und Probleme in den Leitungen zu finden und zu beheben, ehe sie von den Kunden bemerkt wurden. Das reduzierte die Anzahl der Kundenbeschwerden. Deren Zahl wurde behördlich gemessen und zur Regelung der Gebühren genutzt, die die Telefonfirmen für ihre Dienste berechnen durften. Kurz gesagt waren diese Systeme unglaublich wichtig.

Jede Nacht wurden diese Systeme routinemäßig durchgemessen, und der zentrale Minicomputer sorgte dafür, dass alle Satelliten-Mikrocomputer alle Telefonleitungen testeten, für die sie jeweils verantwortlich waren. Jeden Morgen bekam der Zentralcomputer die Liste der schadhaften Leitungen plus Hinweise auf die Art der Probleme. Die Servicebereichsmanager nutzten diese Berichte dann, um Zeitpläne und Reparaturaufträge für die Mechaniker zu erstellen, um die Defekte noch vor den Beschwerden der Kunden zu beheben.

Einmal lieferte ich ein neues Release an mehrere Dutzend Kunden aus. »Ausliefern« ist hier genau das richtige Wort. Ich schrieb die Software auf Bänder und verschickte sie an die Kunden. Diese setzen die Bänder in die jeweiligen Bandlaufwerke ein und starteten die Systeme neu.

Durch das neue Release wurden einige kleinere Mängel behoben und ein neues Feature hinzugefügt, das von unseren Kunden bestellt wurde. Wir hatten ihnen gesagt, dass dieses Feature zu einem bestimmten Datum erhältlich sein würde. Ich hatte es gerade noch geschafft, die Bänder per Express über Nacht zu versenden, damit sie am zugesagten Datum eintreffen konnten.

Zwei Tage später bekam ich einen Anruf von unserem Außendienstmanager Tom. Er berichtete mir, dass mehrere Kunden sich darüber beschwert hatten, dass der »nächtliche Testlauf« nicht abgeschlossen worden war und sie keine Berichte bekommen hatten. Mein Herz rutschte mir in die Hose, denn um die Software rechtzeitig versenden zu können, hatte ich mir erspart, diese Routine zu testen. Ich hatte die restliche Funktionalität des Systems weitgehend getestet, aber es hätte Stunden gedauert, eben diese Routine zu testen, und ich musste die Software ausliefern. Keiner der Bugfixes befand sich im Routine-Code, also fühlte ich mich auf der sicheren Seite.

Dass einer dieser nächtlichen Berichte unter den Tisch gefallen war, war ein großes Problem. Es bedeutete, dass die Mechaniker weniger zu tun hatten und später überbucht sein würden. Manche Kunden würden einen Defekt bemerken und sich beschweren. Der Verlust dieser nächtlichen Daten würde ausreichen, damit ein Servicebereichsmanager Tom anrufen und ihn »auf den Pott« setzen würde.

Ich startete unser Laborsystem, lud die neue Software und startete dann eine Routine. Das dauerte mehrere Stunden, wurde dann aber abgebrochen: Die Routine schlug fehl. Hätte ich diesen Test vorm Ausliefern durchlaufen lassen, hätten die Servicebereiche keine Daten verloren, und die Servicebereichsmanager hätten Tom nicht zur Rede stellen müssen.

Ich rief Tom an, um ihm zu sagen, dass ich das Problem reproduzieren könne. Er sagte mir, dass die meisten der anderen Kunden ihn in gleicher Angelegenheit schon angerufen hätten. Dann wollte er wissen, bis wann ich das beheben könne. Das wisse ich noch nicht genau, entgegnete ich, aber ich würde dran arbeiten. In der Zwischenzeit, ergänzte ich noch, sollten die Kunden auf die alte Software zurückgreifen. Tom war sauer auf mich und meinte, dass dies die Kunden doppelt träfe, weil sie nicht nur die Daten einer ganzen Nacht verloren hätten, sondern überdies auch nicht mit dem versprochenen neuen Feature arbeiten konnten.

Der Bug war schwer zu finden, und die Testläufe dauerten mehrere Stunden. Der erste Fix funktionierte nicht. Der zweite auch nicht. Ich probierte alles Mögliche aus und brauchte deswegen mehrere Tage, bis ich herausfand, wo der Hase im Pfeffer lag. Die ganze Zeit rief Tom mich alle paar Stunden an und hakte nach, wann ich endlich das Problem gelöst hätte. Er sorgte auch dafür, dass ich möglichst viel davon mitbekam, mit welchen Klagen ihm die Servicebereichsmanager in den Ohren lagen, und wie peinlich es für ihn war, ihnen sagen zu müssen, dass sie die alten Bänder einlegen sollten.

Zum Schluss fand ich endlich den Defekt, lieferte die neuen Bänder aus, und alles lief wieder normal. Tom, der nicht mein Boss war, regte sich wieder ab, und wir konnten die ganze Episode hinter uns lassen. Als sich die Wogen gelegt hatten, kam mein Boss vorbei und meinte: »Ich wette, dieses kommt nicht noch einmal vor.« Dem konnte ich nur zustimmen.

Beim Nachdenken über diese Geschichte erkannte ich, wie unverantwortlich es gewesen war, ohne Testen der Routine die Software auszuliefern. Ich hatte den Test natürlich deswegen vernachlässigt, um sagen zu können, dass meine Lieferung pünktlich war. Es ging für mich darum, nicht mein Gesicht zu verlieren. Weder hatte ich mir Gedanken um die Kunden gemacht noch Sorgen um meinen Arbeitgeber. Ich hatte nur auf meine eigene Reputation​ geachtet. Ich hätte bereits früh schon die Verantwortung übernehmen und Tom informieren sollen, dass die Tests nicht vollständig und zufriedenstellend abgeschlossen waren und ich nicht in der Lage war, die Software rechtzeitig auszuliefern. Das wäre nicht einfach gewesen, und Tom hätte sich sicherlich darüber aufgeregt. Aber kein Kunde hätte seine Daten verloren, und kein Servicemanager hätte angerufen.

1.3 Erstens: Richte keinen Schaden an​​

Wie übernimmt man also Verantwortung? Es gibt da einige Prinzipien. Vielleicht wirkt es arrogant, sich auf den Hippokratischen Eid zu beziehen, aber kann es eine bessere Quelle geben? Und tatsächlich: Ist es nicht wirklich sinnvoll, dass die erste Verantwortung und das erste Ziel eines angehenden Profis sein sollte, die eigene Macht für etwas Gutes einzusetzen?

Welche Schäden kann ein Software-Entwickler anrichten? Vom reinen Standpunkt der Software aus kann er (oder sie) sowohl die Funktion als auch die Struktur der Software beschädigen. Wir werden untersuchen, wie das genau zu vermeiden ist.

1.3.1 Beschädige nicht die Funktion​​​

Wir wollen naturgemäß, dass unsere Software funktioniert. Tatsächlich sind die meisten von uns heute Programmierer, weil wir es mal geschafft haben, dass etwas funktionierte, und dieses Gefühl wollen wir gerne wieder haben. Aber wir sind nicht die Einzigen, die wollen, dass die Software funktioniert. Unsere Kunden und Arbeitgeber wollen das auch. Tatsächlich bezahlen sie uns dafür, dass wir Software erstellen, damit sie genauso wie gewünscht funktioniert.

Wir beschädigen die Funktion unserer Software, wenn wir Bugs schaffen. Somit dürfen wir keine Bugs produzieren, wenn wir professionell sein wollen.

»Aber Moment mal!«, höre ich Sie sagen. »Das ist unrealistisch. Software ist zu komplex, als dass man sie ohne Bugs erstellen könnte.«

Natürlich haben Sie recht. Software ist zu komplex, als dass man sie ohne Bugs erstellen kann. Bedauerlicherweise entlässt Sie das nicht aus der Verantwortung. Der menschliche Körper ist zu komplex, als dass man ihn in seiner Gesamtheit verstehen könnte, aber Ärzte legen trotzdem einen Eid ab, keine Schäden daran anzurichten. Wenn die sich schon bei einem solchen Thema dermaßen festlegen, wie könnten wir uns dann selbst vom Haken lassen?

»Soll das etwa heißen, dass wir perfekt sein müssen?« Höre ich da jemanden widersprechen?

Nein, ich will Ihnen nur sagen, dass Sie für Ihre Unzulänglichkeiten verantwortlich sind. Die Tatsache, dass in Ihrer Software mit Sicherheit Bugs drinstecken werden, bedeutet nicht, dass Sie keine Verantwortung dafür tragen. Die Tatsache, dass es praktisch unmöglich ist, perfekte Software zu schreiben, heißt im Gegenzug nicht, dass Sie die Verantwortung für die Unvollkommenheit ablehnen können.

Es gehört zum Los eines Profis, für Fehler verantwortlich zu sein, auch wenn diese Fehler praktisch mit Sicherheit geschehen werden. Also, mein angehender Profi, Sie müssen nun als Allererstes lernen, sich zu entschuldigen. Entschuldigungen​​ sind notwendig, aber nicht ausreichend. Sie dürfen nicht einfach die gleichen Fehler immer wieder machen. Wenn Sie in Ihrer Profession reifen, sollte Ihre Fehlerrate schnellstmöglich gegen Null gehen. Sie wird nie auf Null landen, aber es obliegt Ihrer Verantwortung, dem so nahe wie möglich zu kommen.

Die Qualitätssicherung sollte nichts finden

Wenn Sie also Ihre Software freigeben, sollten Sie davon ausgehen, dass von der Qualitätssicherung keine Probleme entdeckt werden. Es ist außerordentlich unprofessionell, an die Qualitätssicherung Code zu schicken, von dem Sie wissen, dass er mangelhaft ist. Und bei welchem Code können Sie davon ausgehen, dass er mangelhaft ist? Das ist jeder Code, bei dem Sie unsicher sind!

Manche nutzen die Qualitätssicherung als Bug-Netz​. Sie schicken der QS nicht gründlich geprüften Code und verlassen sich darauf, dass dort die Bugs gefunden und an die Entwickler zurückgemeldet werden. Tatsächlich vergüten manche Firmen ihre Qualitätssicherung anhand der aufgedeckten Bugs. Je mehr Bugs, desto besser die Entlohnung.

Es ist egal, dass dies ein absolut kostspieliges Verhalten ist, das Firma und Software beschädigt. Es ist egal, dass dieses Verhalten Zeitpläne ruiniert und das Vertrauen des Unternehmens ins Entwicklerteam untergräbt. Es ist egal, dass ein solches Verhalten einfach nur faul und unverantwortlich ist. Wenn man Code für die Qualitätssicherung freigibt, von dem man nicht weiß, ob er funktioniert, ist das einfach unprofessionell. Das verletzt die Regel »Richte keinen Schaden an«.

Wird die Qualitätssicherung​ Bugs finden? Wahrscheinlich, also sollte man sich schon mal ein paar Entschuldigungen zurechtlegen – und sich dann auf Weg machen herauszufinden, warum diese Bugs durchrutschen konnten, und etwas dafür tun, dass das nicht noch einmal passiert.

Jedes Mal, wenn die Qualitätssicherung – oder schlimmer noch: ein User! – ein Problem findet, sollten Sie überrascht und verärgert sein und entschlossen verhindern, dass das erneut passiert.

Sie müssen wissen, ob er funktioniert

Woher wissen Sie, dass Ihr Code funktioniert? Ganz einfach: Testen​ Sie den Code. Testen​ Sie ihn noch einmal. Testen Sie ihn von vorne. Testen Sie ihn von hinten. Testen Sie ihn hoch und runter!

Vielleicht machen Sie sich Sorgen darüber, dass das Testen​ des Codes so viel von Ihrer wertvollen Zeit frisst. Immerhin müssen Sie Zeitpläne befolgen und Termine einhalten. Wenn Sie die ganze Zeit nur testen, kriegen Sie nie irgendwas fertig geschrieben. Gutes Argument! Also sollten Sie Ihre Tests​ automatisieren. Schreiben Sie Unit-Tests, die Sie ganz kurzfristig ausführen können, und lassen Sie diese Tests so oft wie möglich laufen.

Wie viel von dem Code sollte mit diesen automatisierten Unit-Tests getestet werden? Muss ich diese Frage wirklich beantworten? Der gesamte Code! Der. Gesamte. Code.

Rate ich zu einer hundertprozentigen Testabdeckung? Nein, dazu rate ich nicht. Ich fordere sie! Jede einzelne Codezeile, die Sie schreiben, sollte getestet werden. Basta!

Ist das nicht unrealistisch? Natürlich nicht. Sie schreiben nur deswegen Code, weil Sie erwarten, dass er ausgeführt wird. Wenn er also Ihrer Erwartung nach ausgeführt werden wird, sollten Sie auch wissen, dass er funktioniert. Der einzige Weg, um das herauszubekommen, sind Tests.

Ich bin der Hauptentwickler und Committer für ein Open Source-Projekt namens FitNesse. Während ich dies hier schreibe, gibt es in FitNesse 60.000 Zeilen Quellcode. 26.000 davon enthalten die über 2.000 Unit-Tests. Laut Emma ^[2] liegt die Abdeckung dieser 2.000 Tests bei etwa 90 %.

Warum ist meine Code-Abdeckung nicht höher? Weil Emma nicht alle Codezeilen sehen kann, die ausgeführt werden! Ich gehe davon aus, dass die Abdeckung deutlich höher ist als 90 %. Beträgt die Abdeckung 100 %? Nein, 100 % ist nur eine Annäherungslinie.

Aber ist mancher Code nicht schwer zu testen? Ja, aber nur deswegen, weil dieser Code so designt wurde, dass er schwer zu testen ist. Die Lösung dafür ist, Ihren Code so designen, dass er einfach zu testen ist. Und der beste Weg ...

Inhaltsverzeichnis

• Impressum
• Vorwort
• Einführung
• Danksagungen
• Über den Autor
• Auf dem Titelbild
• Unverzichtbare Einführung
• Kapitel 1: Professionalität​
• Kapitel 2: Nein sagen
• Kapitel 3: Ja sagen​
• Kapitel 4: Programmieren​
• Kapitel 5: Test Driven Development​
• Kapitel 6: Praktizieren und Üben​
• Kapitel 7: Akzeptanztests
• Kapitel 8: Teststrategien​
• Kapitel 9: Zeitmanagement​
• Kapitel 10: Aufwandsschätzungen​
• Kapitel 11: Äußerer Druck​
• Kapitel 12: Teamwork​
• Kapitel 13: Teams und Projekte
• Kapitel 14: Mentoring, Lehrzeiten und die Handwerkskunst
• Anhang A: Werkzeuge und Hilfsmittel