Clean Code Developer

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

2. Ralf Schoch Clean Code Developer Agenda • Clean Code Developer (CCD) • Woher kommt CCD? • Was ist die Idee von CCD? • Was sind die CCD Grade? • 1. Grad – Rot • Literatur • Links

3. Ralf Schoch Clean Code Developer 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

4. Ralf Schoch Clean Code Developer 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.

5. Ralf Schoch Clean Code Developer 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)

6. Ralf Schoch Clean Code Developer 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 – Rot • Der 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.

7. Ralf Schoch 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.

8. Ralf Schoch Clean Code Developer 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.

9. Ralf Schoch Clean Code Developer 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.

10. Ralf Schoch Clean Code Developer 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.

11. Ralf Schoch Clean Code Developer 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.

12. Ralf Schoch Clean Code Developer 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.

13. Ralf Schoch Clean Code Developer 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.

14. Ralf Schoch Clean Code Developer 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

15. Ralf Schoch Clean Code Developer 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 causeanalysis (Ursachenanalyse) • Praktiken • Ein Versionskontrollsystem benutzen • Erste Refaktorisierungsmuster anwenden • Täglich reflektieren

16. Ralf Schoch Clean Code Developer 1. Grad der CCD - Prinzipien • DRY – Don‘trepeatyourself • 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

17. Ralf Schoch Clean Code Developer 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

18. Ralf Schoch Clean Code Developer 1. Grad der CCD - Regeln • Pfadfinderregel • „Hinterlasse einen Ort immer in einem besseren Zustand als Du ihn vorgefunden hast.“ • Vermeidet „BrokenWindow“ Phänomen • CCD geht nicht von einem Tag auf den anderen • Schritt für Schritt • Bsp.: • Code ausserhalb VV wird eingecheckt • Wiederholungen werden entfernt.

19. Ralf Schoch Clean Code Developer 1. Grad der CCD - Regeln • 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)

20. Ralf Schoch Clean Code Developer 1. Grad der CCD - Regeln • 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.

21. Ralf Schoch Clean Code Developer 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.

22. Ralf Schoch Clean Code Developer 1. Grad der CCD - Praktiken • Refactoringmuster • Einfache Muster • Methoden extrahieren (DRY) • Methode umbenennen (Pfadfinderregel) • Pflichtlektüre: Clean Code

23. Ralf Schoch Clean Code Developer 1. Grad der CCD - Praktiken • 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

24. Ralf Schoch Clean Code Developer Aus der Praxis … Praxis

25. Ralf Schoch Clean Code Developer Aus der Praxis: Aussagekräftige Namen • Beispiel: • int d; // elapsed time in days • Bessere Lösung: • intelapsedTimeInDays; • intdaysSinceCreation; • intdaysSinceModification; • intfileAgeInDays;

26. Ralf Schoch Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Fehlinformationen vermeiden • Beispiel: • accountList • EineListe hat füreinenEntwicklereinespezielleBedeutung. accountList muss abernichtzwingendeineListeim Sinn von Progarmmierungsein. • Bessere Lösung: • accountGroup; • bunchOfAccounts • Accounts

27. Ralf Schoch Clean Code Developer 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” sindkeinesinnvollenVariablennamen. FührenleichtzuVerwechslungenmit 1 und 0.

28. Ralf Schoch Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Namen ohne Aussagekraft • Beispiel: • Public void copychars( char a1[], char a2[]){ for (inti=0; i<a1.length; i++){ a2[i] = a1[i]; }} • Bessere Lösung: • Public void copychars( char source[], char destination[]){ for (inti=0; i<source.length; i++){ destination[i] = source[i]; }}

29. Ralf Schoch Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Bedeutungslose Namen • Beispiel: • class Product;class ProductInfo;class ProductData; • Zusätzewie “Info” oder “Data” sindziemlichnichtssagendbzw. Redundant. SolcheZusätzebesserweglassen. • Das gleiche gilt fürPrefixewiea, an, the. Ausnahmeist, wenndieseneineBedeutungzugeordnetist. z.B. AllelokalenVariablenfangenmita an, alle functions Parameter mitthe.

30. Ralf Schoch Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Bedeutungslose Namen • Beispiel: • Customer;CustomerObject;Name;NameString; • Zusätzewie “Object” oder “String” sind in bestimmtenProgrammiersprachen (z.B. Java, C#) nichtsinnvoll.

31. Ralf Schoch Clean Code Developer 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”;}

32. Ralf Schoch Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Suchbare Namen • Beispiel: • for (int j=0; j<34; j++) { S += (t[j]*4/5)} • Es istnichtmöglichnach den obigenVariablenzusuchen! BeiderSuchenach “5” werdenallevorkommen von 5 gefunden. Hier wären sprechende Namen besser um bei Änderungen gezielt danach Suchen zu können.

33. Ralf Schoch Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Suchbare Namen • Bessere Lösung: • intrealDaysPerIdealDay = 4;const int WORK_DAYS_PER_WEEK = 5;int sum = 0;for (int j=0; j<NUMBER_OF_TASKS; j++){ intrealTaskDays = TasksEstimate[j]*realDaysPerIdealDay;intrealTaskWeeks = (realdays / WORK_DAYS_PER_WEEK) ; sum += realTaskWeeks;} • Es ist einfacher nach WORK_DAYS_PER_WEEK zu suchen.

34. Ralf Schoch Clean Code Developer Etwas Praxis … • Sinnvoller Context • Demo „VariablesWithClearContect.cs“ • Beispiel aus „Clean Code“ auf C# adaptiert

35. Ralf Schoch Clean Code Developer Literatur • Clean Code (eng), Robert C. MartinISBN 0132350882 • Clean Code (ger), Robert C. MartinISBN 3826655486 • Refactoringto Patterns, Joshua KerievskyISBN 3827322626

36. Ralf Schoch Clean Code Developer 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

37. Ralf Schoch Clean Code Developer Fragen