…
I wrote that article in 2007, and I am stunned, but not entirely surprised, to hear that three years later “the vast majority” of so-called programmers who apply for a programming job interview are unable to write the smallest of programs. To be clear, hard is a relative term — we’re not talking about complicated, Google-style graduate computer science interview problems. This is extremely simple stuff we’re asking candidates to do. And they can’t. It’s the equivalent of attempting to hire a truck driver and finding out that 90 percent of the job applicants can’t find the gas pedal or the gear shift.

Aus den Unmengen von Kommentaren zu urteilen, ist das ein Problem, mit dem sehr viele zu kämpfen haben. Sein Artikel beschäftigt sich mit der Arbeit von Personen, die Einstellungsgespräche führen, und er versucht ein paar Tipps zu geben, wie man dieses Verfahren führen soll.

Ich musste allerdings beim Lesen ständig auf die Situation “danach” denken, wenn diese NPPs (sprich Non- Programming Programmers) bereits aus irgendeinem Grund eingestellt wurden. Aus Erfahrung weiß ich genau, was mir viel über jemanden verraten würde: weiß er/sie etwas über Clean Code, kennt er die Folgen vom Creepy Code und wie ist die persönliche Einstellung dazu? Also zusammengefasst: geht es um einen professionellen Softwareentwickler? Dafür würden auch ein Code-Review oder ein paar Fragen reichen.

Was haltet ihr von Coding bei der Einstellung? Ist das auch in Europa üblich? Würde das die unpassenden Personen ausfiltern? Oder soll man sich die Zeit nehmen und dem Kandidaten “ungesehen” die Probezeit anbieten? Würde das vielleicht zu viele Personen ausfiltern? Kann man sich das überhaupt erlauben in der heutigen Zeit der Fachkräftemangel? (Gut, man fragt sich natürlich, ob wir hier über “Fachkraft” sprechen dürfen…)

Um etwas Ordnung in die Webanwendungen zu bringen, haben wir also vor 4 Jahren angefangen, nach einem 3-Schichten-Modell zu entwickeln. Wir haben neue Funktionalitäten und neue Anwendungen nur noch so gebaut und wir waren für eine kurze Zeit zufrieden. Alles lief gut. Als wir den Umstieg auf .NET begonnen haben, haben wir weiterhin nach einem Mehr-Schichten-Modell gearbeitet, wir haben nur die Anzahl der Schichten erhöht.

Die Anwendungen wuchsen weiter, wir haben immer mehr Bereiche ausgelagert und diese hauptsächlich mit Webservices angesprochen. Währenddessen waren wir daran, unser Hauptprodukt, ein Portal für unseren Kunden mit der neuen Technologie entsprechend der alten Anforderung neu zu bauen. Und dann ist es passiert: ehe wir uns versahen, hatten wir ein riesiges Projekt, das alle mögliche Anwendungen eingebunden bzw. durch Webservices angesprochen hat. Die Grenzen waren fließend, eventuelle Änderungen an anderen Anwendungen konnten das Projekt unbuildbar machen, also ein ähnlicher Zustand wie vor paar Jahren zuvor.

Die Weiterentwicklung hat nicht nur in unserer Art zu Programmieren stattgefunden, wir selbst haben uns auch weiterentwickelt, wir haben die Community kennen gelernt. Bei den Open Space-Veranstaltungen haben wir Stefan und Ralf kennengelernt und durch sie eine andere Sichtweise der Dinge: die Modellierung einer Lösung durch Softwarezellen.

Wir haben sie zu uns eingeladen und uns die Idee erklären lassen. Das Stichwort heißt Holon. Wikipedia definiert ein Holon folgendermaßen:

Der Begriff Holon (von griech. ὅλος, hólos und ὀν, on „ganzes Seiendes“) wurde von Arthur Koestler geprägt und bedeutet ein Ganzes, das Teil eines anderen Ganzen ist. Es wird auch als “Ganzes/Teil” umschrieben.

Jede Anwendung ist ein Ganzes, die aus Teilen besteht, die ihrerseits auch als Ganze zu betrachten sind.

