Embed Size (px)
Citation preview
Wie Clean Code zum Teamsport wird
Von der Vision zur Mission
Hi
Halina[Senior Software Entwickler ]
Clean Code Team ?
Was ist eigentlich Clean Code?
Ist das nicht subjektiv?
“simple to readand
painless to maintain“
lesbar
verständlich
wartbar
testbar
Was sagen Entwickler?
Batman: “- SoC
- KISS- YAGNI- SLA- SRP- DEMETER- DRY- Test first- IOSP- ISP- Evolvierbarkeit- FCoI- Root Cause Analysis- Dependency Inversion Principle- SOLID- Information Hiding Principle- Liskov- boy scout rule
… *lufthol* …
Alfred: „Schöne Variablennamen... … und, ähm, Tests.
Ja, Testabdeckung! “
Robin: “ Hmmm, gleiche Einrückung?
… Also Leerzeilen und Umbrüche sowas?“
Was verstehst Du unter Clean Code?
Woher kommen die unterschiedlichen Sichten
auf Clean Code?
individuelles Fachwissen&
individuelle Erfahrung
Dreyfus Model
Brüder Stuart und Hubert Dreyfus, 1980
Novice braucht Regeln
Advanced Beginner testet Regeln
Competent wendet Regeln an
Proficient greift auf Regeln zurück
Expert weit über Regeln hinaus
Dreyfus Model5 levels of skill aquisition
Dan North, GOTO 2017
Woran jetzt jeder denkt:
Moment !
Hier geht es um einzelne Fähigkeiten
Robin
C Ruby
Java PHP
JS C++
Dreyfus Squared
NoviceAdvancedBeginner
Competent Proficient Expert
Novice
AdvancedBeginner
Competent
Proficient
Expert
Dan North, GOTO 2017
o Onboardings / Einführungen
o Trainings / Workshops
o Diskussionen / Meetings
o Fragen / Antworten
o Code Reviews
o Teamzusammenstellung / Pairings
Berücksichtigen bei
Ok.Also je nach Level geht jeder anders mit
Regeln um oder kennt sie noch gar nicht.
Betrachten wir wieder unser Team …
Welche Regeln?
Coding Guidelines!
Eigene Guidelines einfach festlegen?
Nur sinnvoll, wenn das Team die Guidelines ernst
nimmt
Schritt 1Sicherstellen, dass jeder im Team versteht, warum Guidelines so wichtig sind
Schritt 2Von Anfang an jeden im Team bei der Erstellung der Guidelines involvieren
o Code Ownership
o Man kann Dinge nachschlagen
o Keine Streitereien zwischen Einzelnen
o Neuzugang kann sich einfach einlesen
o Lesbarer Code, als hätte man ihn selbst geschrieben
o Positiver Effekt auf Wartbarkeit, wenn Guidelines
eingehalten werden weniger Kosten
o Weniger erfahrene Entwickler können sich leichter
orientieren und besser dazulernen
Vorteile
Was legt man da denn überhaupt fest?
o Formatierung
o Kommentare
o Umfang von Klassen & Funktionen
o Testing
o Datei Organisation
o Naming Conventions
o Architektur Guidelines
… und, und, und
Was sind Coding Guidelines?
Ist das nicht viel?
Wie machen das andere?
o Bestehende Guidelines als Basis auswählen
Vorlage suchen (Sprache/Framework)
o Nur festhalten, wo das Team davon abweichen will
o Den ersten Entwurf im Team präsentieren
per Mail, Confluence und/oder Meeting
o Offene Diskussion & Zeit für Erklärungen
o Commitment von allen einholen
o Gemeinsam (!) “Strafen” bei Regelverstoß festlegen
Coding Guidelines festlegenpro Sprache / Projekt
Moment, Strafen?
Wieder zurück…
o Bestehende Guidelines als Basis festlegen
Vorlage suchen (Sprache/Framework)
o Nur festhalten, wo das Team davon abweichen will
o Den ersten Entwurf im Team präsentieren
per Mail, Confluence und/oder Meeting
o Offene Diskussion & Zeit für Erklärungen
o Commitment von allen einholen
o Germeinsam(!) “Strafen” bei Regelverstoß festlegen
o regelmäßig prüfen/aktualisieren/erweitern
Coding Guidelines festlegenpro Sprache / Projekt
Wie trifft man solche Entscheidungen im Team?
o Votingohne große Diskussion abstimmen
o ConsensusTeam diskutiert, bis sich alle auf eine Lösung einigen
o The Strong LeaderDiskussion im Team, Entscheidung durch Leader. Leader-Rolle kann wechseln
MethodenGerald M. Weinberg’s - “Becoming a Technical Leader“.
Proo Schnelle Ergebnisseo Gefühl der Gleichberechtigungo Hilfreich, wenn keiner
Verantwortung übernehmen will
o Gut, wenn es keinen Spezialisten zu dem Thema gibt
o Entscheidungen selten total schlecht
VotingGerald M. Weinberg’s - “Becoming a Technical Leader“
Kontrao Oft kein optimales Ergebniso Ohne Diskussion kein
Lerneffekt
Proo Großartige Ergebnisseo Hoher Lerneffekt durch
Diskussion
ConsensusGerald M. Weinberg’s - “Becoming a Technical Leader“
Kontrao Sehr zeitintensivo Wird schnell anstrengend,
wenn Meinungen zu weit auseinander liegen
Proo Schnelle Ergebnisseo Großartige Ergebnisse, wenn
der Leader tiefes Fachwissen hat
Strong LeaderGerald M. Weinberg’s - “Becoming a Technical Leader“
Kontrao Schlechte Ergebnisse, wenn
der Leader keine guten Fachkenntnisse hat und er andere Meinungen nicht berücksichtigt
o Keine Gleichberechtigung führt vielleicht zu dem Gefühl, weniger wichtig zu sein
o Slack
o Confluence
o Handzeichen
o Entscheidungs-Log
etc.
Es muss nicht immer ein Meeting sein:
o Wenn man auf Widerstand stößt, Moderator-Rolle an den „Rebell“ abgeben
o Stillere Teammitglieder einbeziehen und nach ihrer Meinung fragen
o Wenn man gemeinsam entscheidet, ist das ganze Team dafür verantwortlich
keine Blame Kultur
o Wenn über ein komplexes Thema entschieden werden muss, vorab ein
Zeitkontingent zur Einarbeitung festlegen
o Meinungen entschärfen:
„Wie seht ihr das?“
„Lasst uns den anderen Ansatz zusammen durchspielen!“
Tipps für Team-Entscheidungen
Gut
Guidelines festgelegt
Und wie läuft das jetzt jeden Tag?
Wir müssen doch Features bauen!?
Automatisieren, was geht!
o Tools bereits in der Entwicklungsumgebung einrichten
o Statische Codeanalyse der Testsuite vorschalten
✓ Spart Arbeit
✓ Frühes Feedback
✓ Die Tools kritisieren den Code, nicht andere Teammitglieder
✓ Deckt Probleme auf, ein Mensch vielleicht nicht wahrnimmt
✓ Lerneffekt
Statische Codeanalyse
Und was ist damit, das die statische Codeanalyse
nicht finden kann?
Code Reviews !
Warum?
Vorteile
o Konsistenter Code
o Code Ownership
o Wissen verteilen
o Teamstandards erhöhen
o Entwickler geben sich mehr Mühe, wenn Reviews anstehen
o Hands on learning: dein Code, dein Anwendungsfall
o Weniger Security Issues
o Weniger Bugs
Wie?
Review Guidelines
Review Checkliste
im Team erarbeiten und updaten
o Allgemein (Coding Standards)
o Performance
o Security
o Dokumentation
o Testing (ausreichend und sinnvoll)
Grundregeln
o Wirklich konstruktiv sein
o Zeit nehmen für Erklärungen
o Immer etwas Gutes finden
o Harte Kritik entschärfen:
„ ... ist nicht so gut, was meinst Du?“
„Ich glaube, es wäre besser, weil …“
o Reviews vor dem Mergen abschließen (Dod)
o Anderen für Kritik danken
o Lob / Begeisterung für gute Ansätze
Wie kann man sonst noch Wissen im Team verteilen?
o Code Reviews
o Pair-Programming
o Workshops
o (e-learning) Kurse / Clean Code Videos
o Brown Bag Lunch
o Buch Club
o Programmierbier
o Dokumentation
Wege, Wissen im Team zu verteilen
Findet einen Weg, der zu eurem Team passt!
o Bewusstsein für verschiedenen Lernstufen
oder Erfahrungsstufen schärfen
o Coding Guidelines etablieren
o Entscheidungsprozess im Team optimieren
o Code Reviews einführen
o Soviel automatisieren wie möglich
o Austausch fördern
Zusammengefasst:
Organisiert Euch!
Danke für‘s ZuhörenRessources:
Dan North, GOTO 2017 - https://www.youtube.com/watch?v=lvs7VEsQzKYBrüder Stuart und Hubert Dreyfus, 1980 - Dreyfus ModelGerald M. Weinberg’s book “Becoming a Technical Leader“https://team-coder.com/boosting-the-quality-of-team-decisions/
Bilder:
https://www.publicdomainpictures.net/en/view-image.php?image=129416&picture=darwin-evolutionhttps://creativecommons.org/publicdomain/zero/1.0/https://www.buildabear.de/mode/haarreif-mit-hasenohren/a-22348/https://pixabay.com/de/service/terms/#usagehttps://pixabay.com/de/gugelhupf-kuchen-gebacken-2842827/https://pixabay.com/de/marke-kreuz-falsch-nr-abstimmung-39951/
![Philosophische Aufsdtze: Eduard Zeller zu seinem funf- · 2015. 12. 24. · ['O n he pt of ] , in Philosophische Aufsdtze: Eduard Zeller zu seinem funf-zigjdhrigen Doctorjubilaum](https://img.pdfslide.us/doc/110x75/611de9219a783e1e040ac163/philosophische-aufsdtze-eduard-zeller-zu-seinem-funf-2015-12-24-o-n-he.jpg)
![VebraAlto.com - Agency Cloud · D ZÇ ^ }v Z o >]u] Uíìì,}o vZµ Z} U }µ v u}µ ZU } U ,ôôY dWìïðñññòðíìðrÁÁÁXu ZÇv }v o X }Xµl](https://img.pdfslide.us/doc/110x75/5d57c2d188c993a1048b4d1d/-agency-cloud-d-zc-v-z-o-u-uiiio-vz-z-u-v-u-zu-u-ooy.jpg)
