Clean Code
Inhaltsverzeichnis: Definition – Clean Code Development – Werte – Prinzipien und Praktiken – Tipps – Herausforderungen – Download – Hinweise
Wissen kompakt: Clean Code bezeichnet Code, der leicht zu verstehen, zu ändern, zu erweitern und zu warten ist. Er ist das Ergebnis von Werten, Prinzipien und Praktiken der Softwareentwicklung.
Clean Code Definition
Clean Code ist ein Begriff aus der Softwareentwicklung und adressiert die klare, verständliche, nachvollziehbare, logische und disziplinierte Implementierung von Code. Ziel ist es, Software effizient und effektiv zu produzieren, und dabei den Code so zu gestalten, dass er leicht
- lesbar,
- änderbar,
- erweiterbar
- und wartbar
ist.
In der Praxis der Softwareentwicklung ist es nicht unüblich, dass funktionierender Code nicht notwendigerweise “sauber” ist. Schnell führt dies zu Fehlern bei Adaptionen oder Problemen bei Erweiterungen, bspw. wenn eine kleine Änderung zu einer Kaskade von nachfolgenden Änderungen führt. Die Pflege und Weiterentwicklung von Software wird unnötig erschwert. Der Ansatz, den die Clean Code Developer School1 propagiert, wirkt dem entgegen, in dem
- zuerst eine Analyse und anschließend ein Design (Clean Analysis und Clean Design genannt) durchgeführt wird (unabhängig davon, ob es sich um Greenfield oder Brownfield Projekte handelt),
- die Entwicklung inkrementell, lernend, reaktiv und in enger Zusammenarbeit mit den Kunden (in einem Wort: agil) erfolgt,
- Leitgedanken – Werte, Prinzipien und Praktiken – definiert werden, die für die Entwicklung elementar und entsprechend zu berücksichtigen sind.
Durch diesen Ansatz werden technische Schulden (Technical Debt) vermieden oder zumindest so gering wie möglich gehalten. Zwar ist der Aufwand zur Implementierung von sauberem Code initial vergleichsweise hoch, über den Lebenszyklus der Software amortisiert er sich in der Praxis aber sehr schnell. Damit ist Clean Code nicht nur technologisch nachhaltig, sondern auch ökonomisch sinnvoll.
Clean Code Development
Während die frühen Werke von Robert C. Martin “Clean Code: A Handbook of Agile Software Craftsmanship”2 oder Dustin Boswell “The Art of Readable Code”3 ihren Fokus vor allem auf die einfache, textuelle Form von Code legten, fasst die Clean Code Developer School das Clean Code Development etwas weiter: Sie betrachtet den Entwicklungsprozess und definiert Werte sowie zahlreiche Prinzipien und Praktiken. Vor allem erkennt sie aber, dass eine agile Vorgehensweise und strukturelle Überlegungen vor der Implementierung – namentlich die Analyse und der Entwurf – notwendig sind. Ohne entsprechende Struktur lassen sich zwar funktionale, nicht-funktionale Anforderungen aber nur sehr schwer oder überhaupt nicht implementieren.
Die Struktur einer Software bietet darüber hinaus die Basis für eine Evolution anhand neuer Anforderungen. Ohne Struktur steigen die Aufwände für neue Features exponentiell. Hinzu kommt, dass sich eine Struktur nur schwer nachträglich hinzufügen lässt. Im Zuge von Clean Code Development gilt also der Spruch: Erst die Analyse und der Entwurf, dann die Implementierung. Oder anders ausgedrückt: erst sauber denken, dann sauber realisieren.
Clean Code Werte
Der Ansatz sauberen Code zu implementieren basiert auf einem Fundament aus vier Werten:
- Wandelbarkeit
- Korrektheit
- Produktionseffizienz
- Kontinuierliche Verbesserung
Wandelbarkeit
Software lebt. Häufig sogar länger als ursprünglich angenommen. Sie wird verbessert, angepasst, erweitert. Je einfacher eine Software auf geänderte Anforderungen und Rahmenbedingungen angepasst kann, desto höher ist ihre Wandelbarkeit. Steigern lässt sich die Wandelbarkeit durch die Verwendung verschiedener Entwurfsprinzipien, die Einfluss auf die Softwarearchitektur haben, wie bspw.
- die Abstraktion von Informationen,
- die Trennung von Zuständigkeiten,
- die Nutzung von Schnittstellen
- oder die Kopplung von Komponenten.
Idealerweise wird die Wandelbarkeit von Anfang an bei der Entwicklung von Software beachtet, denn je später sie ins Blickfeld rückt, desto aufwändiger, teurer und schwieriger werden Anpassungen.
Korrektheit
Korrektheit als Wert klingt vielleicht im ersten Moment banal. Dahinter versteckt sich aber mehr als nur die korrekte Ausführung von Funktionen, die richtige Verwendung von Klassen und Methoden, oder die Anwendung von Prinzipien und Praktiken der Softwareentwicklung. Korrektheit adressiert auch den Umgang mit Anforderungen.
Oftmals kennen Entwickler die Anforderungen von Kunden gar nicht. Sie kennen keine Akzeptanzkriterien. Sie kennen keine Rahmenbedingungen bzw. keinen Systemkontext, keine Einsatzszenarien und keine nicht-funktionalen Anforderungen. Wie kann es da gelingen, auf Korrektheit zu achten? Anstelle darauf zu vertrauen (oder zu hoffen), dass eine Testabteilung eventuelle Fehler findet, sollten Entwickler vor der Implementierung verstehen, was Kunden tatsächlich wollen. Erst wenn sie das wissen, können sie Anwendungen korrekt implementieren.
Produktionseffizienz
Die Produktionseffizienz als Wert betrachtet zwei Aspekte der Softwareentwicklung:
- Softwareentwicklung verursacht Aufwand und Kosten. Code, der schwer zu lesen, zu ändern, zu erweitern oder zu warten ist, verlängert die Entwicklungszeit und ist ineffizient. Je umfangreicher und je länger eine Software entwickelt wird, desto stärker fallen diese Probleme ins Gewicht. Produktionseffizienz bedeutet, dass eine Software jahrelang weiterentwickelt werden kann, da Wert auf Clean Code gelegt wird. Die Alternative wäre eine Neuentwicklung anstelle einer Weiterentwicklung – und oftmals ist das keine sehr attraktive Alternative.
- Die Produktionseffizienz ist ein Maß für die anderen Werte. Einerseits um bspw. den Aufwand für die Korrektheit von Software nicht unendlich in die Höhe zu schrauben, andererseits auch um Aspekte wie Gold Plating, bei dem in positiver Absicht mehr entwickelt wird, als mit dem Auftraggeber vereinbart wurde, oder Overengineering, bei dem Software in höherer Qualität entwickelt und geliefert wird, als dies von Kunden gefordert wurde.
Kontinuierliche Verbesserung
Der Wert “kontinuierliche Verbesserung” adressiert nicht die Verbesserung der Implementation als solches, denn dieser Aspekt ist bereits Teil der Wandelbarkeit. Die kontinuierliche Verbesserung fordert die Auseinandersetzung der Entwickler mit ihrer Arbeitsweise. So könnten bspw. folgende Fragen in Fokus rücken:
- Welche Erfahrungen wurden beim Pair Programming oder dem Mob Programming gemacht?
- Was sind die Ursachen für Code Smells?
- Wie lässt sich die Zusammenarbeit im Team und mit den Kunden verbessern?
- Was sind unsere Erkenntnisse bei Code Reviews?
- Was sollte in der nächsten Iteration besser werden?
- Wie lassen sich Code Katas optimieren?
Kontinuierliche Verbesserung ist also ein Wert, der sich um die Reflexion des Teams dreht.
Auf welchen dieser Werte sollten Entwickler als erstes achten? Primär geht es bei den Werten um keine explizite Reihenfolge, an die sich Entwickler halten können. Ein Wert ist nicht wichtiger als ein anderer. Dennoch steht Wandelbarkeit bewusst an erster Stelle. Wandelbarkeit steht für eine Grundhaltung, eine Offenheit für zukünftige Anforderungen und Evolutionen, selbst wenn diese natürlich noch nicht bekannt sind. So wie in der Luftfahrt Safety First gilt, so sollte bei der Softwareentwicklung Wandelbarkeit zuerst gelten.4
Clean Code Prinzipien und Praktiken
Auch wenn die Werte eine Orientierung für Softwareentwickler bieten, so sind sie für die konkrete Umsetzung zu abstrakt. Aus diesem Grund gibt es Prinzipien und Praktiken:
- Prinzipien sind Grundsätze zur Strukturierung von Software. Sie ergänzen einander. Idealerweise wird immer eine maximale Zahl von Prinzipien beachtet. Wird Software entgegen der Prinzipien entwickelt, zeigen sich die Auswirkungen spätestens mittelfristig, bspw. durch steigende Aufwände bei Anpassungen. Tendenziell lässt sich an einer Implementierung erkennen, ob ein Prinzip eingehalten wurde oder nicht.
- Praktiken sind Handlungsanweisungen. Es sind Methoden und Techniken, die kontinuierlich zum Einsatz kommen. Manche Praktiken erfordern den Einsatz von Tools. Und nicht immer lässt sich anhand der Implementierung erkennen, ob eine Praktik umgesetzt wurde.
Nachfolgend finden Sie eine Übersicht der Prinzipien:
DRY – Dont’ Repeat Yourself
Das DRY-Prinzip zielt darauf ab, die Wiederholung von Software-Mustern zu reduzieren, sie durch Abstraktionen zu ersetzen oder Datennormalisierung zu verwenden, um Redundanzen zu vermeiden.
KISS – Keep It Simple and Stupid
“Mache es so einfach wie möglich” lautet das KISS-Prinzip. Es fordert, Dinge nicht zu kompliziert zu sehen oder zu implementieren, und stets die einfachste Lösung für ein Problem zu suchen oder zu nutzen.
Vorsicht vor Optimierungen
Optimierungen verursachen häufig hohe Aufwände, sie sind oft weder notwendig noch nützlich. Eine einfach Regel daher lautet: Vorsicht vor Optimierungen. Und falls doch optimiert werden sollte, dann nach einer genauen Analyse.
FCoI – Favour Composition over Inheritance
Das FCoI-Prinzip propagiert die Verwendung von Kompositionen anstelle von Vererbungen, so dass Klassen von ihren Algorithmen und deren Details getrennt werden, um so das Verhalten einer Klasse zur Laufzeit verändern zu können.
SRP – Single Responsibility Principle
Das SRP-Prinzip adressiert den Softwareentwurf, wonach ein Modul mit seinen Klassen, Funktionen, Variablen und Datenstrukturen nur einem Akteur gegenüber verantwortlich sein sollte.
SLA – Single Level of Abstraction
Das SLA-Prinzip besagt, dass verschiedene Abstraktionslevel von Funktionen nicht miteinander vermischt werden sollen, um so die Lesbarkeit, das Verständnis und die Wartbarkeit des Codes zu erhöhen.
Source Code Konventionen
Source Code Konventionen definieren Leitlinien, die dabei helfen, die Softwarequalität strukturell zu verbessern. Sie umfassen bspw. Namensregeln, Kommentare, Deklarationen, Statements, White Spaces etc.
SoC – Separation of Concerns
Das SoC-Prinzip fordert die Konzentration einer Klasse auf einen konkreten Aspekt, um einzelne Belange bzw. Concerns separat testen und Anpassungen überschaubar gestalten zu können.
DIP – Dependency Inversion Principle
Das DIP propagiert, dass Module höherer Ebenen nicht von Modulen niedrigerer Ebenen abhängen, Module von Abstraktionen abhängen und Abstraktionen nicht von Details sondern Details von Abstraktionen abhängen sollten.
ISP – Interface Segregation Principle
Das ISP-Prinzip besagt, dass Schnittstellen eine hohe Kohäsion haben und somit lediglich zusammengehörige Elemente enthalten sollten. Ziel ist es, die Kopplung zwischen Komponenten “schlank” und übersichtlich zu gestalten.
POLA – Principle of Least Astonishment
Das Principle of Least Astonishment, manchmal auch als POLS – Principle of Least Surprise bezeichnet, besagt, dass eine Anwenderschnittstelle immer so gestaltet werden sollte, dass der Anwender möglichst wenige Überraschungen erlebt.
LSP – Liskov Substitution Principle
Das LSP-Prinzip bzw. Ersetzbarkeitsprinzip besagt, dass sich abgeleitete Subtypen wie ihre Basistypen verhalten müssen, wobei Subtypen die Funktionalitäten der Basistypen erweitern, aber nicht einschränken dürfen.
OCP – Open Closed Principle
Das OCP-Prinzip beschäftigt sich mit der Erweiterbarkeit von Modulen, Klassen, Methoden etc., wonach diese offen für Erweiterungen und geschlossen für Modifikationen sein sollten.
Information Hiding Principle
Nach dem Information-Hiding-Prinzip sollte das Innenleben von Komponenten durch Schnittstellen gekapselt bzw. verborgen werden, um unnötige Abhängigkeiten und umfangreiche Anpassungen zu vermeiden.
LoD – Law of Demeter
Das Gesetz von Demeter, auch als Principle of Least Knowledge bezeichnet, besagt, dass Objekte nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren sollten, um so die Kopplung zu verringern.
TDA – Tell, Don’t Ask Principle
Beim TDA-Prinzip geht es darum, Daten mit den Funktionen zu bündeln, die mit diesen Daten arbeiten. Anstatt ein Objekt nach Daten zu fragen, um mit diesen Daten zu agieren, sollte dem Objekt mitgeteilt werden, was es tun soll.
Entwurf und Implementation überlappen nicht
Oftmals laufen Entwurf und Implementation in der Praxis auseinander. Idealerweise sollten Inkonsistenzen durch die Trennung der Zuständigkeiten zwischen Entwurf bzw. Architektur und Implementierung minimiert werden.
Implementation spiegelt Entwurf
Die Implementation sollte nicht unabhängig von Entwurf bzw. Architektur existieren. Bspw. sollten Komponenten, die in der Architektur definiert wurden, auch im Code physisch getrennt werden.
YAGNI – You Ain’t Gonna Need It
Das YAGNI-Prinzip fordert Funktionalität erst dann zu implementieren, wenn sie tatsächlich benötigt wird. Oft sind Anforderungen für Features noch zu ungenau oder diese stellen sich später als unnötig heraus. Im Zweifel sollte also (verfrühter, unnötiger) Aufwand vermieden werden.
Nachfolgend finden Sie eine Übersicht der Praktiken:
Pfadfinderregel beachten
Die Pfadfinderregel besagt: “Hinterlasse einen Ort immer in einem besseren Zustand, als Du ihn vorgefunden hast.” Ergo: Kleinigkeiten im Code sollten verbessert und Fehler beseitigt werden, bevor sie zu größeren Problemen mutieren.
Ursachenanalyse durchführen
Die Ursachenanalyse – auf Englisch Root Cause Analysis bezeichnet – fokusiert auf der Beseitigung von Ursachen anstelle der Beseitigung von Symtomen. Dies ist mittelfristig deutlich effizienter.
Versionsverwaltungssystem einsetzen
Versionsmanagement beschäftigt sich mit der Verwaltung von Dateien inklusive Archivierung, Protokollierung, Wiederherstellung und Zugriffskoordination. Softwareentwicklung ohne Versionsverwaltungssystem ist undenkbar.
Einfache Refaktorierungsmuster anwenden
Refactoring adressiert die Restrukturierung einer Software unter Beibehaltung des Funktionsangebots. Das Extrahieren von Methoden oder das Umbenennen von unverständlichen Namen sind einfache Refaktorierungsmuster.
Täglich reflektieren
Reflexion ist die Voraussetzung, um etwas aktiv zu lernen. Die Praxis zeigt, dass sie aber nur täglich stattfindet, wenn sie auch aktiv in den Kalender eingeplant wird, ansonsten fällt sie dem Tagesgeschäft zum Opfer.
Fehlerverfolgung / Issue Tracking
Die Fehlerverfolgung, auch als Bug Tracking oder Issue Tracking bezeichnet, beschreibt den Prozess von der Erfassung bis zur Beseitigung von Fehlern, offenen Punkten, Wünschen etc.
Automatisierte Integrationstests verwenden
Integrationstests überprüfen die Zusammenarbeit verschiedener Komponenten, bspw. nach einem Refactoring oder einer Erweiterung. Die Automatisierung sorgt für die benötigte Effizienz beim Testen.
Reviews durchführen
Reviews erhöhen die Qualität des Codes, sei es im Zuge eines Pair Programmings, eines Peer Reviews oder bei einem Code Review. Ziel ist die kontinuierliche Verbesserung der Codequalität.
Lesen und sich weiterbilden
Softwaretechniken, Methoden, Frameworks, Tools – vieles entwickelt sich im Kontext der Softwareentwicklung weiter. Hier empfiehlt es sich, viel zu lesen (Blogs, Zeitschriften oder Bücher), um auf dem Laufenden zu bleiben.
Automatisierte Unit-Tests verwenden
Unit-Tests überprüfen, ob die entwickelten Komponenten wie beabsichtigt funktionieren. Bspw. werden einzelne Klassen oder Methoden getestet. Die Automatisierung der Tests reduziert den Testaufwand.
Mockups nutzen
Für das isolierte Testen einzelner Komponenten gilt es Abhängigkeiten zu beseitigen. Mockups bzw. Mock-Objekte sind Testattrappen, die mit der zu testenden Komponente interagieren, bspw. weil das gewünschte Objekt noch nicht zur Verfügung steht.
Code Coverage analysieren
Die Codeüberdeckung bzw. Code Coverage drückt aus, welcher Anteil des Quellcodes – Anweisungen, Verzweigungen, Pfade und Bedingungen – durch Testfälle ausgeführt wird. Ziel ist es, die Anteile zu finden, die noch nicht getestet werden.
Komplexe Refaktorisierungen vornehmen
Es ist nicht möglich, Code direkt in einer optimalen Form zu implementieren. Neben den einfachen gibt es auch komplexere Refaktorisierungen6, deren Wirkung sich jedoch nur durch automatisierte Tests überprüfen lässt.
Teilnahme an Fachveranstaltungen
Um sich auf dem Gebiet der Softwareentwicklung weiterzubilden, ist zusätzlich zum Lesen von Fachliteratur der Austausch mit anderen Entwicklern – bspw. bei Meetups, in User Groups oder auf Messen – wichtig.
Continuous Integration praktizieren
Die kontinuierliche Integration von Komponenten zu einer Anwendung – bspw. in Form von Daily Builds – bietet den Vorteil, Inkompatibilitäts- und Integrationsprobleme schnell und nicht erst zum Ende einer Iteration zu diagnostizieren.
Metriken erheben
Eine statische Codeanalyse hilft bspw. bei der Überprüfung der Korrektheit durch automatisierte Tests oder der Bestimmung der Anforderungskonformität. Auch die Wandelbarkeit einer Software lässt sich in Teilen durch Metriken bestimmen.
Inversion of Control Container verwenden
Der IoC Container hilft beim Instanziieren und Verbinden vieler kleiner Objekte, die als Folge der SoC-Prinzips entstehen. Darüber hinaus helfen sie auch bei der Umkonfiguration von Klassen für Testfälle.
Erfahrungen weitergeben
Wissen zu besitzen ist gut, Wissen weiterzugeben ist sehr gut. Der Gedanke dahinter: erst durch Wissensvermittlung findet wahre Reflexion und die Durchdringung eines Fachthemas statt. Und davon profitieren alle Beteiligten.
Fehler messen
Ein Ziel der Softwareentwicklung ist es, die Anzahl der Fehler zu minimieren, die Kunden nach der Freigabe einer neuen Version melden. Die Vergleichbarkeit der Messung ist dabei wichtiger als die Präzision.
Continuous Delivery praktizieren
Das Continuous Delivery beschreibt einen Prozess zur Auslieferung von getesteten Updates, bei dem das Setup und das Deployment automatisiert werden. Es folgt nach der Continuous Integration.
Iterative Entwicklung betreiben
Die Entwicklung in Iterationen und kurze Feedbackzyklen sind heutzutage zwei wesentliche Erfolgsfaktoren der Softwareentwicklung. In der Folge sinkt das Risiko von Fehlentwicklungen und die Qualität der Software steigt.
Komponentenorientiert entwickeln
Die komponentenorientierte Entwicklung fördert die Produktivität durch die parallele Implementierung, verbessert die Übersichtlichkeit der Anwendung und erleichtert das Testen der einzelnen Komponenten.
Test first
Test first propagiert, dass Schnittstellen sowie ein entsprechend gewünschtes Verhalten durch Tests beschrieben wird. Durch diesen Ansatz entsteht gleichzeitig die Spezifikationsdokumentation in Form von ausführbarem Code, der automatisch überprüft werden kann.
Tipps zur Anwendung von Clean Code
Und wie kommen Werte, Prinzipien und Praktiken in Einklang? Welche Tipps gibt es zur Implementierung von Clean Code?7
- Allgemeine Tipps
Befolgen Sie die Konventionen. Reduzieren Sie die Komplexität so weit wie möglich. Je einfacher Code, desto besser. Verhalten Sie sich wie ein Pfadfinder und hinterlassen Sie den Code besser als Sie ihn vorgefunden haben. Und suchen Sie stets nach der Ursache und nicht nach dem Symptom eines Problems. - Tipps zur Gestaltung
Halten Sie konfigurierbare Daten auf einem High Level. Nutzen Sie Polymorphismus statt if/else oder switch/case. Verwenden Sie separaten Multithreading-Code. Vermeiden Sie Überkonfigurierbarkeit und nutzen Sie Dependency Injection. Folgen Sie dem Gesetz von Demeter. - Tipps zur Verständlichkeit
Seien Sie konsequent und implementieren Sie ähnliche Dinge auf die gleiche Art und Weise. Verwenden Sie erklärende Variablen. Kapseln Sie Randbedingungen, denn oftmals sind sie schwer nachzuvollziehen. Bevorzugen Sie dedizierte Wertobjekte gegenüber primitiven Typen. Vermeiden Sie logische Abhängigkeiten, schreiben Sie also bspw. keine Methoden, die in Abhängigkeit von etwas anderem in derselben Klasse korrekt funktionieren. Und vermeiden Sie negative Bedingungen. - Tipps für Namen
Verwenden Sie beschreibende, unmissverständliche, aussagekräftige, aussprechbare und durchsuchbare Namen. Ersetzen Sie magische Zahlen durch benannte Konstanten und vermeiden Sie Encodings. - Tipps für Funktionen
Halten Sie Funktionen klein, in dem diese nur eine Sache tun. Verwenden Sie beschreibende Namen und nutzen Sie möglichst wenige Argumente. Vermeiden Sie Nebenwirkungen. - Tipps für Kommentare
Versuchen Sie, den Code für sich sprechen zu lassen. Kommentieren Sie Ihren Code nicht aus. Wenn Sie kommentieren, dann zur Erklärung der Absicht oder als Hinweis auf mögliche Nebeneffekte. - Tipps zur Struktur des Quellcodes
Deklarieren Sie Variablen in der Nähe ihrer Verwendung. Abhängige und ähnliche Funktionen sollten nahe beieinander liegen. Platzieren Sie Funktionen in Abwärtsrichtung, vermeiden Sie eine horizontale Ausrichtung. Halten Sie Codezeilen kurz, verwenden Sie White Spaces, um Aspekte zu assoziieren bzw. zu dissoziieren und achten Sie auf Einrückungen. - Tipps zu Tests
Gestalten Sie Tests lesbar, schnell, unabhängig, wiederholbar und automatisiert. Und testen Sie immer nur einen Aspekt pro Test.
Herausforderungen bei der Clean Code Entwicklung
Wandelbarkeit, Korrektheit, Produktionseffizienz und kontinuierliche Verbesserung lauten die vier Werte von Clean Code. Sie als Vorteile oder Ziele zu postulieren klingt logisch und sinnvoll, doch in der Realität der Entwicklung von Software ist die Umsetzung alles andere als leicht. Sauberer Code lässt sich nicht ohne weiteres messen und damit auch nicht einfach im Vorbeigehen realisieren. Hier kommen die Prinzipien und Praktiken zum Tragen. Allerdings in Verbindung mit der Bereitschaft, sich kontinuierlich mit Clean Code, seiner Bedeutung und der konkreten Umsetzung auseinander zu setzen. Nur wenn die saubere Umsetzung im Fokus steht, kann sie dauerhaft gelingen. In diesem Fall ist weniger tatsächlich weniger und mehr tatsächlich mehr. In Abwandlung eines der Prinzipien könnte man sagen: You gonna need it!
Wollen Sie das Clean Code Whitepaper kostenlos downloaden?
Alles Wichtige über das Clean Code auf einen Blick.
- Definition
- Werte
- Prinzipien und Praktiken
- Tipps
- Herausforderungen
Wissen auf 14 Seiten zum Mitnehmen.
Einfach hier klicken.
- Ist Clean Code wichtiger als / gleich wichtig wie / weniger wichtig als funktionaler oder performanter Code?
- Lässt sich sauberer Code überhaupt entwickeln?
- Zahlen Unternehmen eigentlich für sauberen Code oder eher für dessen Abwesenheit?
Hinweise:
Haben Sie Lust auf einen neuen Lieblings-Newsletter?
Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.
[1] Hier finden Sie Informationen zur Clean Code Developer School und ihre Sicht auf nachhaltige Produktivität in der Softwareentwicklung.
[2] Robert C. Martin: Clean Code: A Handbook of Agile Software Craftsmanship
[3] Dustin Boswell: The Art of Readable Code: Simple an Practical Techniques for Writing Better Code
[4] Die Clean Code Developer School: Die Anforderungen auf die Füße stellen
[5] Robert C. Martin: Agile Software Development: Principles, Patterns and Practices
[6] Martin Fowler: Online Catalog of Refactorings
[7] Wojtek Lukaszuk: Zusammenfassung von Tipps
Im Jahr 2008 propagierte Robert C. Martin auf einer Konferenz einen 5. Wert zum Agilen Manifest: We value craftsmanship over crap. Frei übersetzt: Handwerkliches Können ist wichtiger als Mist. Martin hatte beobachtet, dass sowohl Extreme Programming als auch Scrum zentrale Probleme der Entwicklung nicht beseitigen würden, und forderte die Anwesenden auf der Konferenz auf, fortan Clean Code zu schreiben und sich nicht dem Zeitdruck zu beugen oder zu behaupten, sie hätten keine Zeit dafür oder dürften dies nicht tun.
Hier finden Sie ergänzende Informationen aus dem t2informatik Blog:
Die Implementierung von Clean Code
Dokumentation im Code – Pro und Contra
Sinn und Unsinn der Unittest Coverage