Seit dem Besuch von Ralf und Stefan haben wir uns die Artikelserie von Ralf von dotnetpro durchgelesen, die Webcasts (Teil 1, Teil 2) angeschaut und wir haben angefangen, diese Modellierung auszuprobieren.

Wir haben noch einen langen und interessanten Weg vor uns, aber eins ist jetzt schon sicher: wir werden versuchen unsere nächste Projekte durch Softzellen modellieren.

Solange die Komplexität nicht wieder die Überhand gewinnt

Refaktorisierung ist, wie die Küche nach dem Abendessen aufzuräumen. Das erste Mal, wenn du das überspringst, bist mit der Kochen schneller fertig. Aber das Fehlen von sauberem Geschirr und sauberem Arbeitsplatz führt dazu, dass die Vorbereitung diesmal länger dauert. Am liebsten würdest du das Aufräumen wieder überspringen. Tatsache ist, dass du heute ohne das lästige Geschirrspülen wieder schneller fertig wärst. Aber der Schmutz wächst und wächst. Jedes Mal dauert es länger, das richtige Küchengerät zu finden, die vertrockneten Schmutzschichten vom Geschirr ab zu kratzen, und so weiter und so fort. Das Vorbereiten des Abendessens dauert ewig…
Das Überspringen der Abwasch macht das Kochen eigentlich nicht wirklich schneller.

Das Ziel von Refaktorisierung ist die Bereinigung des Codes, jeden Tag, jede Stunde, jede Minute. Wir wollen nicht den Code versauen. Wir wollen nicht ständig gezwungen zu sein, schmutzigen Bits und Bytes sauber zu schrubben. Wir wollen jeder Zeit in der Lage zu sein, unser System mühelos zu erweitern und zu verändern. Der wichtigste Faktor, der uns das möglich macht, ist die Sauberkeit des Codes.

Das Buch habe zwar noch nicht ganz durch, aber was ich bis jetzt gelesen habe, kann ich nur unterschreiben. Es beinhaltet die Prinzipien, wie man in einem agilen Team sauberen Code plant und Mustern und Beispiele, wie man ihn schreibt. Und wie ihr ja sieht, ist es in eine ganz tolle Art geschrieben

Erstens muss man die IDE anpassen: im März kommt .NET 4.0 raus und da wird Design by Contract mitgeliefert. Man kann das Konzept aber jetzt schon anwenden, wenn man die Assembly zusätzlich installiert. Danach muss man die dll referenzieren und im Eigenschaftenfenster des Projektes im neuen Tab Code Contracts das Runtime Checking einstellen.

Jetzt zum Code: Nehmen wir eine ganz einfache Klasse Bill deren Objekte mit einem IRepository gespeichert bzw. geladen werden.

Die Kontrakte kann man in den einzelnen Methoden oder für eine ganze Klasse schreiben (unter dem Attribut ContractInvariantMethode) aber ich finde am schönsten, dass man die auch auslagern kann: durch eine gegenseitige Markierung können Kontrakt-Klassen und Interfaces als “Paare” definiert werden:

Eine Vorbedingung wird mit Contract.Requires und eine Nachbedingung mit Contract.Ensures definiert. Beide Methoden bekommen boolische Ausdrücke. Diese Ausdrücke müssen frei von Seiteneffekten sein.

Die eigentliche Implementierung der Klasse schaut dann so aus:

Woher können wir wissen, dass das funktioniert? Es ist einfach, wir schreiben ein Paar Tests dazu!
Bei Kontraktverletzung wird eine Exception geworfen. Um diese – und dadurch die genaue Verletzung – überprüfen zu können braucht man etwas Workaround:

Danach sind die Tests dann einfach:

Ich hoffe, das Beispiel ist ausführlich genug, um die Vorteile von DbC zu highlighten. Stefan, vielen dank noch mal für den Artikel, ich habe mich natürlich von dir inspirieren lassen.

10 Classes

