Clean Code Developer Clean Code Developer (CCD) Software professionell entwickeln Erste Schritte... 22.05.20091Ralf Schoch

Clean Code Developer

Clean Code Developer (CCD)Software professionell entwickeln

Erste Schritte ...

22.05.2009 1Ralf Schoch


Agenda

Clean Code Developer (CCD)

• Woher kommt CCD?• Was ist die Idee von CCD?• Was sind die CCD Grade?• 1. Grad – Rot • Literatur• Links



Woher kommt Clean Code Developer?

Die Verursacher

• Ralf Westphal • Autor: Bücher und Artikel im .NET Umfeld• Sprecher bei Entwicklerveranstaltungen• Workshops• .NET TV

• Stephan Lieser• .NET User Group Bonn• Autor: Artikel im .NET Umfeld



Woher kommt Clean Code Developer?

Das Buch „Clean Code“ von „Robert C. Martin“.

• Lernen Sie, guten Code von schlechtem zu unterscheiden. • Sauberen Code schreiben und schlechten Code

in guten umwandeln. • Aussagekräftige Namen sowie gute Funktionen,

Objekte und Klassen erstellen. • Code so formatieren, strukturieren und kommentieren,

dass er bestmöglich lesbar ist. • Ein vollständiges Fehler-Handling implementieren,

ohne die Logik des Codes zu verschleiern. • Unit-Tests schreiben und Ihren Code

testgesteuert entwickeln.



Was ist die Idee von CCD?

Die Idee

• Professionalität = Bewusstheit + Prinzipien• Softwareentwicklung braucht Profis!• Was sind Profis?

• Ein professioneller Softwareentwickler setzt sich mit dem Metier bewusst auseinander.

• Ein professioneller Softwareentwickler hat ein inneres Wertesystem.

• Qualitätsmaßstab oder zumindest einen Erwartungshorizont für Professionalität

• Kriterien (Software Team, Diplom)



Grade der CCD

0. Grad – SchwarzDen schwarze Grad hat jeder, der sich noch nicht auf den Weg gemacht hat. Ein schwarzes Armband signalisiert deshalb nur, dass man sich für CCD interessiert. Man kann es tragen, wenn für den ersten richtigen Grad noch nicht alle Voraussetzungen erfüllt sind.

1. Grad – RotDer wirkliche Weg zum Clean Code Developer beginnt mit dem roten Grad.

Mit dem roten Grad setzt die Übungspraxis ein. Er enthält deshalb nur Elemente des CCD-Wertesystems, die absolut unverzichtbar sind. Der Einstieg soll so leicht wie möglich sein. Auf dieser Stufe geht es deshalb noch nicht so sehr um Softwareentwicklungsprinzipien, als vielmehr um den Aufbau einer fundamentalen Haltung zur Softwareentwicklung und zum Clean Code Developer.



Grade der CCD

2. Grad – Orange

Nachdem im roten Grad die Grundlagen für den Prozess der kontinuierlichen Verbesserung geschaffen wurden, geht es im orangen Grad darum, einige fundamentale Prinzipien auf den Code anzuwenden und erste Erfahrungen mit dem Mittel Nr. 1 zur Produktivitätssteigerung zu gewinnen: der Automatisierung von Abläufen. Da nur korrekter Code guter Code ist, dient die Automatisierung der Korrektheitsprüfung. Es geht also nicht um eine nice-to-have Eigenschaft von Code, sondern um seine Essenz.



Grade der CCD

3. Grad – Gelb

Der gelbe Grad steht ganz im Zeichen automatisierter Tests. Beim orangen Grad ging es noch um die von außen ansetzbaren Integrationstests. Für sie war nicht unbedingt ein Eingriff in den Code nötig. Ab dem gelben Grad allerdings geht es nicht mehr ohne Tests unter der Oberfläche. Und nicht nur das: getestet werden sollen die kleinstmöglichen Einheiten, nicht nur funktionale Durchstiche. Das bedeutet ein Änderung der Codierungspraxis, denn sonst lassen sich einzelne Klassen nicht isoliert, d.h. unabhängig von genutzten Diensten prüfen. Deshalb gehören zum gelben Grad auch objektorientierte Prinzipien, denn nur mit ihnen ist eine Ablösung von zu testendem Code von seinem "Untergrund" möglich.



