Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: MITP
- Kategorie: Wissenschaft und neue Technologien
- Serie: mitp Professional
- Sprache: Deutsch
- Aus der Feder des legendären Softwareentwicklers Robert C. Martin (»Uncle Bob«), Autor des Bestsellers Clean Code
- Standards und ethische Grundsätze für die Entwicklung von zuverlässiger und vertrauenswürdiger Software
- Mit fünf Kerndisziplinen zu besserem und nachhaltigerem Code: Test-Driven Development (TDD), Refactoring, einfaches Design, kollaborative Entwicklung und Akzeptanztests
Software Craftsmanship ist kein Beruf, sondern eine Berufung. Der legendäre Softwareentwickler Robert C. Martin (»Uncle Bob«) gibt Ihnen mit diesem Buch einen pragmatischen und praktischen Leitfaden für die Praktiken an die Hand, die für die Softwareentwicklung essenziell sind.
Uncle Bob erläutert die Methoden, Standards und ethischen Grundsätze, die es Ihnen ermöglichen, robusten und effektiven Code zu schreiben, auf den Sie stolz sein können. Er erörtert wichtige Standards für die Softwareentwicklung, zeigt auf, wie sich die Erwartungen, die andere an Entwickler stellen, von ihren eigenen unterscheiden, und hilft Ihnen dabei, beide Vorstellungen in Einklang zu bringen.
Zum Abschluss geht er auf die Berufsethik für die professionelle Programmierung ein und erläutert die Prinzipien, denen alle Entwickler folgen sollten, um sicheren, nachhaltigen und wartbaren Code zu gewährleisten.
Mit den Methoden und Konzepten aus diesem Buch können sowohl Programmierer als auch ihre Manager konsequent Code liefern, der Vertrauen schafft, statt es zu untergraben – bei Usern und gleichermaßen der gesamten Gesellschaft, die auf Software angewiesen ist.
Aus dem Inhalt- Auf dem Weg zum »Polarstern« der Software Craftsmanship: wissen, wie man gut programmiert
- Praktische Anleitungen zur Anwendung von fünf Kerndisziplinen: testgetriebene Entwicklung (TDD), Refactoring, einfaches Design, kollaborative Entwicklung und Akzeptanztests
- Wie Entwickler und Teams Produktivität, Qualität und Courage fördern können
- Die wahre Bedeutung von Integrität und Teamarbeit sowie zehn spezifische Grundsätze, denen jeder professionelle Softwareentwickler folgen sollte
»Zum richtigen Zeitpunkt eine Erinnerung an die ständig zunehmende Komplexität unserer programmatischen Welt und daran, dass wir es dem Vermächtnis der Menschheit – und uns selbst – schuldig sind, ethische Entwicklung zu betreiben.«
– Aus dem Vorwort von Stacia Heimgartner Viscardi, CST & Agile MentorinSie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 433
Veröffentlichungsjahr: 2022
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Stimmen zum Buch
»Bobs Clean Craftsmanship hat großartige Arbeit dabei geleistet, den Zweck agiler technischer Praktiken zu erklären, zusammen mit einer tiefen historischen Basis, die aufzeigt, wie sie entstanden sind, sowie einer Positionierung, wieso er davon ausgeht, dass sie immer von Bedeutung sein werden. Seine Beteiligung an der Geschichte und der Entstehung von Agilität, sein umfassendes Verständnis der Praktiken und ihres Sinns spiegeln sich im gesamten Manuskript deutlich wider.«
– Tim Ottinger, bekannterAgile Coach und Autor.
»Bobs Schreibstil ist ausgezeichnet. Er ist leicht zu lesen, und die Konzepte werden so detailliert erklärt, dass auch ein neuer Programmierer sie verstehen kann. Bob hat sogar einige lustige Anekdoten parat, die einen beim Lesen angenehm aus dem Konzept bringen. Der wahre Wert des Buchs liegt in dem Schrei nach Veränderung, nach etwas Besserem ... dem Schrei nach professionellen Programmierern ... der Erkenntnis, dass Software überall ist. Außerdem glaube ich, dass die Historie, die Bob bereitstellt, von großem Wert ist. Mir gefällt, dass er keine Zeit mit Schuldzuweisungen verschwendet, wer dafür verantwortlich ist, dass wir dahin gekommen sind, wo wir jetzt sind. Bob ruft die Menschen zum Handeln auf und fordert sie auf, Verantwortung zu übernehmen, indem sie ihre Standards und ihr Niveau an Professionalität erhöhen, auch wenn das manchmal bedeutet, sich zu wehren.«
– Heather Kanser
»Als Softwareentwickler müssen wir ständig wichtige Probleme für unsere Arbeitgeber, Kunden, Kollegen und unser zukünftiges Ich lösen. Eine App zum Laufen zu bringen, auch wenn es schwierig ist, ist nicht genug, es macht Sie nicht zum Craftsman. Wenn eine App funktioniert, haben Sie den Eignungstest bestanden. Sie haben vielleicht das Potenzial, ein Craftsman zu werden, aber es gibt noch mehr, was Sie beherrschen müssen. Auf diesen Seiten beschreibt Bob klar und deutlich die Techniken und Verantwortlichkeiten, um über den App-Eignungstest hinauszugehen und zeigt den Weg, wie Sie ein ernsthafter Software Craftsman werden.«
– James Grenning, Autor von »Test-Driven Developmentfor Embedded C« und Mitverfasser des Agilen Manifests
»Bob ist einer der wenigen berühmten Entwickler, mit denen ich gerne an einem technischen Projekt arbeiten würde. Nicht, weil er ein guter Entwickler, berühmt oder ein guter Kommunikator ist, sondern weil er mir hilft, ein besserer Entwickler und ein besseres Teammitglied zu sein. Er hat jeden wichtigen Entwicklungstrend Jahre vor allen anderen erkannt und war in der Lage, dessen Tragweite zu erklären, was mich zum Lernen ermutigte. Als ich anfing, fehlte in diesem Bereich – abgesehen davon, ehrlich und ein guter Mensch zu sein – jede Vorstellung von Handwerkskunst und Ethik. Jetzt scheint es das Wichtigste zu sein, was professionelle Entwickler lernen können, sogar noch vor dem Programmieren selbst. Ich freue mich, dass Bob wieder den Weg vorgibt. Ich kann es kaum erwarten, seine Perspektive zu hören und sie in meine eigene Praxis einzubringen.«
– Daniel Markham, Principal,Bedford Technology Group, Inc.
In Gedenken an Mike Beedle
Robert C. Martin
Clean Craftsmanship
Best Practices, Standards und Ethik für die Softwareentwicklung
Impressum
Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN 978-3-7475-0418-5 1. Auflage 2022
www.mitp.de E-Mail: [email protected] Telefon: +49 7953 / 7189 - 079 Telefax: +49 7953 / 7189 - 082
© 2022 mitp Verlags GmbH & Co. KG
Authorized translation from the English language edition, entitled CLEAN CRAFTMANSHIP: PROGRAMMING WITH PRIDE, 1st Edition by ROBERT MARTIN, published by Pearson Education, Inc, publishing as Addison-Wesley Professional, Copyright © 2022 Pearson Education, Inc.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.
GERMAN language edition published by MITP VERLAGS GMBH & CO. KG, Copyright © 2022
Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Lektorat: Janina Bahlmann Sprachkorrektorat: Christine Hoffmeister Covergestaltung: Christian Kalkert Bildnachweis: Richie_K / stock.adobe.comelectronic publication: III-satz, Flensburg, www.drei-satz.de
Dieses E-Book verwendet das ePub-Format und ist optimiert für die Nutzung mit dem iBooks-reader auf dem iPad von Apple. Bei der Verwendung anderer Reader kann es zu Darstellungsproblemen kommen.
Der Verlag räumt Ihnen mit dem Kauf des E-Books das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und Einspeicherung und Verarbeitung in elektronischen Systemen.
Der Verlag schützt seine E-Books vor Missbrauch des Urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die E-Books mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert.
Bei Kauf in anderen E-Book-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.
Vorwort
Ich erinnere mich, dass ich Uncle Bob im Frühjahr 2003 traf, kurz nachdem Scrum in unserem Unternehmen und in unseren Technologieteams eingeführt worden war. Als skeptischer, junger Scrum Master erinnere ich mich daran, dass ich Bob zuhörte, als er uns in TDD und einem kleinen Tool namens FitNesse unterrichtete, und ich erinnere mich, dass ich mir dachte: »Warum sollten wir jemals Testfälle schreiben, die zuerst fehlschlagen? Kommt das Testen nicht erst nach dem Coding?« Ich habe mich oft am Kopf gekratzt, wie viele meiner Teammitglieder, und doch erinnere ich mich bis heute deutlich an Bobs spürbare Begeisterung für das Code-Handwerk, als wäre es erst gestern gewesen. Ich erinnere mich an seine Direktheit, als er sich eines Tags unseren Bug-Backlog ansah und uns fragte, warum in aller Welt wir so schlechte Entscheidungen über Softwaresysteme treffen würden, die uns eigentlich nicht gehörten – »Diese Systeme sind Firmeneigentum, nicht euer persönliches Eigentum.« Seine Leidenschaft machte uns neugierig, und anderthalb Jahre später hatten wir durch Refactoring eine automatisierte Testabdeckung von etwa 80 % und eine saubere Codebasis, die uns Anpassungen wesentlich erleichterte und zu zufriedeneren Kunden – und zufriedeneren Teams – führte. Danach kamen wir blitzschnell voran und nutzten unsere »Definition ofdone« wie eine Rüstung, um uns vor den immer lauernden Codekobolden zu schützen; wir hatten im Wesentlichen gelernt, wie wir uns vor uns selbst schützen konnten. Mit der Zeit entwickelten wir eine große Sympathie für Uncle Bob, der sich für uns immer mehr wie ein richtiger Onkel anfühlte – ein warmherziger, entschlossener und mutiger Mann, der uns mit der Zeit half, zu lernen, für uns selbst einzustehen und das Richtige zu tun. Während die Onkel mancher Kinder ihnen beibrachten, wie man Fahrrad fährt oder angelt, lehrte uns unser Uncle Bob, unsere Integrität nicht aufs Spiel zu setzen – und bis heute ist die Fähigkeit und der Wunsch, jeder Situation mit Mut und Neugierde zu begegnen, die beste Lektion meiner Karriere.
Ich nahm Bobs frühe Lektionen mit auf meine Reise, als ich mich als agiler Coach in die Welt hinauswagte und habe schnell selbst beobachtet, dass die besten Produktentwicklungsteams herausfanden, wie sie ihre eigenen Best Practices für ihre einzigartigen Kontexte, für ihre speziellen Kunden, in ihren jeweiligen Branchen zusammenstellen konnten. Ich erinnerte mich an Bobs Lektionen, als ich feststellte, dass die besten Entwicklungswerkzeuge der Welt nur so gut sind wie ihre menschlichen Bediener – die Teams, die die besten Anwendungen dieser Werkzeuge in ihren eigenen Domänen fanden. Ich beobachtete, dass Teams einen hohen Prozentsatz an Unit-Test-Abdeckung erreichen können, um den Punkt abzuhaken und die Metrik zu erfüllen, nur um dann feststellen, dass ein großer Prozentsatz dieser Tests fehlerhaft war – die Metrik wurde erfüllt, aber es wurde kein Wert erbracht. Die besten Teams brauchten sich nicht wirklich um Metriken zu kümmern; sie hatten ein Ziel, Disziplin, Stolz und Verantwortung – und die Metriken sprachen in jedem Fall für sich selbst. Clean Craftsmanship verwebt all diese Lektionen und Prinzipien mit praktischen Codebeispielen und Erfahrungen, um den Unterschied zu verdeutlichen, zwischen etwas zu schreiben, um eine Frist einzuhalten, und dem tatsächlichen Aufbau von etwas Nachhaltigem für die Zukunft.
Clean Craftsmanship erinnert uns daran, uns niemals mit weniger zufrieden zu geben und mit furchtloser Kompetenz über diese Erde zu wandeln. Dieses Buch wird Sie wie ein alter Freund daran erinnern, worauf es ankommt, was funktioniert, was nicht funktioniert, was Risiken schafft und was sie verringert. Diese Lektionen sind zeitlos. Vielleicht stellen Sie fest, dass Sie einige der darin enthaltenen Techniken bereits praktizieren, und ich wette, Sie werden etwas Neues finden oder zumindest etwas, das Sie fallengelassen haben, weil Sie irgendwann vor Terminen oder anderem Druck in Ihrer Karriere kapituliert haben. Wenn Sie neu in der Welt der Entwicklung sind – sei es im Management oder in der Technik – werden Sie vom Besten lernen, und selbst die Geübtesten und Kampfesmüden werden Wege finden, sich zu verbessern. Vielleicht hilft Ihnen dieses Buch, Ihre Leidenschaft wiederzuentdecken, Ihren Wunsch zu erneuern, Ihr Handwerk zu verbessern oder Ihre Energie erneut der Suche nach Perfektion zu widmen, ungeachtet der Hindernisse, die sich Ihnen in den Weg stellen.
Softwareentwickler regieren die Welt, und Uncle Bob ist wieder da, um uns an die professionellen Praktiken derjenigen zu erinnern, die so viel Macht haben. Er macht dort weiter, wo er mit Clean Code aufgehört hat. Da Softwareentwickler buchstäblich die Regeln der Menschheit schreiben, erinnert uns Uncle Bob daran, dass wir einen strengen ethischen Kodex einhalten müssen, eine Verantwortung haben, zu wissen, was der Code macht, wie die Menschen ihn verwenden und wo er bricht. Softwarefehler kosten Menschen ihren Lebensunterhalt – und ihr Leben. Software beeinflusst die Art und Weise, wie wir denken, die Entscheidungen, die wir treffen, und durch künstliche Intelligenz und prognostische Analytik beeinflusst sie das Sozial- und Herdenverhalten. Daher müssen wir verantwortungsbewusst sein und mit großer Sorgfalt und Empathie handeln – die Gesundheit und das Wohlbefinden der Menschen hängen davon ab. Uncle Bob hilft uns, dieser Verantwortung gerecht zu werden, und er hilft uns, die Fachleute zu werden, die unsere Gesellschaft von uns erwartet und verlangt.
Da sich das Agile Manifest zum Zeitpunkt der Verfassung dieses Vorworts seinem zwanzigsten Geburtstag nähert, ist dieses Buch eine perfekte Gelegenheit, zu den Grundlagen zurückzukehren: zum richtigen Zeitpunkt eine bescheidene Erinnerung an die ständig zunehmende Komplexität unserer programmatischen Welt und daran, dass wir es dem Vermächtnis der Menschheit – und uns selbst – schuldig sind, ethische Entwicklung zu betreiben. Nehmen Sie sich die Zeit, Clean Craftsmanship zu lesen. Verinnerlichen Sie sich die Prinzipien. Üben Sie sie. Verbessern Sie sie. Leiten Sie andere an. Behalten Sie dieses Buch in Ihrem Bücherregal. Lassen Sie dieses Buch Ihr alter Freund sein – Ihr Uncle Bob, Ihr Wegweiser – wenn Sie sich mit Neugier und Mut auf den Weg durch diese Welt machen.
– Stacia Heimgartner Viscardi, CST & Agile Mentor
Vorwort des Übersetzers der deutschen Ausgabe
Ich hatte leider noch nicht die Gelegenheit, Robert C. Martin persönlich kennenzulernen. Trotzdem kenne ich, wie viele Softwareentwickler und Softwarearchitekten in meinem Umfeld, die meisten seiner Werke. Deswegen war ich auch hocherfreut, als ich gefragt wurde, ob ich sein neuestes Buch übersetzen könne.
Ich muss zugeben, dass ich Martins Bücher bisher auf Englisch gelesen hatte. Ich schreibe Bücher auf Deutsch und Englisch und habe auch schon Bücher von Freunden übersetzt. Clean Craftsmanship zu übersetzen, war aber ein Abenteuer für sich. Uncle Bob verwendet eine sehr lebendige Sprache und spielt mit Wörtern und Begriffen. Beim Übersetzen eines englischen Begriffs muss man sich oft für eine Facette, eine Bedeutung entscheiden. Das wäre an einigen Stellen den Wortspielereien von Robert C. Martin nicht gerecht geworden. Deswegen haben wir im Buch einige Begriffe nicht übersetzt, z.B. das titelgebende Craftsmanship oder einige Begriffe aus der IT, die auch den meisten deutschen »Softwerkern« geläufig sein sollten. Diese Begriffe zu übersetzen, hätte mehr Verwirrung gestiftet, als Klarheit gebracht. Ich bin mir bewusst, dass dies eine subjektive Entscheidung ist und einige Leser anderer Ansicht sein werden. Seien Sie aber versichert, dass wir über jeden der hier verwendeten Fachbegriffe lange diskutiert haben, ob wir ihn übersetzen oder belassen, und dies auch mit früheren Übersetzungen von Robert C. Martins Büchern abgeglichen haben.
Ich bin selbst seit mehr als 20 Jahren in der Softwareentwicklung tätig und musste bei einigen seiner Beispiele aus frühen Jahren schmunzeln, weil ich sie teilweise noch selbst miterleben durfte. Auch wenn ich gottlob nie Programme auf Lochkarten erstellen musste, habe ich doch zumindest in meinen frühen Jahren als Entwickler einmal Lochkarten in der Hand gehabt. Und die frühen Versionsverwaltungssysteme habe ich selbst noch als Entwickler verwendet. Auch wenn diese Beispiele aus einer anderen Zeit zu stammen scheinen, bringen sie einem doch die Entwicklung unseres Handwerks näher und tragen dazu bei, dass wir besser verstehen, warum manche Dinge heute so sind, wie sie sind.Ich bin selbst ein großer Fan von testgetriebener Entwicklung, auch wenn ich meine Leidenschaft in echten Projekten oft nicht so ausleben kann, wie ich es gerne tun würde. Dazu sind Projekte oft zu sehr ein Zusammenspiel zahlreicher Individuen, und die testgetriebene Entwicklung ist nicht so weitverbreitet, wie sie es sein sollte. Robert C. Martin liefert in diesem Buch ein paar sehr gelungene Beispiele, wie Testgetriebene Entwicklung in der Praxis funktioniert, und er liefert auch sehr gute Argumente, warum man testgetrieben entwickeln sollte. Argumente für Entwickler und Manager. Ich muss zugeben, dass es mir oft nicht leicht gefallen ist, die Testgetriebene Entwicklung in Projekten zu verteidigen. Nach dem Übersetzen und Lesen dieses Buchs bin ich mir aber sicher, dass es mir leichter fallen wird, dies in Zukunft zu tun.
Ich wünsche Ihnen viel Spaß beim Lesen und Lernen.
– Uwe M. Schirmer Software Architekt, Autor und Übersetzer
Einleitung
Bevor wir beginnen, müssen wir uns mit zwei Fragen befassen, um sicherzustellen, dass Sie, verehrte Leserinnen und Leser, den Rahmen verstehen, in dem dieses Buch präsentiert wird.
Über den Begriff »Craftsmanship«
Der Beginn des 21. Jahrhunderts war von einer Kontroverse über die Sprache geprägt. Auch wir in der Softwarebranche hatten unseren Anteil an dieser Kontroverse. Ein Begriff, der oft als nicht inklusiv bezeichnet wird, ist Craftsman (dt. Handwerker).
Ich habe lange über diese Frage nachgedacht und mit vielen Menschen mit unterschiedlichen Meinungen gesprochen, und ich bin zu dem Schluss gekommen, dass es keinen besseren Begriff gibt, der im Zusammenhang mit diesem Buch verwendet werden kann
Es wurden Alternativen zu Craftsman in Betracht gezogen, darunter Craftsperson, Craftsfolk und Crafter. Aber keiner dieser Begriffe hat das historische Gewicht des Craftsman. Und diese historische Bedeutung ist wichtig für die Botschaft dieses Buchs.
Mit dem Begriff Craftsman wird eine Person assoziiert, die in einer bestimmten Tätigkeit sehr geschickt und versiert ist – jemand, der sich mit seinen Werkzeugen und seinem Handwerk auskennt, der stolz auf seine Arbeit ist und von dem man erwarten kann, dass er seinen Beruf mit Würde und Professionalität ausübt.
Es mag sein, dass einige von Ihnen mit meiner Entscheidung nicht einverstanden sind. Ich verstehe, warum das so sein könnte. Ich hoffe nur, dass Sie dies nicht als Versuch interpretieren, in irgendeiner Weise exklusiv zu sein – denn das ist keineswegs meine Absicht.
Auf dem einzig wahren Weg
Wenn Sie Clean Craftsmanship: Best Practices, Standards und Ethik für die Softwareentwicklung lesen, bekommen Sie vielleicht das Gefühl, dass dies der einzig wahre Weg zur Craftsmanship ist. Für mich mag er das sein, aber nicht unbedingt für Sie. Ich biete Ihnen dieses Buch als ein Beispiel für meinen Weg an. Sie werden natürlich Ihren eigenen Weg finden müssen.
Werden wir irgendwann den einen einzigen wahren Weg brauchen? Ich weiß es nicht. Aber vielleicht. Wie Sie auf diesen Seiten lesen werden, wächst der Druck für eine strenge Definition des Softwareberufs. Je nach der Kritikalität der zu erstellenden Software können wir vielleicht mit mehreren verschiedenen Wegen auskommen. Aber wie Sie im Folgenden lesen werden, ist es vielleicht gar nicht so einfach, kritische von unkritischer Software zu unterscheiden.
Über eines bin ich mir aber sicher. Die Zeiten der »Richter«[1] sind vorbei. Es reicht nicht mehr aus, dass jeder Programmierer das tut, was er in seinen Augen für richtig hält. Es werden Praktiken, Standards und Ethik kommen. Die Entscheidung, vor der wir heute stehen, ist, ob wir Programmierer sie für uns selbst definieren oder ob wir sie uns von denen aufzwingen lassen wollen, die uns nicht kennen.
Einführung in das Buch
Dieses Buch ist für Programmierer und für Manager von Programmierern geschrieben. Aber in einem anderen Sinne ist dieses Buch für die gesamte menschliche Gesellschaft geschrieben. Denn wir, die Programmierer, haben uns ungewollt am Dreh- und Angelpunkt dieser Gesellschaft wiedergefunden.
Für Sie selbst
Wenn Sie ein Programmierer mit mehreren Jahren Erfahrung sind, kennen Sie wahrscheinlich die Genugtuung, wenn Sie ein System einrichten und zum Laufen bringen. Es erfüllt Sie mit einem gewissen Stolz, an einer solchen Leistung beteiligt gewesen zu sein. Sie sind stolz darauf, dass Sie das System auf den Weg gebracht haben.
Aber sind Sie auch stolz darauf, wie Sie das System auf den Weg gebracht haben? Ist es der Stolz darauf, fertig geworden zu sein? Oder ist es der Stolz auf Ihre Arbeit? Sind Sie stolz darauf, dass das System deployt wurde? Oder sind Sie stolz darauf, wie Sie das System gebaut haben?
Wenn Sie nach einem anstrengenden Tag, an dem Sie Code geschrieben haben, nach Hause gehen, schauen Sie sich dann im Spiegel an und sagen: »Heute habe ich gute Arbeit geleistet«? Oder müssen Sie erst duschen gehen?
Zu viele von uns fühlen sich am Ende des Tags schmutzig. Zu viele von uns fühlen sich dazu gezwungen, minderwertige Arbeit zu leisten. Zu viele von uns haben das Gefühl, dass niedrige Qualität erwartet wird und für hohe Geschwindigkeit notwendig ist. Zu viele von uns denken, dass Produktivität und Qualität in einem umgekehrten Verhältnis zueinanderstehen.
In diesem Buch versuche ich, diese Denkweise zu durchbrechen. Dies ist ein Buch darüber, gut zu arbeiten. Es ist ein Buch darüber, seinen Job gut zu machen. Es ist ein Buch, das die Praktiken beschreibt, die jeder Programmierer kennen sollte, um schnell zu arbeiten, produktiv zu sein und stolz auf das, was er jeden Tag schreibt.
Für die Gesellschaft
Das 21. Jahrhundert markiert das erste Mal in der Geschichte der Menschheit, dass unsere Gesellschaft für ihr Überleben von einer Technologie abhängig geworden ist, die praktisch keinen Anschein von Disziplin oder Kontrolle mehr hat. Software ist in jede Facette des modernen Lebens eingedrungen, vom morgendlichen Kaffeekochen bis zur abendlichen Unterhaltung, vom Wäschewaschen bis zum Autofahren, vom Verbinden über ein weltumspannendes Netz bis zur Aufspaltung in gesellschaftliche und politische Lager. Es gibt buchstäblich keinen Aspekt des Lebens in der modernen Welt, der nicht von Software beherrscht wird. Und doch sind diejenigen von uns, die diese Software entwickeln, kaum mehr als ein zusammengewürfelter Haufen von Tüftlern, die nur wenig Ahnung davon haben, was sie da tun.
Hätten wir Programmierer besser verstanden, was wir tun, wären dann die Ergebnisse der Caucus-Wahl in Iowa 2020 zum versprochenen Zeitpunkt fertig gewesen? Wären bei den beiden Abstürzen der 737 Max 346 Menschen ums Leben gekommen? Hätte die Knight Capital Group in 45 Minuten 460 Millionen Dollar verloren? Hätten 89 Menschen bei den Unfällen mit unbeabsichtigter Beschleunigung bei Toyota ihr Leben verloren?
Alle fünf Jahre verdoppelt sich die Zahl der Programmierer auf der Welt. Diesen Programmierern wird nur sehr wenig über ihr Handwerk beigebracht. Man zeigt ihnen die Werkzeuge, gibt ihnen ein paar Spielzeugprojekte, die sie entwickeln sollen, und wirft sie dann in eine exponentiell wachsende Belegschaft, um die exponentiell wachsende Nachfrage nach immer mehr Software zu befriedigen. Jeden Tag dringt das Kartenhaus, das wir Software nennen, tiefer und tiefer in unsere Infrastruktur, unsere Institutionen, unsere Regierungen und unser Leben ein. Und mit jedem Tag wächst das Risiko einer Katastrophe.
Von welcher Katastrophe spreche ich? Es ist weder der Zusammenbruch unserer Zivilisation noch der plötzliche Zerfall aller Softwaresysteme auf einmal. Das Kartenhaus, das einstürzen wird, besteht nicht aus den Softwaresystemen selbst. Vielmehr ist es das fragile Fundament des öffentlichen Vertrauens, das in Gefahr ist.
Zu viele weitere Vorfälle wie die 737 Max, Toyotas unbeabsichtigte Beschleunigung, Volkswagens Dieselaffäre oder der Iowa Caucus – zu viele weitere Fälle von aufsehenerregenden Softwarefehlern oder Fehlverhalten – und der Mangel an Praktiken, Ethik und Standards wird in den Fokus einer misstrauischen und wütenden Öffentlichkeit geraten. Und dann werden Vorschriften folgen: Vorschriften, die niemand von uns wollen sollte; Vorschriften, die unsere Fähigkeit, das Handwerk der Softwareentwicklung frei zu erkunden und zu erweitern, lähmen werden; Vorschriften, die das Wachstum unserer Technologie und Wirtschaft stark einschränken werden.
Es ist nicht das Ziel dieses Buchs, die überstürzte Einführung von immer mehr Software zu stoppen. Es ist auch nicht das Ziel, das Tempo der Softwareproduktion zu verlangsamen. Solche Ziele sind nicht der Mühe wert. Unsere Gesellschaft braucht Software, und sie wird sie bekommen, egal wie. Der Versuch, diesen Bedarf zu drosseln, wird die sich abzeichnende Katastrophe in Bezug auf das öffentliche Vertrauen nicht aufhalten.
Vielmehr ist es das Ziel dieses Buchs, Softwareentwicklern und ihren Managern die Notwendigkeit von Praktiken aufzuzeigen und diesen Entwicklern und Managern die Praktiken, Standards und Ethik beizubringen, die am effektivsten sind, um ihre Fähigkeit zu maximieren, robuste, fehlertolerante und effektive Software zu produzieren. Nur wenn wir Programmierer unsere Arbeitsweise ändern, indem wir unsere Praktiken, Ethik und Standards verbessern, kann das Kartenhaus gestützt und vor dem Zusammenbruch bewahrt werden.
Der Aufbau des Buchs
Dieses Buch ist in drei Teile gegliedert, die drei Ebenen beschreiben: Praktiken, Standards und Ethik.
Praktiken sind die unterste Ebene. Dieser Teil des Buchs ist pragmatisch, technisch und reglementierend. Programmierer aller Couleur werden vom Lesen und Verstehen dieses Teils profitieren. Auf den Seiten dieses Teils finden sich mehrere Verweise auf Videos in englischer Sprache. Diese Videos zeigen den Rhythmus der testgetriebenen Entwicklung und der Refactoring-Disziplinen in Echtzeit. Die zugehörigen Texte im Buch versuchen ebenfalls, diesen Rhythmus einzufangen, aber nichts eignet sich so gut für diesen Zweck wie Videos.
Standards sind die mittlere Ebene. In diesem Teil werden die Erwartungen, die die Welt an unseren Beruf stellt, umrissen. Er eignet sich besonders für Manager, damit sie wissen, was sie von professionellen Programmierern erwarten können.
Ethik ist die oberste Ebene. In diesem Abschnitt wird der ethische Kontext vom Beruf des Programmierers beschrieben. Dies geschieht in Form eines Eids beziehungsweise einer Reihe von Versprechen. Er ist mit vielen historischen und philosophischen Erörterungen gespickt und sollte von Programmierern und Managern gleichermaßen gelesen werden.
Ein Hinweis für Manager
Diese Seiten enthalten viele Informationen, die für Sie von Nutzen sein können. Sie enthalten auch eine Menge technischer Informationen, die sie wahrscheinlich nicht brauchen. Ich empfehle Ihnen, die Einleitung jedes Kapitels zu lesen und die Lektüre abzubrechen, wenn der Inhalt Ihnen zu technisch wird. Gehen Sie dann zum nächsten Kapitel, und beginnen Sie von vorn.
Lesen Sie unbedingt Teil II, »Die Standards«, und Teil III, »Die Ethik«. Lesen Sie auch unbedingt die Einführungen zu jeder der fünf Praktiken.
Videos zum Buch
Geben Sie den untenstehenden Code unter
https://mitp.code-load.de/
in das Textfeld ein und klicken Sie auf Einlösen, um die Videos zum Buch herunterzuladen (nur in englischer Sprache verfügbar):
c6xea22a7x
[1] eine Anspielung auf das alttestamentarische Buch der Richter
Danksagungen
Vielen Dank an meine unerschrockenen Rezensenten: Damon Poole, Eric Crichlow, Heather Kanser, Tim Ottinger, Jeff Langr, und Stacia Viscardi. Sie haben mich vor so manchem Stolperstein bewahrt.
Mein Dank gilt auch Julie Phifer, Chris Zahn, Menka Mehta, Carol Lallier und all jenen bei Pearson, die so unermüdlich daran gearbeitet haben, dass diese Bücher so gut gelungen sind.
Wie immer möchte ich mich bei meiner kreativen und talentierten Illustratorin Jennifer Kohnke bedanken. Ihre Bilder bringen mich immer zum Lächeln.
Und natürlich danke ich meiner lieben Frau und meiner wunderbaren Familie.
Über den Autor
Robert C. Martin (Uncle Bob) schrieb seine erste Codezeile im Alter von 12 Jahren im Jahr 1964. Seit 1970 ist er als Programmierer tätig. Er ist Mitbegründer von cleancoders.com, einem Anbieter von Online-Videotrainings für Softwareentwickler, sowie Gründer von Uncle Bob Consulting LLC, einem Anbieter von Softwareberatung, Schulungen und Skill-Entwicklungsdienstleistungen für große Unternehmen weltweit. Außerdem hat er als Master Craftsman bei 8th Light, Inc., einem Softwareberatungsunternehmen in Chicago, gearbeitet.
Martin hat Dutzende von Artikeln in verschiedenen Fachzeitschriften veröffentlicht und tritt regelmäßig als Redner auf internationalen Konferenzen und Fachmessen auf. Er ist auch der Schöpfer einer hochgelobten Serie von Lehrvideos auf cleancoders.com.
Martin hat viele Bücher verfasst und herausgegeben, darunter die folgenden:
Clean Agile: Die Essenz der agilen Softwareentwicklung (mitp, 2020)
Clean Architecture: Das Praxis-Handbuch für professionelles Softwaredesign (mitp, 2018)
Clean Coder: Verhaltensregeln für professionelle Programmierer (mitp, 2014)
Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code (mitp, 2009)
UML for Java Programmers (Pearson, 2003)
Agile Software Development (Prentice Hall International, 2013)
Extreme Programming in Practice (Addison-Wesley, 2001)
More C++ Gems (Cambridge University Press, 2000)
Pattern Languages of Program Design 3 (Addison-Wesley, 1997)
Designing Object Oriented C++ Aplications Using the Booch Method (Prentice Hall, 1995)
Als führende Persönlichkeit in der Softwareentwicklungsbranche war Martin drei Jahre lang Chefredakteur des C++ Report und erster Vorsitzender der Agile Alliance.
Kapitel 1: Craftsmanship
Der Traum vom Fliegen ist wahrscheinlich so alt wie die Menschheit. Der altgriechische Mythos, der den Flug von Dädalus und Ikarus beschreibt, stammt etwa aus der Zeit um 1550 vor Christus. In den darauffolgenden Jahrtausenden haben sich viele mutige, wenn auch törichte Seelen unbeholfene Vorrichtungen an den Körper geschnallt und sind von Klippen und Türmen ins Verderben gesprungen, um diesen Traum zu verwirklichen.
Vor etwa fünfhundert Jahren begannen die Dinge sich zu ändern, als Leonardo da Vinci Skizzen von Maschinen anfertigte, die zwar nicht wirklich flugfähig waren, aber doch einige vernünftige Ansätze enthielten. Es war da Vinci, der erkannte, dass Fliegen möglich ist, weil der Luftwiderstand in beide Richtungen wirkt. Der Widerstand, der durch das Herunterdrücken von Luft entsteht, erzeugt in gleicher Weise Auftrieb. Dies ist der Mechanismus, mit dem alle modernen Flugzeuge fliegen.
Da Vincis Ideen gingen bis zur Mitte des 18. Jahrhunderts verloren. Doch dann begann eine enthusiastische Erforschung der Möglichkeiten des Fliegens. Das 18. und 19. Jahrhundert war eine Zeit intensiver aeronautischer Forschungen und Experimente. Unmotorisierte Prototypen wurden gebaut, ausprobiert, verworfen und verbessert. Die Wissenschaft der Aeronautik nahm Gestalt an. Die Kräfte des Auftriebs, des Widerstands, des Schubs und der Schwerkraft wurden erkannt und verstanden. Einige mutige Seelen wagten den Versuch.
Und einige stürzten ab und starben.
In den letzten Jahren des 18. Jahrhunderts und im darauffolgenden halben Jahrhundert baute Sir George Cayley, der Vater der modernen Aerodynamik, Versuchsanlagen, Prototypen und Modelle in Originalgröße, die im ersten bemannten Flug eines Segelflugzeugs gipfelten.
Und immer noch stürzten einige ab und starben.
Dann kam das Zeitalter des Dampfs und die Möglichkeit des bemannten Motorflugs. Dutzende von Prototypen wurden gebaut und Experimente durchgeführt. Sowohl Wissenschaftler als auch Enthusiasten schlossen sich der Schar von Menschen an, die das Potenzial des Fliegens erforschten. Im Jahr 1890 flog Clément Ader mit einer zweimotorigen Dampfmaschine 50 Meter weit.
Und immer noch stürzten einige ab und starben.
Aber der Verbrennungsmotor war der Wendepunkt. Aller Wahrscheinlichkeit nach fand der erste motorisierte und kontrollierte bemannte Flug 1901 durch Gustave Whitehead statt. Aber es waren die Gebrüder Wright, die am 17. Dezember 1903 in den Kill Devil Hills in North Carolina den ersten wirklich längeren angetriebenen und kontrollierten bemannten Flug mit einer Maschine durchführen, die schwerer war als Luft.
Und immer noch stürzten einige ab und starben.
Doch die Welt veränderte sich über Nacht. Schon elf Jahre später, im Jahr 1914, lieferten sich Doppeldecker in der Luft Kämpfe über Europa.
Und auch wenn viele Piloten unter feindlichem Beschuss abstürzten und starben, stürzten ähnlich viele ab und starben, während sie nur das Fliegen lernten. Die Prinzipien des Fliegens mochten gemeistert worden sein, aber die Technik des Fliegens wurde kaum verstanden.
Nur zwei Jahrzehnte später richteten die wirklich schrecklichen Jagdflugzeuge und Bomber des Zweiten Weltkriegs über Frankreich und Deutschland verheerende Schäden an. Sie flogen in extremen Höhen. Sie waren mit Kanonen bestückt. Und sie hatten eine verheerende Zerstörungskraft.
Während des Kriegs verlor Amerika 65.000 Flugzeuge. Aber nur 23.000 davon im Gefecht. Die Piloten flogen und starben im Kampf. Noch häufiger aber flogen und starben sie, wenn niemand schoss. Denn wir wussten immer noch nicht, wie wir fliegen sollten.
Ein weiteres Jahrzehnt kam und brachte düsengetriebene Flugzeuge, das Durchbrechen der Schallmauer und die explosionsartige Ausbreitung der kommerziellen Fluggesellschaften und des zivilen Luftverkehrs. Es war der Beginn des Düsenzeitalters, in dem wohlhabende Menschen (der sogenannte Jetset) innerhalb weniger Stunden von Stadt zu Stadt und von Land zu Land fliegen konnten.
Und die Düsenflugzeuge rissen sich selbst in Stücke und stürzten in erschreckender Zahl vom Himmel. Es gab so vieles, was wir immer noch nicht über den Bau und das Fliegen von Flugzeugen wussten.
Das bringt uns in die 1950er-Jahre. Bis zum Ende des Jahrzehnts würden Boeing-707-Flugzeuge Passagiere von hier nach dort um die ganze Welt fliegen. Zwei weitere Jahrzehnte später sollte der erste Großraum-Jumbojet, die 747, auf den Markt kommen.
Die Luftfahrt und der Luftverkehr sollten sich zum sichersten und effizientesten Reisemittel der Weltgeschichte entwickelten. Es hat lange gedauert und viele Menschenleben gekostet, aber wir hatten endlich gelernt, wie man Flugzeuge sicher baut und fliegt[1].
Chesley Sullenberger wurde 1951 in Denison, Texas, geboren. Er war ein Kind des Jet-Zeitalters. Im Alter von sechzehn Jahren lernte er das Fliegen und flog schließlich F4 Phantoms für die Luftwaffe. Im Jahr 1980 wurde er Pilot bei US Airways.
Am 15. Januar 2009, kurz nach dem Abflug von LaGuardia, stieß sein Airbus A320 mit 155 Passagieren an Bord mit einem Gänseschwarm zusammen und verlor beide Triebwerke. Kapitän Sullenberger, der auf mehr als zwanzigtausend Stunden Flugerfahrung zurückblicken konnte, steuerte sein beschädigtes Flugzeug zu einer »Wasserlandung« im Hudson River und rettete durch sein unheimliches Geschick jede einzelne der 155 Seelen an Bord. Kapitän Sullenberger beherrschte sein Handwerk hervorragend. Kapitän Sullenberger war ein Craftsman (dt. Handwerker).
Der Traum von schnellen, zuverlässigen Berechnungen und Datenmanagement ist wahrscheinlich so alt wie die Menschheit. Das Zählen mit Fingern, Stöcken und Perlen reicht Tausende von Jahren zurück. Schon vor über viertausend Jahren bauten und benutzten die Menschen Abakusse. Mechanische Geräte wurden vor etwa zweitausend Jahren zur Vorhersage der Bewegungen von Sternen und Planeten verwendet. Rechenschieber wurden vor etwa vierhundert Jahren erfunden.
Im frühen 19. Jahrhundert begann Charles Babbage mit dem Bau von kurbelbetriebenen Rechenmaschinen. Es handelte sich dabei um echte digitale Computer mit Speicher und arithmetischer Verarbeitung. Aber sie waren mit den damaligen Möglichkeiten der Metallverarbeitung schwer zu bauen, und obwohl er einige Prototypen baute, waren sie kein kommerzieller Erfolg.
Mitte des 18. Jahrhunderts versuchte Babbage, eine viel leistungsfähigere Maschine zu bauen. Sie sollte mit Dampf betrieben werden und in der Lage sein, echte Programme auszuführen. Er nannte sie die Analysemaschine (engl. Analytical Engine).
Lord Byrons Tochter Ada, die Gräfin von Lovelace, übersetzte die Aufzeichnungen eines Vortrags von Babbage und entdeckte eine Tatsache, die zu dieser Zeit offenbar noch niemandem aufgefallen war: Die Zahlen in einem Computer müssen überhaupt keine Zahlen darstellen, sondern können Dinge in der realen Welt repräsentieren. Wegen dieser Erkenntnis wird sie oft als die weltweit erste echte Programmiererin bezeichnet.
Die Probleme der präzisen Verarbeitung von Metall frustrierten Babbage weiterhin, und schließlich scheiterte sein Projekt. Für den Rest des 19. und frühen 20. Jahrhunderts wurden keine weiteren Fortschritte bei digitalen Computern erzielt. Aber in dieser Zeit erlebten die mechanischen Analogrechner ihre Blütezeit.
1936 zeigte Alan Turing, dass es keine allgemeine Möglichkeit gibt, zu beweisen, dass eine gegebene diophantische[2] Gleichung Lösungen hat. Er konstruierte diesen Beweis, indem er sich einen einfachen, wenn auch unendlichen digitalen Computer vorstellte und dann bewies, dass es Zahlen gibt, die dieser Computer nicht berechnen konnte. Als Folge dieses Beweises erfand er endliche Zustandsautomaten (engl. finite state machine), Maschinensprache, symbolische Sprache, Makros und primitive Unterroutinen. Er erfand, was wir heute als Software bezeichnen würden.
Fast genau zur gleichen Zeit konstruierte Alonzo Church einen völlig anderen Beweis für dasselbe Problem und entwickelte in der Folge das Lambda-Kalkül – das Kernkonzept der funktionalen Programmierung.
1941 baute Konrad Zuse den ersten elektromechanisch programmierbaren Digitalcomputer, die Z3. Er bestand aus mehr als 2.000 Relais und arbeitete mit einer Taktrate von 5 bis 10 Hz. Die Maschine verwendete binäre Arithmetik, die in Wörtern von je 22 Bit organisiert war.
Während des Zweiten Weltkriegs wurde Turing rekrutiert, um den »Boffins«[3] in Bletchley Park bei der Entschlüsselung der deutschen Enigma-Codes zu helfen. Bei der Enigma-Maschine handelte es sich um einen einfachen digitalen Computer, der die Zeichen von Textnachrichten, die üblicherweise über Funktelegrafen übertragen wurden, nach dem Zufallsprinzip verschlüsselte. Turing half bei der Konstruktion einer elektromechanischen digitalen Suchmaschine, um die Schlüssel zu diesen Codes zu finden.
Nach dem Krieg war Turing maßgeblich am Bau und der Programmierung eines der weltweit ersten Computer mit elektronischen Vakuumröhren beteiligt – der Automatic Computing Engine (ACE). Der ursprüngliche Prototyp verwendete 1.000 Vakuumröhren und verarbeitete binäre Zahlen mit einer Geschwindigkeit von einer Million Bits pro Sekunde.
Nachdem er einige Programme für diese Maschine geschrieben und ihre Fähigkeiten erforscht hatte, hielt Turing 1947 einen Vortrag, in dem er die folgenden, vorausschauenden Aussagen machte:
Wir werden eine große Anzahl fähiger Mathematiker brauchen, um [die Probleme] in eine rechenbare Form zu bringen.
Eine unserer Schwierigkeiten wird die Aufrechterhaltung einer geeigneten Disziplin sein, damit wir nicht den Überblick über das verlieren, was wir tun.[4]
Und die Welt veränderte sich über Nacht.
Innerhalb weniger Jahre wurde der Kernspeicher entwickelt. Die Möglichkeit, innerhalb von Mikrosekunden auf Hunderttausende, wenn nicht Millionen von Speicherbits zugreifen zu können, wurde Realität. Gleichzeitig machte die Massenproduktion von Vakuumröhren Computer billiger und zuverlässiger. Die Serienproduktion wurde teilweise zur Realität. Bis 1960 hatte IBM 140 Computer des Modells 70x verkauft. Das waren riesige Vakuumröhrenmaschinen im Wert von mehreren Millionen Dollar.
Turing hatte seine Maschine binär programmiert, aber jeder verstand, dass dies unpraktisch war. 1949 hatte Grace Hopper das Wort Compiler geprägt und 1952 den ersten Compiler entwickelt: A-0. Ende 1953 legte John Bachus die erste FORTRAN-Spezifikation vor. ALGOL und LISP folgten 1958.
Der erste funktionierende Transistor wurde 1947 von John Bardeen, Walter Brattain und William Shockley entwickelt. Sie hielten 1953 Einzug in Computern. Das Ersetzen von Vakuumröhren durch Transistoren hat alles von Grund auf verändert. Computer wurden kleiner, schneller, billiger und viel zuverlässiger.
Bis 1965 hatte IBM 10.000 Computer des Modells 1401 hergestellt. Sie wurden für 2.500 Dollar pro Monat vermietet. Das war für mittelgroße Unternehmen durchaus erschwinglich. Diese Unternehmen brauchten Programmierer, und so stieg die Nachfrage nach Programmierern rapide an.
Wer sollte all diese Maschinen programmieren? Es gab keine Universitätskurse. Niemand ging 1965 zur Schule, um Programmieren zu lernen. Diese Programmierer kamen aus der Wirtschaft. Es waren erwachsene Menschen, die schon einige Zeit in ihren Unternehmen gearbeitet hatten. Sie waren in ihren 30ern, 40ern und 50ern.
1966 produzierte IBM jeden Monat 1.000 Computer des Modells 360. Die Unternehmen bekamen nicht genug. Diese Maschinen hatten einen Speicher von 64 kB und mehr. Sie konnten Hunderttausende von Befehlen pro Sekunde ausführen.
Im selben Jahr erfanden Ole-Johan Dahl und Kristen Nygard auf einer Univac 1107 im Norwegischen Computerzentrum Simula 67, eine Erweiterung von ALGOL. Es war die erste objektorientierte Sprache.
Der Vortrag von Alan Turing lag erst zwei Jahrzehnte zurück!
Zwei Jahre später, im März 1968, schrieb Edsger Dijkstra seinen berühmten Brief an die Communications of the ACM (CACM). Der Herausgeber gab diesem Brief den Titel »Go To Statement Considered Harmful«[5]. Die strukturierte Programmierung war geboren.
1972 befanden sich Ken Thompson und Dennis Ritchie in den Bell Labs in New Jersey zwischen verschiedenen Projekten. Sie erbaten sich Zeit auf einer PDP 7 eines anderen Projektteams und erfanden UNIX und C.
Jetzt nahm das Tempo fast wahnwitzige Ausmaße an. Ich werde Ihnen ein paar wichtige Ereignisse nennen. Fragen Sie sich bei jedem dieser Ereignisse: Wie viele Computer gibt es auf der Welt? Wie viele Programmierer gibt es auf der Welt? Und woher kommen diese Programmierer?
1970 – Die Digital Equipment Corporation hat seit 1965 50.000 PDP-8-Computer produziert.1970 – Winston Royce schreibt das »Wasserfall«-Papier, »Managing the Development of Large Software Systems«1971 – Intel bringt den 4004 Single-Chip-Mikrocomputer auf den Markt.1974 – Intel bringt den Single-Chip-Mikrocomputer 8080 auf den Markt.1977 – Apple bringt den Apple II heraus.1979 – Motorola bringt den 68000 heraus, einen 16-Bit-Single-Chip-Mikrocomputer.1980 – Bjarne Stroustrup erfindet »C mit Klassen« (ein Präprozessor, der C wie Simula aussehen lässt).1980 – Alan Kay erfindet Smalltalk.1981 – IBM bringt den IBM PC heraus.1983 – Apple bringt den 128K Macintosh heraus.1983 – Stroustrup benennt »C mit Klassen« in C++ um.1985 – Das US-Verteidigungsministerium führt das Wasserfall-Modell als offiziellen Softwareentwicklungsprozess ein (DOD-STD-2167A).1986 – Stroustrup veröffentlicht »The C++ Programming Language« (Addison-Wesley).1991 – Grady Booch veröffentlicht »Object-Oriented Design with Applications« (Benjamin/Cummings).1991 – James Gosling erfindet Java (damals noch Oak genannt).1991 – Guido van Rossum veröffentlicht Python.1995 – »Design Patterns: Elements of Reusable Object-Oriented Software« (Addison-Wesley) wurde von Erich Gamma, Richard Helm, John Vlissides und Ralph Johnson geschrieben.1995 – Yukihiro Matsumoto veröffentlicht Ruby.1995 – Brendan Eich entwickelt JavaScript.1996 – Sun Microsystems veröffentlicht Java.1999 – Microsoft erfindet C#/.NET (damals Cool genannt).2000 – Y2K! Der Millennium-Bug.2001 – Das »Agile Manifest« wurde geschrieben.
Zwischen 1970 und 2000 stiegen die Taktraten von Computern um drei Zehnerpotenzen. Die Datendichte stieg um vier Zehnerpotenzen. Die Kapazität von Festplattenspeicher stieg um sechs oder sieben Zehnerpotenzen. Die Kapazität von RAM stieg um sechs oder sieben Zehnerpotenzen. Die Kosten sanken von Dollar pro Bit auf Dollar pro Gigabit. Die Veränderungen in der Hardware sind schwer zu veranschaulichen, aber wenn man alle genannten Größenordnungen zusammenzählt, kommt man auf eine Steigerung der Leistungsfähigkeit um etwa dreißig Zehnerpotenzen.
Und das alles in etwas mehr als fünfzig Jahren seit Alan Turings Vortrag.
Wie viele Programmierer gibt es heute? Wie viele Codezeilen wurden geschrieben? Wie gut ist all dieser Code?
Vergleichen Sie die Zeitleiste mit der Luftfahrt. Erkennen Sie Ähnlichkeiten? Sehen Sie die kontinuierliche Zunahme von Theorie, die Ungeduld und das Scheitern der Enthusiasten und die allmähliche Zunahme an Kompetenz? Die Jahrzehnte, in denen wir nicht wussten, was wir taten?
Und jetzt, wo unsere Gesellschaft in ihrer Existenz von unseren Fähigkeiten abhängt, haben wir die Sullenberger, die unsere Gesellschaft braucht? Haben wir die Programmierer herangezogen, die ihr Handwerk so gut verstehen, wie die Piloten von heute das ihre verstehen? Haben wir die Craftsmen, die wir mit Sicherheit brauchen werden?
Handwerkliches Geschick bedeutet, dass man weiß, wie man etwas gut macht, und es ist das Ergebnis einer guten Ausbildung und viel Erfahrung. Bis vor Kurzem gab es in der Softwarebranche viel zu wenig von beidem. Programmierer blieben nicht lange Programmierer, weil sie das Programmieren als Sprungbrett ins Management betrachteten. Das bedeutete, dass es zu wenige von ihnen gab, die genug Erfahrung sammelten, um anderen das Handwerk beizubringen. Erschwerend kommt hinzu, dass sich die Zahl der neuen Programmierer, die in die Branche eintreten, etwa alle fünf Jahre verdoppelt, sodass der Anteil an erfahrenen Programmierern viel zu niedrig ist.
Das Ergebnis ist, dass die meisten Programmierer nie die Disziplinen, Standards und Ethik lernen, die ihr Handwerk ausmachen könnten. Während ihrer relativ kurzen Karriere als Programmierer bleiben sie ungelernte Anfänger. Und das bedeutet natürlich, dass ein Großteil des von diesen unerfahrenen Programmierern produzierten Codes minderwertig, schlecht strukturiert, unsicher, fehlerhaft und ein ziemliches Chaos ist.
In diesem Buch beschreibe ich die Standards, Disziplinen und ethischen Grundsätze, die meiner Meinung nach jeder Programmierer und jede Programmiererin kennen und befolgen sollte, um sich nach und nach das Wissen und die Fähigkeiten anzueignen, die sein oder ihr Handwerk wirklich erfordert.
[1] Wir ignorieren hier die 737 Max.
[2] Gleichungen von ganzen Zahlen (engl. integers).
[3] Boffin ist ein britischer Slang-Ausdruck für einen Wissenschaftler, Ingenieur oder eine andere Person, die in der technischen oder wissenschaftlichen Forschung und Entwicklung tätig ist (Anmerkung des Übersetzers).
[4] A.M. Turing’s ACE Report of 1946 and Other Papers – Vol. 10, »In the Charles Babbage Institute Reprint Series for the History of Computing«, (B.E. Carpenter, B.W. Doran, Hrsg.). The MIT Press, 1986.
[5] Edsger W. Dijkstra, »Go To Statement Considered Harmful«, Communications of the ACM 11, no. 3 (1968).
Teil I: Die Praktiken
In diesem Teil:
Kapitel 2
Testgetriebene Entwicklung
Kapitel 3
Fortgeschrittenes TDD
Kapitel 4
Testdesign
Kapitel 5
Refactoring
Kapitel 6
Einfaches Design
Kapitel 7
Kollaborative Programmierung
Kapitel 8
Akzeptanztests
Was ist eine Praktik? Eine Praktik besteht aus einer Sammlung von Regeln, die sich aus zwei Teilen zusammensetzt: dem wesentlichen und dem willkürlichen Teil. Der wesentliche Teil ist das, was der Praktik ihre Macht verleiht; er ist der Grund dafür, dass die Praktik überhaupt existiert. Der willkürliche Teil gibt der Praktik ihre Form und Substanz. Ohne den willkürlichen Teil kann eine Praktik nicht existieren.
Schauen wir uns ein Beispiel an: Chirurgen waschen sich vor einer Operation die Hände. Wenn sie dabei zuschauen würden, würden sie sehen, dass das Händewaschen einem ganz bestimmten Ablauf folgt. Der Chirurg wäscht sich nicht einfach nur die Hände unter fließendem Wasser ab, wie Sie und ich es tun. Vielmehr folgt er einem ritualisierten Ablauf, einer Praktik des Händewaschens. Eine solche Routine, wie ich sie gesehen habe, sieht zum Beispiel folgendermaßen aus:
Verwende die richtige Seife.
Verwende die geeignete Bürste.
Benutze für jeden Finger
zehn Striche auf der Oberseite.
zehn Striche über die linke Seite.
zehn Striche über die Unterseite.
zehn Striche über die rechte Seite.
zehn Striche über den Nagel.
Und so weiter.
Der wesentliche Teil der Praktik sollte offensichtlich sein. Die Hände des Chirurgen müssen sehr sauber sein. Aber haben Sie auch den willkürlichen Teil bemerkt? Warum zehn Striche anstelle von acht oder zwölf? Warum wird der Finger in fünf Abschnitte unterteilt? Warum nicht drei oder sieben Abschnitte?
Das ist alles willkürlich. Es gibt keinen wirklichen Grund für diese Zahlen, außer dass man sie für ausreichend hält.
In diesem Buch untersuchen wir fünf Praktiken der Software Craftsmanship (dt. Softwarehandwerk). Einige dieser Praktiken sind bereits fünf Jahrzehnte alt. Andere gibt es erst seit zwei Jahrzehnten. Aber alle haben in dieser Zeit ihre Nützlichkeit bewiesen. Ohne sie wäre es schlicht undenkbar, Softwareentwicklung als Handwerk zu bezeichnen.
Jede dieser Praktiken hat ihre eigenen wesentlichen und willkürlichen Elemente. Während des Lesens werden Sie vielleicht feststellen, dass Ihr Gefühl sich gegen eine oder mehrere der Praktiken sträubt. Sollte es Ihnen so gehen, dann fragen Sie sich, ob sich der Einwand auf die wesentlichen oder nur auf die willkürlichen Elemente bezieht. Lassen Sie sich nicht von den willkürlichen Elementen in die Irre führen. Konzentrieren Sie sich auf die wesentlichen Elemente. Wenn Sie das Wesentliche einer jeden Praktik verinnerlicht haben, wird die willkürliche Form an Bedeutung verlieren.
Zum Beispiel veröffentlichte Ignaz Semmelweis 1861 seine Erkenntnisse über die Anwendung der Praktik des Händewaschens für Ärzte. Die Ergebnisse seiner Forschung waren verblüffend. Er konnte aufzeigen, dass die Sterblichkeitsrate von schwangeren Frauen von einem Zehntel auf praktisch null sank, wenn sich die Ärzte vor der Untersuchung gründlich die Hände in Chlorbleiche wuschen.
Doch die Ärzte der damaligen Zeit trennten bei der Überprüfung von Semmelweis’ vorgeschlagener Praktik nicht zwischen dem Wesentlichen und dem Willkürlichen. Die Chlorbleiche war der willkürliche Teil. Das Waschen war das Wesentliche. Die Unbequemlichkeit des Waschens mit Bleichmittel stieß sie ab, und so lehnten sie den Beweis für die wesentliche Natur des Händewaschens ab.
Es dauerte viele Jahrzehnte, bis Ärzte anfingen, sich tatsächlich die Hände zu waschen.
Extreme Programming
1970 veröffentlichte Winston Royce eine Arbeit, die für eine weite Verbreitung des Wasserfallmodells in der Softwareentwicklung sorgte. Es dauerte fast 30 Jahre, bis dieser Fehler wieder rückgängig gemacht wurde.
Ab 1995 begannen Softwareexperten andere, stärker inkrementelle Ansätze in Betracht zu ziehen. Prozesse wie Scrum, Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM) und die Crystal-Methoden wurden vorgestellt. Doch in der Branche änderte sich insgesamt wenig.
Dann, 1999, veröffentlichte Kent Beck das Buch »Extreme Programming Explained« (Addison-Wesley). Extreme Programming (XP) baute auf den Ideen dieser früheren Prozesse auf, fügte aber mit Engineering-Praktiken etwas Neues hinzu.
Zwischen 1999 und 2001 wuchs die Begeisterung für XP exponentiell. Dieser Enthusiasmus war es, der die agile Revolution auslöste und vorantrieb. Bis zum heutigen Tag ist XP die am besten definierte und zugleich vollständigste aller agilen Methoden. Die ingenieurwissenschaftlichen Praktiken, die den Kern der Methode bilden, stehen im Mittelpunkt dieses Abschnitts.
Der Kreislauf des Lebens
In Abbildung I.1 sehen sie den Kreislauf des Lebens von Ron Jeffries, in dem die Praktiken von XP dargestellt sind. Die Praktiken, die wir in diesem Buch behandeln, sind die vier in der Mitte und die Praktik ganz links.
Abb. I.1: Der Kreislauf des Lebens: die Praktiken von XP
Die vier in der Mitte sind die technischen Praktiken von XP: Testgetriebene Entwicklung (engl. Test-Driven Development oder kurz TDD), Refactoring, Einfaches Design und Pair Programming (das wir auch kollaborative Programmierung oder Pairing nennen). Die Praktik ganz links, Akzeptanztests, ist die technischste und ingenieurmäßigste der Praktiken von XP.
Diese fünf Praktiken zählen zu den Grundlagen des Softwarehandwerks.
Testgetriebene Entwicklung
TDD ist der Dreh- und Angelpunkt. Ohne sie sind die anderen Praktiken entweder unmöglich oder wenig wirksam. Aus diesem Grund nehmen die beiden folgenden Kapitel, die TDD beschreiben, fast die Hälfte der Seiten dieses Buchs ein und sind sehr technisch. Diese Aufteilung mag unausgewogen erscheinen. In der Tat kommt es mir selbst auch so vor, und ich habe lange mit mir gerungen, was ich dagegen tun soll. Ich bin jedoch zu dem Schluss gekommen, dass dieses Ungleichgewicht eine Reaktion auf das entsprechende Ungleichgewicht innerhalb unserer Branche ist. Zu wenige Programmierer kennen diese Praktik gut.
TDD ist die Praktik, die die Arbeitsweise eines Programmierers in jeder Sekunde bestimmt. Es ist weder eine vorbereitende Praktik noch eine nachbereitende Praktik. TDD ist prozessbegleitend und immer vor Augen. Es gibt keine Möglichkeit, TDD teilweise durchzuführen. Es ist eine Alles-oder-nichts-Praktik.
Die Essenz von TDD ist sehr einfach. Kleine Zyklen und Tests haben Vorrang. Tests stehen vor allem anderen. Tests werden zuerst geschrieben. Tests werden zuerst aufgeräumt. Bei allen Aktivitäten stehen Tests an erster Stelle. Und alle Aktivitäten werden in kleinste Zyklen unterteilt.
Die Zykluszeiten werden in Sekunden und nicht in Minuten gemessen. Sie werden in Zeichen und nicht in Zeilen gemessen. Die Feedbackschleife wird fast buchstäblich so schnell geschlossen, wie sie geöffnet wurde.
Das Ziel von TDD ist es, eine Testsuite zu erstellen, der Sie Ihr Leben anvertrauen würden. Wenn die Testsuite erfolgreich alle Tests durchläuft, sollten Sie den Code mit gutem Gefühl veröffentlichen können.
Von allen Praktiken ist TDD die mühsamste und komplexeste. Sie ist aufwendig, weil sie alles dominiert. Sie ist das Erste und das Letzte, woran man denkt. Sie ist die Einschränkung, die sich über alles legt, was man tut. Sie ist der Treiber, der das Tempo ungeachtet von Druck und Stress konstant hält.
TDD ist so komplex, weil Code komplex ist. Für jede Form von Code gibt es eine entsprechende Form des TDD. TDD ist komplex, weil die Tests so gestaltet sein müssen, damit sie zum Code passen, ohne zu eng an den Code gekoppelt zu sein, und sie müssen fast alles abdecken und dennoch in Sekundenschnelle ausgeführt werden können. TDD ist eine aufwendige und komplexe Fähigkeit, die sehr schwer zu erlernen ist, dafür aber einen unschätzbaren Wert hat.
Refactoring
Refactoring ist die Praktik, die es uns ermöglicht, sauberen Code zu schreiben. Refactoring ist ohne TDD schwierig, wenn nicht gar unmöglich.[1] Daher ist das Schreiben von sauberem Code ohne TDD genauso schwierig oder unmöglich.
Refactoring ist die Praktik, mit der wir schlecht strukturierten Code in Code mit einer besseren Struktur umwandeln – ohne das Verhalten zu verändern. Dieser letzte Teil ist entscheidend. Indem wir garantieren, dass das Verhalten des Codes nicht beeinträchtigt wird, sind die Verbesserungen an der Struktur garantiert sicher.
Der Grund, warum wir den Code nicht bereinigen – der Grund, warum Softwaresysteme mit der Zeit »verrotten« –, ist, dass wir Angst haben, dass die Bereinigung des Codes das Verhalten der Software verändert. Wenn wir aber eine Möglichkeit haben, Code zu bereinigen, von der wir wissen, dass sie sicher ist, dann werden wir den Code bereinigen, und unsere Systeme werden nicht »verrotten«.
Aber wie können wir garantieren, dass unsere Verbesserungen das Verhalten nicht verändern? Dazu haben wir die Tests des TDD.
Refactoring ist auch deshalb eine komplexe Praktik, weil es viele Möglichkeiten gibt, schlecht strukturierten Code zu erstellen. Daher gibt es auch viele Strategien, um diesen Code zu bereinigen. Zusätzlich muss sich jede dieser Strategien reibungslos in den TDD-Zyklus einfügen, in dem wir zuerst Tests schreiben. In der Tat sind diese beiden Praktiken so eng miteinander verwoben, dass sie praktisch untrennbar sind. Es ist fast unmöglich, Refactoring ohne TDD durchzuführen, und es ist praktisch unmöglich, TDD ohne Refactoring zu praktizieren.