Die erste Regel von Klassen lautet: Sie sollten klein sein.
Die zweite Regel von Klassen lautet: Sie sollten noch kleiner sein als das.

Klassen sollten eine hohe Kohäsion haben.
Kohäsion ist ein Maß dafür, wie stark die Methoden und Daten einer Klasse miteinander zu tun haben. Zur Verdeutlichung:
Eine Klasse, in der jede Membervariable von jeder Methode der Klasse verwendet wird, ist maximal kohäsiv.

Bei Klassen sollten folgende Prinzipien beachtet werden:

• Das Single Responsibility Principle (SRP), welches besagt:

Eine Klasse oder ein Modul sollte nur einen Grund haben sich zu ändern. Eine Klasse sollte sich nur um EINE Sache kümmern.

• Das Open Close Principle (OCP), welches besagt:

Klassen sollten offen für Erweiterungen sein, aber geschlossen für Modifikation.

• Das Dependency Inversion Priniciple (DIP), welches besagt:

Klassen sollten von Abstraktionen abhängen und nicht von konkreten Klassen.

11 Systems

Separiere Konstruktion von Benutzung.
Realisiert werden kann das durch Dependency Injection.

Dependency Injection = Klassen bekommen ihre Abhängigkeiten von außen über den Konstruktor oder Setter übergeben. Dieses Pattern unterstützt das SRP, da sich die Klasse nicht mehr um das Instanzieren dieser Abhängigkeiten kümmern muss. Realisiert wird das ganze über Inversion of Control Container wie Windsor, Spring und wie sie alle heißen. Bei diesen Containern werden die Abhängigkeiten einmalig definiert, so dass man sich bei der Instanzierung nicht mehr darum kümmern muss.

Wenn Objekte zu einer bestimmten Zeit erstellt werden müssen, sollten Factories verwendet werden.

Systeme werden nicht von heute auf morgen gebaut. Sie werden nach und nach ausgebaut. Um sicherzustellen, dass dabei noch alles funktioniert, gibt es TDD, Refaktorisieren und Separation of Concerns.

12 Emergence

Viele Leute sagen, dass Kent Beck’s 4 “Rules of Simple Design” einem sehr helfen, gut designte Software zu erstellen.

Kent Beck sagt:
ein Design ist „simple“, wenn:

• alle Tests durchlaufen
• kein doppelter Code vorhanden ist
• wenn es die Absicht des Programmierers ausdrückt
• die Anzahl von Klassen und Methoden minimiert sind

in der Reihenfolge.

13 Concurrency

In Multithread-Anwendungen bekommt man schon bei minimaler Anforderung ein Problem mit der Komplexität. Da mit steigender Komplexität auch die Fehleranfälligkeit steigt, gibt es ein paar Prinzipien, die diese minimieren können:

Die Concurrency Defense Principles

• Single Responsibility Principle

Trenne multithreaded Code von nicht-multithreaded Code

• Limit the Scope of Data

Man sollte den Bereich, in dem multithreaded Code verwendet wird, möglichst klein halten.

• Use Copies of Data

Verschiedene Threads sollten nicht mit demselben Objekt arbeiten. Wenn möglich sollte mit Kopien von diesem Objekt gearbeitet werden.

• Independence

Threads sollten so unabhängig wie möglich sein

• Library

Natürlich sollte man die Bibliothek, die man für Multithread-Anwendungen verwendet, sehr gut kennen.

14 Successive Refinement

Um Clean Code schreiben zu können, muss man erst Dirty Code schreiben und ihn dann bereinigen.

Einer der besten Wege, ein Programm zu ruinieren, ist, massive Änderungen an der Struktur vorzunehmen, um das Programm zu verbessern. Um das zu verhindern, nutzt man die Disziplinen von TDD. Eines der zentralen Doktrinen dieses Ansatzes ist es, das System zu jeder Zeit lauffähig zu halten. Mit TDD ist es also nicht erlaubt eine Veränderung am System vorzunehmen, die das System bricht.

15 JUnit Internals

JUnit Internals halt… (Kapitel überlesen)

16 Refactoring SerialDate