Grade der CCD

4. Grad – Grün

Im grünen Grad geht es weiter mit der Automatisierung. Die ist einfach der Schlüssel zur Produktivität und Reaktionsfähigkeit. Nur wenn maximal viele Tätigkeiten in der Softwareentwicklung automatisiert sind, kann sich der CCD auf das Wesentliche konzentrieren: die Implementation von Kundenanforder-ungen. Ohne Automatisierung hängt die Entwicklung sonst oft an Kleinigkeiten - das kostet Zeit. Korrektheitsprüfungen und Releases sind dann mehr Strafe denn Mittel zum Erfolg. Nach der Automatisierung der Tests steht jetzt allerdings die Produktion auf dem Plan. Code am Entwicklerarbeits-platz zu testen, ist eine Sache. Ihn auf einem unabhängigen Rechner erfolg-reich zu übersetzen und zu testen, eine andere. Nur so lassen sich mehr oder weniger subtile Abhängigkeiten von den einzelnen Entwicklerarbeitsplätzen finden. Garniert wird diese Praxis dann noch mit weiteren Prinzipien zur Codestrukturierung und einem Werkzeug für bessere Architekturen.



Grade der CCD

5. Grad – Blau

Mit dem blauen Grad geht es in die Zielgerade des CCD-Wertesystems. Die Automatisierung ist noch einen Schritt weiter zu treiben. Nach Übersetzung und Test steht jetzt das Deployment auf dem Programm. Vor allem geht es im blauen Grad aber nun um Aspekte der Softwareentwicklung jenseits von Code und Tools: CCD kümmern sich nicht nur um gute Strukturen im Kleinen, sondern planen sie von vornherein im Großen. Es geht also um Architektur. Da wir uns jedoch bewusst sind, dass keine Planung eine perfekte Lösung definieren kann, gehört nicht nur zur Architektur, sondern zur Software-entwicklung insgesamt auch ein passendes Vorgehensmodell. Das ist iterativ und soll während der Arbeit am blauen Grad nun auch eingeübt werden.



Grade der CCD

6. Grad – Weiß

Im weißen Grad fließen alle Prinzipien, Regeln und Praktiken zusammen. So wie im weißen Licht alle Farben enthalten sind, so enthält der weiße Grad alle anderen Grade. Auf der Ebene des weißen Grades arbeitet ein CCD nur, wenn er ständig das ganze CcdWertesystem im Blick hat. Das macht klar, dass nur wirklich fortgeschrittene Softwareentwickler mit mehreren Jahren Erfahrung und in einer geeigneten Umgebung mit dem weißen Grad arbeiten können.



Grade der CCD

Bedeutung der Grade

Die Grade drücken keinen Wert aus. Wer am blauen Grad arbeitet ist nicht "besser" oder "weiter" als jemand, der am orangen Grad arbeitet. Die Grade sind nur ein didaktisches Hilfsmittel, um die Gesamtheit des Wertesystems "einfacher verdaubar" zu machen. Die vielen Werte lassen sich schlicht in kleinen Happen besser aneignen, als in einem Anlauf.

Deshalb ist es uns auch wichtig, dass jeder Interessent mit dem roten Grad beginnt. Aus didaktischen Gründen ist es der beste Einstieg - auch wenn man meint, man würde doch auch schon in der täglichen Arbeit andere Werte umsetzen. Denn unabhängig von der heutigen Projektpraxis ist es sicherlich neu, sich so bewusst mit Werten auseinanderzusetzen. Insbesondere die tägliche Reflektion darüber ist wahrscheinlich noch nicht Gewohnheit. Um sie im Kontext "einfacher" Werte zu üben, eignet sich dann der rote Grad.



Grade der CCD

Bedeutung der Grade

Auch wenn wir verstehen, dass jeder, der das CcdWertesystem zum ersten Mal sieht, abhaken will, was er davon schon beherzigt, so ist das letztlich unerheblich. Die bewusste Praxis im Rahmen des Wertesystems ist immer neu - und sollte auch wer meint, er "verdiene" eigentlich den weißen Grad, beim roten Grad beginnen. Es geht eben nicht um "Verdienst", sondern um Iterationen und kleine Happen. Grade sind Gucklöcher auf das große Ganze.

