Clean Code Developer CCD Software professionell entwickeln Erste

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

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 22. 05. 2009 Ralf Schoch 2

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 22. 05. 2009 Ralf Schoch 3

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. 22. 05. 2009 Ralf Schoch 4

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) 22. 05. 2009 Ralf Schoch 5

Clean Code Developer Grade der CCD 0. Grad – Schwarz Den 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. 22. 05. 2009 Ralf Schoch 8

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-tohave Eigenschaft von Code, sondern um seine Essenz. 22. 05. 2009 Ralf Schoch 9

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. 22. 05. 2009 Ralf Schoch 10

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 Kundenanforderungen. 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. 22. 05. 2009 Ralf Schoch 11

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 Softwareentwicklung insgesamt auch ein passendes Vorgehensmodell. Das ist iterativ und soll während der Arbeit am blauen Grad nun auch eingeübt werden. 22. 05. 2009 Ralf Schoch 12

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 Ccd. Wertesystem 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. 22. 05. 2009 Ralf Schoch 13

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. 22. 05. 2009 Ralf Schoch 14

Clean Code Developer Grade der CCD Bedeutung der Grade Auch wenn wir verstehen, dass jeder, der das Ccd. Wertesystem 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. 22. 05. 2009 Ralf Schoch 15

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 22. 05. 2009 Ralf Schoch 16

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 cause analysis (Ursachenanalyse) • Praktiken • Ein Versionskontrollsystem benutzen • Erste Refaktorisierungsmuster anwenden • Täglich reflektieren 22. 05. 2009 Ralf Schoch 17

Clean Code Developer 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 22. 05. 2009 Ralf Schoch 18

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 22. 05. 2009 Ralf Schoch 19

Clean Code Developer 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. 22. 05. 2009 Ralf Schoch 20

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) 22. 05. 2009 Ralf Schoch 21

Clean Code Developer 1. Grad der CCD - Regeln Ursachenforschung • • • Sympthome behandeln bringt oft schnelle Lösung. Behebt aber nicht das Problem immer nach der wahren Wurzel des Übels suchen. Aufwand bei Sympthomebehandlung oft höher. Ursachenforschung ist Dienst an Verständlichkeit und Aufwand. 22. 05. 2009 Ralf Schoch 22

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 Angstfreiheit ist Voraussetzung für Änderungen. Zeitmaschine für Code Basis für Lernen aus Fehlern Mit Versionsverwaltung darf man Fehler machen! Sie können jederzeit wieder rückgängig gemacht werden. 22. 05. 2009 Ralf Schoch 23

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

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 • • • 22. 05. 2009 Ralf Schoch 25

Clean Code Developer Aus der Praxis … Praxis 22. 05. 2009 Ralf Schoch 26

Clean Code Developer Aus der Praxis: Aussagekräftige Namen Beispiel: int d; // elapsed time in days Bessere Lösung: int int elapsed. Time. In. Days; days. Since. Creation; days. Since. Modification; file. Age. In. Days; 22. 05. 2009 Ralf Schoch 27

Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Fehlinformationen vermeiden Beispiel: account. List Eine Liste hat für einen Entwickler eine spezielle Bedeutung. account. List muss aber nicht zwingend eine Liste im Sinn von Progarmmierung sein. Bessere Lösung: account. Group; bunch. Of. Accounts 22. 05. 2009 Ralf Schoch 28

Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Fehlinformationen vermeiden Beispiel: int a = l; if (O == l) a = O 1; else l = 01; Kleine “L” und grosses “o” sind keine sinnvollen Variablennamen. Führen leicht zu Verwechslungen mit 1 und 0. 22. 05. 2009 Ralf Schoch 29

Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Namen ohne Aussagekraft Beispiel: Public void copychars( char a 1[], char a 2[]){ for (int i=0; i<a 1. length; i++){ a 2[i] = a 1[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 Ralf Schoch 30

Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Bedeutungslose Namen Beispiel: class Product; class Product. Info; class Product. Data; 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. 22. 05. 2009 Ralf Schoch 31

Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Bedeutungslose Namen Beispiel: Customer; Customer. Object; Name. String; Zusätze wie “Object” oder “String” sind in bestimmten Programmiersprachen (z. B. Java, C#) nicht sinnvoll. 22. 05. 2009 Ralf Schoch 32

Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Sprechbare Namen Beispiel: class Dta. Rcrd 102 { private Date genymdhms; private Date modymdhms; private final String pszyint = “ 102”; } Bessere Lösung: class Customer { private Date generation. Time. Stamp; private Date modification. Time. Stamp; private final String record. ID = “ 102”; } 22. 05. 2009 Ralf Schoch 33

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 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. 22. 05. 2009 Ralf Schoch 34

Clean Code Developer Aus der Praxis: Aussagekräftige Namen – Suchbare Namen Bessere Lösung: int real. Days. Per. Ideal. Day = 4; const int WORK_DAYS_PER_WEEK = 5; int sum = 0; for (int j=0; j<NUMBER_OF_TASKS; j++){ int real. Task. Days = Tasks. Estimate[j]*real. Days. Per. Ideal. Day; int real. Task. Weeks = (realdays / WORK_DAYS_PER_WEEK) ; sum += real. Task. Weeks; } Es ist einfacher nach WORK_DAYS_PER_WEEK zu suchen. 22. 05. 2009 Ralf Schoch 35

Clean Code Developer Etwas Praxis … Sinnvoller Context • Demo „Variables. With. Clear. Contect. cs“ • Beispiel aus „Clean Code“ auf C# adaptiert 22. 05. 2009 Ralf Schoch 36

Clean Code Developer Literatur • Clean Code (eng), Robert C. Martin ISBN 0132350882 • Clean Code (ger), Robert C. Martin ISBN 3826655486 • Refactoring to Patterns, Joshua Kerievsky ISBN 3827322626 22. 05. 2009 Ralf Schoch 37

Clean Code Developer Links • Clean Code Developer http: //clean-code-developer. de/ • CCD Grade http: //clean-code-developer. de/wiki/Ccd. Grade • Tools http: //clean-code-developer. de/wiki/Ccd. Werkzeugliste • Ralf Westphal http: //ralfw. de • Stephan Lieser http: //www. lieser-online. de 22. 05. 2009 Ralf Schoch 38

Clean Code Developer Fragen 22. 05. 2009 Ralf Schoch 39