War mir eindeutig zu Java-lastig… (Kapitel überlesen)

17 Smells and Heuristics

In diesem Kapitel zeigt Uncle Bob eine Liste von Smells und wie man sie beseitigen kann. Er lobt das Buch “Refactoring” von Martin Fowler. Dieses Buch steht eh schon ganz oben auf meiner To-do-Liste. Das werde ich also demnächst angehen.

Zusammenfassung

An dieser Stelle ein Dank an mein Entwicklerteam, dass ich das Buch so lange in Beschlag nehmen durfte (Teil 2 ging irgendwie zäher). Einen großen Dank auch an Peter Bucher und Rene Drescher-Hackel für ihre Ergänzungen bzw. Einwände. Man darf sicherlich nicht alles so ganz ernst nehmen und man kann es auch übertreiben (siehe Pyramiden etc.). Natürlich sollte man nicht blind durch die Welt laufen, sondern auch Dinge hinterfragen, aber man muss sagen, dass die Punkte von CCD (das ja auf diesem Buch beruht) durchaus plausibel sind. Ich denke schon, dass CCD unerfahrenen aber auch erfahrenen Entwicklern einen SOLIDen Weg zeigt, den man gehen kann und der sogar schon gepflastert ist. Man kann sich natürlich auch mit der Machete durch dichten Dschungel schlagen, was natürlich cool ist – aber halt wesentlich langsamer. Es sei denn man ist Chuck Norris.

Wikipedia definiert DbC folgendermaßen:

Design by contract (kurz DbC; englisch Entwurf gemäß Vertrag) oder Programming by Contract ist ein Konzept aus dem Bereich der Softwareentwicklung. Ziel ist das reibungslose Zusammenspiel einzelner Programmmodule durch die Definition formaler „Verträge“ zur Verwendung von Schnittstellen, die über deren statische Definition hinausgehen. Entwickelt und eingeführt wurde es von Bertrand Meyer mit der Entwicklung der Programmiersprache Eiffel.

Stefan Lieser hat über das neue Konzept einen sehr guten Artikel in www.visualstudio1.de geschrieben, mit Begriffsklärung und Anwendungsbeispiele. Kurz zusammengefasst ist die Rede von Folgendem: anstelle, dass man in jeder Methode auf not-null or not-empty usw. prüft, schreibt man die Erwartungen als Code hin. Diese werden von Tools wie z.B. Resharper erkannt und bei fehlerhaften Aufruf der Methode, wird der Entwickler gewarnt. Am besten finde ich, dass man den Kontrakt-Code z.B. für einen Interface in eine separate Klasse schreiben kann und diese wird durch Attribute (ContractClassFor) gefunden. Also wird dadurch der eigentliche Code nicht größer.

Das soll nicht bedeuten, dass der Entwickler der Methode die Verantwortung von sich schiebt , sondern dass er Bedingungen der “Nutzung” offenlegt, Informationen, die bisher nur durch das Anschauen des Codes oder durch mündliche/schriftliche Mitteilung möglich war. Mit Spec# kann man die Intention-Revealing Interfaces ganz genau schreiben: mit veröffentlichten und kompilierten Bedingungen.

Beim ALT.NET Open Spaces in Seattle wurde wieder eine sehr negative Session angesetzt, “Why so mean?”. Scott Hanselman stellt hier sehr provokant die Frage, warum die Community immer mehr Energie aufwendet um zu Kritisieren, anstatt die neuen Technologien positiv nach aussen zu tragen. Dies kann ich nach meinen jetzigen Erfahrungen beim .NET Open Spaces in Ulm nicht bestätigen. Bei uns habe ich keinerlei negative Energie gespürt.

Andererseits sehe ich es genauso wie Jeremy: Ansätze, die teilweise gegeneinander arbeiten. DDD widerspricht meiner Meinung nach oft den bisher genutzten Kapselungen. Was nun besser oder schlechter ist kann ich derzeit noch nicht sagen, dazu kenne ich selbst DDD zu wenig. Die Mehrheit der ALT.NET Community hat wohl noch nicht einen allgemeingültigen Weg zur Verfügung, der aus dem bisher eingebrachten Wissen entstanden ist.