Wer das erste Armband bestellt, bestelle also am besten das rote Armband.



Grade der CCD – Die Armbänder

Bedeutung der Armbänder

• Arbeitsmittel• Täglich Reflektion• Verstoß gegen Prinzip des Grades oder vorhergehende• Ziel

• Bewusstes Handeln• Wahrnehmung



1. Grad der CCD

Roter Grad

• Prinzipien• Don‘t Repeat Yourself (DRY)• Keep it simple, stupid (KISS)

• Regeln• Die Pfadfinderregel beachten• Vorsicht vor Optimierungen!• Root cause analysis (Ursachenanalyse)

• Praktiken• Ein Versionskontrollsystem benutzen• Erste Refaktorisierungsmuster anwenden• Täglich reflektieren



1. Grad der CCD - Prinzipien

DRY – Don‘t repeat your self

• Erstes Prinzip: Nicht wiederholen• Inkonsistenzen & Fehler werden vermieden• Unterprogramme, Klassen, Methoden etc.• Kein Paste & Copy• Immer beachten• Wiederholungen von sich und anderen erkennen• Bereinigung von Wiederholungen durch Refactoring



1. Grad der CCD - Prinzipien

KISS – Keep it simple, stupid

• Verständlichkeit des Codes• Voraussetzung für Evoluierbarkeit• Alarm! Wenn man eigenen Code nicht mehr versteht!• Andere Entwickler müssen den Code verstehen.• Fehleranfälligkeit bei komplexen Lösungen höher• Reviews & Pair Programming



1. Grad der CCD - Regeln

Pfadfinderregel

• „Hinterlasse einen Ort immer in einem besseren Zustand als Du ihn vorgefunden hast.“

• Vermeidet „Broken Window“ Phänomen• CCD geht nicht von einem Tag auf den anderen• Schritt für Schritt• Bsp.:• Code ausserhalb VV wird eingecheckt• Wiederholungen werden entfernt.




Vorsicht vor Optimierung

• Warum? Es funktioniert doch!• Optimieren ist eine Veränderung an der Funktion oder am

Prozess. • Optimieren kostet immer Aufwand.• Ziel ist Verständlichkeit und Evolierbarkeit des Codes. • Meist Widerspruch zu optimiertem Code!• Muss guten Grund für Optimierung geben: Kundenwunsch!• Optimierung nur nach detaillierter Analyse. (Profiler)




Ursachenforschung

• Sympthome behandeln bringt oft schnelle Lösung.• Behebt aber nicht das Problem.• Problem immer nach der wahren Wurzel des Übels suchen.• Aufwand bei Sympthomebehandlung oft höher.• Ursachenforschung ist Dienst an Verständlichkeit und

Aufwand.



1. Grad der CCD - Praktiken

Versionskontrollsystem

• Warum? „Never Touch a Running System“.• Angst davor ein laufendes System zu beschädigen.• Versionsverwaltung befreit von Angst.• Angstfreiheit ist Voraussetzung für Änderungen.• Zeitmaschine für Code• Basis für Lernen• Lernen aus Fehlern• Mit Versionsverwaltung darf man Fehler machen!• Sie können jederzeit wieder rückgängig gemacht werden.




Refactoringmuster

• Einfache Muster• Methoden extrahieren (DRY)• Methode umbenennen (Pfadfinderregel)

• Pflichtlektüre: Clean Code




Täglich reflektieren

• Warum: Keine Verbesserung, keine Lernen ohne Reflektion• Einplanen in Tagesprozess• Kleinschrittige Planung („Teile & Herrsche“)• Reflexion nach jedem Schritt• Tagesplanung für Entwickler („Scrum“)• Keine Arbeit mit in den Feierabend nehmen• Reflektion, ob alle Schritte des Grades eingehalten wurden• Bei Verstoß nachbessern od. Aufgabe für den nächsten Tag• Wird beides nicht gemacht:

Wechsel des Armbands auf den anderen Arm!• 21 Tage kein Wechsel, dann nächstes Armband



Aus der Praxis …

Praxis



Aus der Praxis: Aussagekräftige Namen

Beispiel:

int d; // elapsed time in days

Bessere Lösung:

