Clean Code

Was ist Clean Code, welche Werte und Prinzipien gelten bei der Implementierung und wo liegen Herausforderungen?

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 - das Ergebnis von Werten, Prinzipien und Praktiken

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.

Ein Fundament aus Werten

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:

  1. 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.
  2. 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 Learnings 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 expliziete 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

Werte durch konkrete Prinzipien und Praktiken unterstützen

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 ISimple and Stupid

„Mache es so einfach wie möglich“ lautet das KISS-PrinzipEs 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.

Gemeinsam werden das Single Responsibility Principle, das Open Closed Principle, das Liskov Substitution Principle, das Interface Segregation Principle und das Dependency Inversion Principle auch als SOLID-Prinzip bezeichnet. Diese Prinzipien erachtet Robert C. Martin in seinem Buch „Agile Software Development: Principles, Patterns and Practices“ als wesentlich für die Entwicklung von Clean Code.5

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 Testattrapen, 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 Controll 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 Reflextion 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 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 Produktivititä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.

Clean Code in der Praxis

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.

 

Die kontinuierliche Beschäftigung mit Clean Code

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!

Impuls zum Diskutieren:

Clean Code ist nicht wichtiger als funktionaler oder performanter Code, aber auch nicht unwichtiger. Und in der Praxis lässt sich sauberer Code gar nicht entwickeln.

Hinweise:

[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

In XING gibt es eine Community, in der über Aspekte des sauberen Codierens gesprochen wird.

Hier finden Sie ergänzende Informationen aus dem t2informatik Blog:

t2informatik Blog: Die Implementierung von Clean Code

Die Implementierung von Clean Code

t2informatik Blog: Dokumentation im Code - Pro und Contra

Dokumentation im Code – Pro und Contra

t2informatik Blog: Sinn und Unsinn der Unittest Coverage

 Sinn und Unsinn der Unittest Coverage