Was wohl langfristig nötig ist, dass wir uns über den Grundgedanken von ALT.NET wieder bewusst werden. Der entstehende Code soll clean, korrekt und erweiterbar sein. Also eine auf den Code zentrierte Produktentwicklung. Der Weg mit CCD sehe ich damit als den Richtigen und CCD spricht auch gerade einen positiven Aspekt an.

Seht ihr ähnliche Tendenzen wie Jeremy in der deutschen Community?

Da es für einen Entwickler wichtig ist, sich ständig weiterzuentwickeln, sollte man sich durch Austausch mit anderen Entwicklern, aktives Programmieren oder eben Bücher weiterbilden. Das Buch, das ich gerade lese, heißt Clean Code von Robert C. Martin a.k.a. Uncle Bob. Ich bin momentan bei der Hälfte des Buches und muss sagen, dass ich von dem Buch ziemlich begeistert bin. Da ich denke, dass es vielen Entwicklern helfen würde, besseren Code zu schreiben, habe ich den Text ein wenig verkürzt und zusammengefasst – was natürlich nicht heißt, dass man dieses Buch nicht lesen muss. Meiner Meinung nach ist es absolute Pflichtlektüre für jeden Entwickler, der was auf sich hält.

Hier also meine kleine Zusammenfassung.

Kapitel 1 Clean Code

In diesem Kapitel wird beschrieben, was Clean Code ist und dass man „Clean Code“ schreiben muss, um sich selbst einen professionellen Softwareentwickler nennen zu dürfen. Was Clean Code ausmacht, hat Christina schon in ihrem Artikel „Clean Code Developer – The Yellow Brick Road of the Coder“ beschrieben. Außerdem wichtig sind :
LeBlanc’s Gesetz : Later equals never
und
die Boy Scout Rule : Leave the campground cleaner than you found it.

Kapitel 2 Meaningful Names

Benennung in einem Projekt ist sehr wichtig, sei es um das Gesuchte zu finden oder um den Sinn einer Variablen oder einer Methode ohne langes Überlegen zu erkennen. Man sollte bei der Vergabe von Namen so gründlich vorgehen, wie man es für seinen Erstgeborenen tun würde. In der heutigen Zeit ist die Ungarische Notation absoluter Quatsch. Die IDE kennt den Typ, warum sollte man das in den Variablennamen integrieren?

Kapitel 3 Funktionen

Die erste Regel von Funktionen lautet: Sie sollte klein sein.
Die zweite Regel von Funktionen lautet: Sie sollte noch kleiner sein als das.
Eine Funktion sollte nur eine Sache tun. Macht sie mehr als eine Sache, steigt die Komplexität. Und Komplexität ist schlecht.
Eine gute Benennung der Funktionen ist, wenn der Name beschreibt, was die Funktion macht. Dabei darf der Name ruhig lang sein, wenn es der Lesbarkeit des Codes dienlich ist.
Flagargumente sind verboten! Durch dieses Flag macht die Methode schon mehr als eine Sache und wir wären wieder bei der Sache mit der Komplexität. Böse.
Die ideale Anzahl von Parametern einer Funktion ist 0! Aber da nicht immer alles ideal laufen kann, sind 1, 2 auch okay. Aber mehr als 3 ist verboten. Okay?
Last but not least eine sehr wichtige Grundregel: Don’t Repeat Yourself!
Denn: Durch Verdopplung des Codes steigt der Wartungsaufwand proportional.

Kapitel 4 Kommentare