int elapsedTimeInDays;int daysSinceCreation;int daysSinceModification;int fileAgeInDays;



Aus der Praxis: Aussagekräftige Namen – Fehlinformationen vermeiden

Beispiel:

accountList

Eine Liste hat für einen Entwickler eine spezielle Bedeutung. accountList muss aber nicht zwingend eine Liste im Sinn von Progarmmierung sein.

Bessere Lösung:

accountGroup;bunchOfAccountsAccounts



Aus der Praxis: Aussagekräftige Namen – Fehlinformationen vermeiden

Beispiel:

int a = l;if (O == l)

a = O1;else

l = 01;

Kleine “L” und grosses “o” sind keine sinnvollen Variablennamen. Führen leicht zu Verwechslungen mit 1 und 0.



Aus der Praxis: Aussagekräftige Namen – Namen ohne Aussagekraft

Beispiel:

Public void copychars( char a1[], char a2[]){for (int i=0; i<a1.length; i++){

a2[i] = a1[i];}

} Bessere Lösung:

Public void copychars( char source[], char destination[]){

for (int i=0; i<source.length; i++){destination[i] = source[i];

}}22.05.2009 30Ralf Schoch


Aus der Praxis: Aussagekräftige Namen – Bedeutungslose Namen

Beispiel:

class Product;class ProductInfo;class ProductData;

Zusätze wie “Info” oder “Data” sind ziemlich nichts sagend bzw. Redundant. Solche Zusätze besser weg lassen.

Das gleiche gilt für Prefixe wie a, an, the. Ausnahme ist, wenn diesen eine Bedeutung zugeordnet ist. z.B. Alle lokalen Variablen fangen mit a an, alle functions Parameter mit the.



Aus der Praxis: Aussagekräftige Namen – Bedeutungslose Namen

Beispiel:

Customer;CustomerObject;Name;NameString;

Zusätze wie “Object” oder “String” sind in bestimmten Programmiersprachen (z.B. Java, C#) nicht sinnvoll.



Aus der Praxis: Aussagekräftige Namen – Sprechbare Namen

Beispiel:

class DtaRcrd102 {private Date genymdhms;private Date modymdhms;private final String pszyint = “102”;

}

Bessere Lösung:

class Customer {private Date generationTimeStamp;private Date modificationTimeStamp;private final String recordID = “102”;

}22.05.2009 33Ralf Schoch


Aus der Praxis: Aussagekräftige Namen – Suchbare Namen

Beispiel:

for (int j=0; j<34; j++) {S += (t[j]*4/5)

}

Es ist nicht möglich nach den obigen Variablen zu suchen! Bei der Suche nach “5” werden alle vorkommen von 5 gefunden. Hier wären sprechende Namen besser um bei Änderungen gezielt danach Suchen zu können.



Aus der Praxis: Aussagekräftige Namen – Suchbare Namen

Bessere Lösung:

int realDaysPerIdealDay = 4;const int WORK_DAYS_PER_WEEK = 5;int sum = 0;for (int j=0; j<NUMBER_OF_TASKS; j++){

int realTaskDays =

TasksEstimate[j]*realDaysPerIdealDay;int realTaskWeeks =

(realdays / WORK_DAYS_PER_WEEK) ;

sum += realTaskWeeks;}

Es ist einfacher nach WORK_DAYS_PER_WEEK zu suchen. 22.05.2009 35Ralf Schoch


Etwas Praxis …

Sinnvoller Context

• Demo „VariablesWithClearContect.cs“• Beispiel aus „Clean Code“ auf C# adaptiert



Literatur

• Clean Code (eng), Robert C. MartinISBN 0132350882

• Clean Code (ger), Robert C. MartinISBN 3826655486

• Refactoring to Patterns, Joshua Kerievsky ISBN 3827322626



Links

• Clean Code Developerhttp://clean-code-developer.de/

• CCD Gradehttp://clean-code-developer.de/wiki/CcdGrade

• Toolshttp://clean-code-developer.de/wiki/CcdWerkzeugliste

• Ralf Westphalhttp://ralfw.de

• Stephan Lieserhttp://www.lieser-online.de



Fragen


Documents

Clean Code Developer Clean Code Developer (CCD) Software professionell entwickeln Erste Schritte... 22.05.20091Ralf Schoch