Kommentare sind schlecht, denn sie lügen! Ja, LÜGE! Code wird häufig verändert durch neue Anforderungen oder Refaktorisierungsmaßnahmen, der dazugehörige Kommentar aber meist nicht, wodurch schlechte bzw. in die Irre führende Kommentare entstehen. Es gilt also: Keine Kommentare sind besser als schlechte Kommentare. Man sollte die Zeit, die man für das Schreiben von Kommentaren aufbringen würde, lieber für die Refaktorierung der Methode verwenden. Denn Code sollte sich selbst erklären und ist außerdem die aktuellste Dokumentation. Nur schlechter Code muss kommentiert werden.
Auskommentieren des Codes ist verboten! Andere Programmierer, die den auskommentierten Code sehen, werden diesen nicht löschen, da sie denken, dass es einen Grund haben muss, dass er dort steht und dass er zu wichtig ist, um gelöscht zu werden. Somit bleibt dieser “Kommentar” auf ewig dort und müllt unseren “Clean Code” zu. Heutzutage muss man nichts mehr auskommentieren. Durch Versionskontrolle geht nichts mehr verloren.

Kapitel 5 Formatting

Eine perfekte Formatierung gibt es nicht, vielleicht für jeden Einzelnen, aber nicht für ein Team. Jeder hat seine Vorlieben. Letzendlich ist nur wichtig, dass sich das Team auf EINE Formatierung einigt. Jeder in diesem Team muss sich daran halten, auch wenn es für einen selbst nicht die optimale Lösung ist. Der Nutzen einer gemeinsamen „Sprache“ ist einfach zu groß, denn Kommunikation ist das A und O.

Kapitel 6 Objects and Data Structures

Es wird grundsätzlich zwischen Objekten und Data Structures unterschieden.
Objekte enthalten Businesslogik und sollten ihre interne Struktur nach außen hin verbergen, also keine Properties, welche die Member-Variablen des Objekts zurückgeben oder verändern lassen. Nur das Objekt selbst sollte seinen internen Status ändern können, wobei bei Objekten auf das Gesetz von Demeter zu achten ist:
Es besagt, dass Objekte nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren sollen.
Also:
Methode m der Klasse k sollte nur Methoden nutzen von:

• k
• Ein Objekt, dass von m erstellt wurde
• Ein Übergabeparameter an m
• Ein Memberobjekt von k

Data Structures sind zum Beispiel Data Transfer Objects, kurz DTOs. Das sind Klassen ohne Methoden, also reine Datenträger. Eine spezielle Form von DTOs sind Active Records. Diese Objekte haben Methoden wie Save() und Find(), enthalten jedoch keine Businesslogik.

Kapitel 7 Error Handling

Moderne Programmiersprachen haben ein Feature namens Exceptions. Das sollte man auch nutzen. Fehlercodes oder ähnliches sind veraltet. Eine gute Exception sollte allerdings so viel Information liefern, dass man auch ohne Debuggen den Fehler identifizieren kann, sonst kann man sich die ganze Mühe auch sparen.
Außerdem noch 2 wichtige Grundregeln:
Don’t Return null – somit wird es unnötig auf null zu prüfen
und
Don’t Pass null – null an eine Methode zu übergeben ist noch schlimmer als null zu returnen

Kapitel 8 Boundaries

Man sollte unbedingt das Adapterpattern anwenden, wenn man 3rd party Code verwendet. 3rd party code sollte an so wenig stellen wie möglich verwendet werden, um Abhängigkeiten zu vermeiden.

Kapitel 9 Unit Tests

Die 3 Gesetze von TDD:

1. Man darf keinen produktiven Code schreiben, solange man keinen fehlgeschlagenen Unit Test geschrieben hat.
2. Man darf nicht mehr als nötig schreiben, um einen Unit Test fehlschlagen zu lassen, und Fehler beim Kompilieren bedeutet einen fehlgeschlagenen Test.
3. Man darf nicht mehr produktiven Code als nötig schreiben, um einen fehlgeschlagenen Test zu reparieren.

Außerdem gilt: Tests sollten genauso “Clean Code” sein wie produktiver Code. Tests sollten genauso evolvierbar sein. Denn wenn sich der Code verändert, muss sich der Test auch verändern.
Ein Test sollte nur ein Szenario abdecken – wieder das Thema Komplexität.

Clean Tests folgen noch 5 anderen Regeln:
Fast
Independent
Repeatable
Self Validating
Timely

Teil 2 gibt es hier

]]> http://blog.aztec-project.org/2009/08/11/clean-code-teil-1/feed/ 4 http://blog.aztec-project.org/2009/07/14/clean-code-developing/ http://blog.aztec-project.org/2009/07/14/clean-code-developing/#comments Tue, 14 Jul 2009 13:14:46 +0000 Christina Hirth http://blog.aztec-project.org/?p=455 Seit dem ich Code schreibe, steht für mich ein klarer und verständlicher Code an oberster Stelle. Ich hatte dann vor ca. eineinhalb Jahren Code Complete und The Pragmatic Programmer gelesen und dadurch die ersten Antworten bekommen, WIE man den Code unter Kontrolle hält. Anfang 2009 sind wir – ich und Stefan – durch den Podcast von Hanselman und Uncle Bob auf das Thema SOLID gestoßen – und darüber auch eine ausgiebige Diskussion geführt. Eins war uns klar: die Ideen, die dahinter stecken, könnten die Antwort auf unsere Suche sein.

Deshalb hat mich sehr gefreut, als ich von der Seite Clean Code Developer erfahren habe. Ihr Inhalt hat mich sofort begeistert. Sie beschreibt einen – wahrscheinlich DEN – möglichen Weg um ein professioneller Softwareentwickler zu werden.

Am letzten Wochenende auf dem .NET Open-Space-Süd habe ich das große Vergnügen gehabt, Stefan Lieser, einen der Gründer von Clean Code Developer-Seite kennen zu lernen und so konnte ich in den 2 Tagen viel über den Weg von einem Creepy-Code-Programmer zu einem Clean-Code-Programmer erfahren.

Die Grundidee ist ganz einfach: genauso wie ein Arzt oder ein Architekt, muss auch ein professioneller Softwareentwickler Verantwortung für seine Arbeit und für die Ergebnisse dieser Arbeit übernehmen. Er/sie muss sicherstellen, dass der Code korrekt, evolvierbar und effizient ist und dass er selbst immer sein Bestes gibt. Damit ist nicht gemeint, dass jeder ein Guru sein muss. Nein, professioneller Softwareentwickler ist derjenige, der an einem Wertesystem festhält und immer die Qualität des Codes vor den Augen hat.

Viele werden sagen “Wozu die Mühe, es funktioniert auch so!”. Klar, wenn man nur für den Jetzt programmiert. Dann, nach kurzer Zeit passiert das unvermeidliche: jemand – oder der Entwickler selbst – muss den furchterregend schlechten Code bugfixen/verändern. All diese Entwickler, die solche Aufgaben hatten, werden Tests zu schätzen wissen. Diese Tests kosten zwar etwas Mühe aber bescheren einem einen ruhigen Schlaf.

Zu einem genauso großen Problem führt, wenn man das elementarste aller Prinzipien nicht respektiert: Don’t-Repeat-Yourself (DRY). Wie oft passiert, dass man eine Methode, ein Verhalten anpassen muss und überall nach verstreuten Kopien vom Code suchen muss? Könnt ihr jedes Mal garantieren, dass ihr alle erwischt habt? Das wäre keine Frage, wenn der Entwickler des Codes das DRY-Prinzip respektiert.

Der Code, den ein Entwickler schreibt, gehört meistens nicht ihm. Ich bin sicher, keiner von uns möchte als “Creepy-Coder” beschimpft werden, wenn jemand anderer unserer Code verstehen oder weiterentwickeln muss.

Nimmt eure Arbeit ernst und werdet ein professioneller Entwickler. Ihr werdet nach kürzester Zeit die Freude an einem korrekten und qualitativen Code entdecken und auch eure Teamkollegen und Chefs werden dafür dankbar sein.

Dabei geht es weder darum neue Technologien zu verwenden, noch darum neue Sprachen zu erlernen. Eigentlich ist es eher ein kleiner Leitfaden um sich stetig zu verbessern, und das wollen wir doch im Allgemeinen eh, sonst würde dieser Blog-Eintrag wohl auch nicht gelesen.