Downloaden Sie, um offline zu lesen
Hochgeladen vonMaximilian Berghoff
Aspects Of Code Quality meetup
Das Dokument behandelt verschiedene Aspekte der Code-Qualität, darunter die Bedeutung von qualitativ hochwertigem Code, Maßnahmen zur Verbesserung, Testmethoden und Metriken zur Qualitätssicherung. Es wird auf die Rolle von Test Driven Development und Behavior Driven Development eingegangen, um Wartbarkeit und Anpassungsfähigkeit von Code zu gewährleisten. Zudem werden Tools und Methoden zur kontinuierlichen Messung und Sicherstellung der Code-Qualität vorgestellt.
Aspects Of Code Quality meetup
- 1. Aspects of CodeQuality Maximilian Berghoff Andreas Haberberger Mayflower Meetup Berlin Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 2. Quelle:http://xkcd.com/844/ Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 3. Der Fahrplan Warum CodeQuality? Code Quality schaffen Code Quality messen und sicherstellen Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 4. Warum Code Quality? Waskosten Systemausfälle? Was kostet Maintenance? Was kostet Weiterentwicklung? Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 5. Warum Code Quality? ZufriedeneEntwickler! Warum? CI mit Angst führt zu PI (procrastinated integration) Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 6. 1.Qualität schaffen Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 7. Maßnahmen, die die Lebensdauer unddamit den Wert des Codes erhöhen. Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 8. Alle Maßnahmen, diedazu führen, dass Code wartbar verständlich zugänglich erweiterbar austauschbar bleibt. Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 9. Testing Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 10. Linting Metriken Unit Service Integration e2e Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 11. Testqualität Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 12. ...und wie schreibeich “testbaren” Code? Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 13. Test Driven Development Aspectsof Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 14. Verteilung Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 15. Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 16. Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 17. Testen an derDomain BDD Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 18. Ubiquitous Language Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 19. Business Need: Editusers In order to have customer support an Admin want's to edit a user. Scenario: Edit user data on behalf of a customer Given a user with email "maximilian.berghoff@mayflower.de" When i change the username to "ElectricMaxxx" Then the user profile should display the username "ElectricMaxxx" Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 20. 2. Qualität messen Warum? Aspectsof Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 21. Indikatoren Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 22. Code Metriken (objektive Qualitätsmaßstäbe) Aspectsof Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 23. subjektive Qualitätsmaßstäbe Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 24. Agile Methoden Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 25. Im Deploy Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 26. Stetiges messen Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 27. Qualität sicherstellen Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 28. Wer kann Qualitätsehen ? Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 29. Entwickler sehen undmerken Code Quality Anzahl Tests Geiler Code Code lässt sich besser bearbeiten Neue Kollegen schneller eingelernt Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 30. Bussiness kann Qualitätsichtbar gemacht werden Bugs - Weniger/Schneller gefixed BDD um Anforderung und Entwicklung “kurzzuschließen” Features schneller/planbarer Entwickler austauschbar Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 31. Bewusst auf Qualität verzichten? Aspectsof Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 32. Technische Schulden Warum eingehen? WelcheFolgen entstehen? Wie geht man damit um? Wie wieder loswerden? Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 33. Fragen ? Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 34. Warum Code Quality? Waskosten Systemausfälle? Was kostet Maintenance? Was kostet Weiterentwicklung? Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 35. - Maximilian.Berghoff@mayflower.de - @ElectricMaxxx -https://github.com/ElectricMaxxx Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg Kontakt - Andreas.Haberberger@mayflower.de - @A_Haberberger - https://github.com/ahaberberger
- 36. - Slides: “Thepyramid is a lie” - Blog: “Testen an der Domaine” Metrik: - Scrutinizer: https://scrutinizer-ci.com - Sonarqube: http://www.sonarqube.org/ Build: - Travis: https://travis-ci.org/ - Shippable: https://app.shippable.com/ - Teamcity: https://www.jetbrains.com/teamcity/ - Bamboo: https://de.atlassian.com/software/bamboo - Jenkins: https://jenkins.io/ Code Review - Crucible: https://de.atlassian.com/software/crucible - Upsource: https://www.jetbrains.com/upsource/ - Github: Github - Gitlab: https://about.gitlab.com/ - Gerit: https://www.gerritcodereview.com/Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg Links und Quellen
- 37. Thank You Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 38. “Sauberen” Code schreiben Aspectsof Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg Robert C. Martin: Clean Code. A Handbook of Agile Software Craftsmanship. Prentice Hall, Upper Saddle River NJ u. a. 2008
- 39. Agile Methoden Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 40. Tools Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 41. Metriken Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 42. Metriken Scrutinizer Sonarqube Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 43. Build Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 44. Build Travis CI shippableTeamcity Jenkins Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg Bamboo
- 45. Code Review Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 46. Code Review Upsource Github Crucible Gerrit CodeReview Gitlab Aspects of Code Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg Stash/Bitbucket
- 47. Verständlicher Code Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 48. Deploy Workflow Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 49. Agile Methoden Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 50. 3. Qualität sicherstellen Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 51. Behavior Driven Development Aspects ofCode Quality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 52. Resilience Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
- 53. Cucumber/Gherkin Aspects of CodeQuality - Maximilian Berghoff & Andreas Haberberger, Mayflower GmbH, Gneisenaustraße 10/11, D-97074 Würzburg
Hinweis der Redaktion
- #2 OPENER: ANDREAS
- #3 A: Bild, Worte A+M: Vorstellung: Andreas Max
- #4 M: Darum soll es heute gehen Der Anfang ist eigentlich das Ende Wir wollen uns mit ein wenig Basis-Wissen darüber unterhalten, warum eigentlich. Basis-Wissen: Schaffen und Messen d.h. Am Ende hoffen wir auf eine aufschlussreiche Diskussion Es soll aber nicht vom Fragen oder Einbringen abhalten KLICK
- #5 A: Fragen, über die wir uns im Nachgang unterhalten wollen, jetzt nur mal im Hinterkopf behalten Antworten, können vielfältig im Code liegen Im Grunde geht es ums Geld ABER, indirekt auch: KLICK
- #6 M: Am Ende sind das Auch Kosten Entwickler auf unsauberer Code-Basis sind schnell unzufrieden “Muss ich jetzt schon wieder diesen Bug hinterher suchen”” Unzufriedene Entwickler gehen auch schnell mal -> Bussinesssicht uncool/Kollegen findes es uncool Ein Beispiel was Entwicklern Angst machen kann ist CI - Continuous Integration Mir hat man mal gesagt: “CI ist nur CI, wenn ich stetig ohne Angst den Button drücken kann” Sonst schiebt man schnell mal Deploys auf die Lange Bahn Darum befassen wir uns erst einmal mit KLICK
- #7 M: Quality will erst einmal in den Code kommen egal ob neu oder legacy das heißt: KLICK
- #8 A Maßnahmen, die die Lebensdauer und damit den Wert des Codes erhöhen. Und die die Geschwindigkeit der Entwicklung für neue Features erhöhen. eben: KLICK
- #9 A Code bleibt wartbar, also effizient veränderbar / korrigierbar (leicht zu refaktorieren). Verständlich -> Funktionsfähigkeit bleibt nachvollziehbar / kontrollierbar. Zugänglich -> “Infosilos” werden vermieden. Erweiterbar / Austauschbar -> Einzelne Elemente sind leichter austauschbar / erweiterbar bestimmt auch wie schnell ich an einem gewissen Punkt Features bauen kann Schlechter Code macht sich besonders bemerkbar, wenn man mehr bauen will / muss Ein Aspekt der zu solchem Code führt ist schlicht: KLICK
- #10 M Egal wie oft gehört, aber TESTEN, TESTEN, TESTEN Testen ist die Basis Was und wie können wir Testen? KLICK
- #11 M Man könnte jetzt hier für jeden Punkt beinahe einen eigenen Vortrag machen Aber: Jedes Layer Jede Sprache hat ihre Tests fängt kleine An - Linting (nicht im Sinne von kleines Code-Stück) Metriken (Komplexitäten, Code Smells) bleibt klein - Unit Größere Blöcke Service oder Integration Direkt auf das Frontend/API - e2e Aber auch Testen hat ihre: KLICK
- #12 A Auch Tests haben Qualität Ist es wünschenswert, dass meine Tests korrekt durchlaufen? Das tun sie,... Wenn mein Code und mein Test korrekt sind… Wenn sich die Fehler in Test und Code aufheben... Wenn mein Test “fail-safe” ist… (also auf Erfolg hin geschrieben) Man darf an dieser Stelle nicht das Unterbewusstsein des Entwicklers unterschätzen Es kommt vor, dass man “intuitiv” die unterbewusst bekannten Probleme des eigenen Codes im Test “umschifft” Daher hat es Vorteile, wenn ein anderer Entwickler die Tests implementiert. Was ist ein wünschenswertes Testergebnis? Wenn ich sicher bin, dass mein Code korrekt ist. Wenn ich sicher bin, dass mein Code buggy ist. Mein Code wird getestet Anderer Leute Code wird nicht getestet Verhältnis Test zu Code Statistik: P(code = korrekt) * P(test = korrekt) = P(ergebnis = korrekt) generell Wahrscheinlichkeit dass Code korrekt ist (auch der Test), ist umgekehrt proportional zur Komplexität. => Code und Tests sollten möglichst wenig komplex sein. => Um exakt zu messen sollte das Messinstrument (Test) möglichst wenig Einfluss auf die Messung haben. => Tests sollten weniger komplex sein, als Code.
- #13 A SOLID Single Rseponsibility Open/closed Liskov substitution Interface segregation Dependency inversion Immutability: Der Wert einer einmal gesetzten Variable kann nicht mehr geändert werden Vorteil: Eine Variable ändert nicht “überraschend” ihren Wert, wenn sie mehrfach gelesen wird. Idempotenz: Eine Methode gibt bei jedem Aufruf das gleiche Ergebnis zurück Wenn sie das nicht tut ist das ein Hinweis auf Nebeneffekte Nebeneffekte (Side effects) vermeiden: Typen von Nebeneffekten: Persistenz IO Service calls (REST, SOAP etc.) Wenn sie nicht vermeidbar sind, Nebeneffekte kapseln: Den eigenen Code weitgehend frei von Nebeneffekten halten Den Code der zwangsweise Nebeneffekte enthält (IO, Persistenz etc.) möglichst frei von eigener Logik halten und in eigene Methoden / Klassen /Services auslagern. Nebeneffekt über Mock abbilden
- #14 M Ganz kurz noch einmal zusammen gefasst, da EIN (meines erachtens der Beste) Weg zu qualitativ hochwertigen Tests führt Bestimmt durch drei Phasen: RED schreibe einen fehlschlagenden Test das kann sein, dass die Klasse/Methode noch gar nicht da ist (Anfang) oder eine Funktion noch nicht das gewünschte Ergebnis zurück gibt GREEN Mache den Test grün Erfülle einfach nur die Anforderungen, dass der Test nicht mehr failt REFACTORING verbessere den Code Fasse Sachen zusammen verallgmeinere Beginne von Vorne Wir haben nun verschiedenste Test-Tool/Möglichkeiten gesehen, da stellt sich die Frage nach der: KLICK Führt meist zu besseren Code auf jeden Fall fühlt es sich ganz anders an Weniger Abhängigkeiten kürzere Methoden Weniger Komplexität Aber ..
- #15 M Jeden TestCase jetzt drei mal schreiben? 1x als Unit-Test, 1x als Integration-Test und 1x als End-To-End Test? In verschiedenen Tools? PHPUnit für Unit-Tests und auch für Service-Test. Selenium fürs Frontend Das sähe dann so aus:
- #16 M Das alte Agypten Diese Pyramide sollte wohl jedem inzwischen vertraut sein Sollte aus unzähligen Testing-Chakka-Talks bekannt sein Was sehen wir hier? Viele Unit-Tests weil billig Wenig UI-Tests weil teuer. Aber … KLICK
- #17 M Schneiden nach Features: Wenn wir feature für feature bauen … Dann testen wir auch feature für feature Dann erzeugen wir auch Redundanzen in den Tests (Überlapp) KLICK
- #18 M Testen an der Domain Das heißt, warum nicht direkt die Anforderung testen? Also direkt an und in der Domain der Applikation testen. Warum nicht Tests wiederverwendbar schreiben? Wenn das klappt haben wir auch in den Tests für Code Qualität gesorgt Wie soll das funktionieren?
- #19 M Wir lassen uns auf die Sprache der Domain ein. Wir sprechen nicht nur diese Sprache wir nutzen sie auch in Tests. Am eigentlichen Testen ändert sich nichts, nur die Beschreibung der Szenarien wird allgemeiner verständlich. Schlechte Tests sind auch in Gherkin-Notation schlecht... Ein Beispiel gefällig ...
- #20 M Beschreibung eines Test-Scenarios Können Kunden lesen Kann direkt aus Anforderungen hervorgehen Wie weiter Die eigentlichen Tests werden in den gewohnten Testframeworks in sog. Contexten umgesetzt. Context für Service-Test -> IntegrationTests Context für Unit-Test -> Unit-Tests Context für Selenium Test -> e2e Warum? Schablone nahe an den Anforderungen In der Sprache des Kunden Tests beinahe nur einmal geschrieben Tests können von Kunden verrifiziert werden Tests könnten vom Kunden geschrieben werden - zumindest die Scenarien Fallen aus guten Stories raus Ein Thema was, nicht den Code direkt betrifft, ihn aber Absichert: KLICK
- #21 A Motivation sicherstellen Sichtbar machen Probleme Fortschritt Business liebt zahlen KLICK
- #22 A Welche Indikatoren können für die Qualität von Code herangezogen werden? KLICK
- #23 A Komplexität Mess Detection Coding Style Testabdeckung LoC Pfad Codemenge KLICK
- #24 A “Ordentliche” Struktur fängt bei Style an und hört bei Ordner und KlassenStruktur auf kann Teil von Team-Commitment sein “Saubere” Interfaces Generell auf Abstraktionen arbeiten public Methods in Interfaces Gerade wenn man OS betreut lernt man Interfaces schätzen viel mögliche Zusatzfunktionen über interfaces gebaut oder hooks offen gelassen “Einfache” Wartbarkeit muss ich mich durch etliche Zeilen Code wühlen bspw: lange if-else für Entscheidungen oder habe ich beispielsweise eine Kette von Votern wo jeder für einen Fall zuständig ist Kleine Codeeinheiten Wie wohl fühle ich mich in meinem Code? KLICK
- #25 A Userstories mit Akzeptanzkriterien zur Planung / Bewertung überschaubarer Einheiten Dann gibt es eben auch die wirklichen Metriken, als Zahlen: KLICK
- #26 M Im Deploy Tests laufen lasssen Was gemessen: läuft noch alles? Tools nennen: Viel zu viele Code Metriken messen Tools nennen Scrutinzer, StyleCI eignet sich schon im Vorgang des PR als Hooks im SCM (git) Konsolen applicationen ausführen Tools für den Deploy nennen Jenkins, Bamboo, shipable, TravisCI Differenzieren ob als SCM-Hooks oder im Deploy an sich Neben diesen Messbaren Metriken und den anfangs genannten Indikatoren gibt es dann noch weitere: KLICK
- #27 A Warum jetzt nochmal das ganze? stetiges messen führt dazu, dass neuer Code Qualität behält alter/bestehender Code Qualität beibehält ERGO: KLICK
- #28 M das führt uns ganz selbstverständlich zum sichern der Qualität Doch es stellt sich noch die Frage: KLICK
- #29 M Qualität will man irgendwie sehen können Wie wir in im Bereich messen festgestellt haben, können wir Tests und Metriken erkennen und messen Wer sieht denn Qualität KLICK
- #30 M Entwickler sollten als erstes die Qualität “spüren” Wir sehen Tests, wie geil sieht das aus wenn so tests durchlaufen … :-) Kennt ihr eigentlich NyanCat-Reporter für die Konsole? Geiler Coder hat was schönes, speziell ich liebe es Als Entwickler merke ich natürlich, dass sich Code schneller bearbeiten lässt, um ein wenig von den Gefühlen ins sachliche zu kommen … :-) In qualitativ hochwertigen Code, der sich vll. auch auch constraints hält lassen sich Kollegen anlernen KLICK
- #31 A nicht nur Entwickler wollen Qualität sehen natürlich auch die Kunden Bug werden weniger Bugs werden schneller gefixed BDD integriert Kunden direkt in die Entwicklung Scenarios lesbar lassen sich abprüfen Features lassen sich schneller planen Entwickler können schneller Feadback geben Features werden dadurch planbarer Und .. Eigentlich lassen sich Entwickler besser austauschen Sehen wir es mal nicht so kritisch, Ausfälle lassen sich besser kompensieren Können wir: KLICK
- #32 A Wenn man Qualität schaffen und messen kann, kann man auch bewusst auf selbige verzichten, Man sollte halt nur wissen worauf man sich da einlässt. KLICK
- #33 A Warum eingehen? Zeitnot Unsicherheit darüber, welche Features Businessvalue bringen Nur, wenn von vornherein klar ist, wann die Schulden wieder abgebaut werden können. Welche Folgen entstehen? “Zinsen” in Form erschwerter Weiterentwicklung (Allgemein alle Nachteile geringerer Codequalität) Wie geht man damit um? Offenheit!!! Dokumentieren Im Team klären, wann die Schulden wieder abgebaut werden (Zeit für Refactoring Wie wird man sie wieder los? Plangemäßes Refactoring Na dann: KLICK
- #34 M Fragen zur Theorie? now mail Twitter wo/wie? … Dann haben wir eben noch welche: KLICK
- #35 M: Gut dann haben wir wieder die Fragen vom Anfang: sollte sich jetzt nicht einfacher beantworten lassen aber vielleicht sieht man die Qualität damit in einem besseren Licht Wer ist denn hier verantwortlich für seine Software und mag ein paar Zahlen nennen? Gerne nehmen wir diese Fragen auch in die Offene Diskussion im Social-Teil des Events mit.
- #36 M
- #39 A “Uncle Bob” stellvertretend für viele andere einschlägige Texte. Inversion of Control Dependency Injection done right Definition über Interfaces Injection über Setter-Methoden Single Responsibility Principle Eine Aufgabe pro Service / Modul / Klasse / Methode / Codezeile ;-) Design Patterns Als funktionierend etablierte Praktiken Convention over Configuration Verringert die Codemenge Wird von den meisten Frameworks unterstützt / gefordert Saubere Interfaces Alle öffentlichen Methoden einer Klasse werden in einem Interface deklariert, das die Klasse implementiert. “Kontrolliert” Separation of Concerns Saubere Abstraktionen und Vererbung Liskovsches Substitutionsprinzip Wenn S eine Unterklasse von T ist, müssen alle Objekte der Klasse T durch Objekte der Klasse S ersetzbar sein Refactoring Wir verlassen den Code jedesmal ein kleines bisschen besser, als wir ihn vorgefunden haben. Weitere hilfreiche Grundprinzipien: KISS, DRY, YAGNI (sozusagen Design Patterns für des eigene Verhalten)
- #40 A Sustainable pace (Unter Druck wurde noch keine hochwertige Zeile Code geschrieben) Durch das Implementieren von Frameworks wie Scrum gibt man dem Team Freiraum sich und den Code weiter zu entwickeln
- #41 A Was haben wir denn da Unterscheidung in Metriken Build-Tools Code-Review
- #42 A Re-Cap von den Metriken
- #43 A Scrutinizer automatisched Code Review Tool Führt Test auf Metriken aus Beispielsweise: MessDetection, Code-Duplication Anekdote: Kommen wir morgens ins Projekt auf einmal war Scrutinizer da und bemängelt CS im PR.(HInt: MyDriver) https://scrutinizer-ci.com Sonarqube: Andreas? http://www.sonarqube.org/
- #44 M Was haben Builds mit Code QA zu tun? Ein Build sollte failen, wenn Tests nicht grün sind Ein Build sollte failen, wenn Metriken werte erreichen, die ungünstig sind Ein Build sollte failen, wenn Coding Style nicht eingehalten wird => automatisieren vor dem eigentlichen Build
- #45 Travis M https://travis-ci.org/ Shippable A https://app.shippable.com/ Jenkins M https://jenkins.io/ Teamcity A https://www.jetbrains.com/teamcity/ Bamboo: M https://de.atlassian.com/software/bamboo Current in Projekt Fügt sich gut in ein Projekt mit vielen Atlassians ein Nur im eingeloggten Zustand kann man deployen :-)
- #46 M Was muss beachtet werden? Code Reviews sind keine “Gefälligkeitsleistung” (dem Code verpflichtet, nicht dem Kollegen) Persönliche und Codische Weiterentwickung Sorgt für einheitliche Code-Sicht im Team (durch Iterationen) Verteilt das Wissen über den Code im Team
- #47 Crucible A https://de.atlassian.com/software/crucible von Atlassian, daher gut in Jira, Confluence etc. integriert Upsource: M https://www.jetbrains.com/upsource/ Jetbrains muss ja in jedem Bereich auch ein Tool haben Wenn man Storm mag und ein Key-Map-Nerd ist, lohnt es sich mal in Upsource umzusehen -> lässt sich genauso bedienen Github: M Github Das Tool für die OpenSource-Welt Aber auch private Gitlab M Gitlab Self-Hosted Gerit Code Review A Gerit Code Review Stark Plugin-orientiert Open source Stash/Bitbucket A Fügt sich wieder in Atlassian-Toolset ein Bitbucket wurde als Service von Atlassian gekauft Stash ursprünglich als on-premises Lösung Wächst zusammen (Stash heißt inzwischen Bitbucket-Server und Bitbucket beruht offenbar inzwischen auf dem Code von Stash ;-) )
- #48 M Namen von Klassen, Methoden/Funktionen und Variablen auschreiben Einheitliche Sprache in der Nomenklatur (nicht Deutsch und Englisch mischen) Kurze (semantiklose) Variablen wie x nur in extremen Ausnahmefällen und nur in mit einem Blick überschaubaren Einheiten Style: Einigen im Team auf einheitlichen Style Testen per Tool: StyleCI, PHP_CS, .. Dokumenation Inline-Dokumentation in Doc-Blocks
- #49 A Der Weg vom Commit aus dem Team bis hin zum Deploy Feature-Branches + Code Reviews auf PR Tests schon auf den Feature-Branches (Style + Metriken) Automatisierte (einfache) Deployments (Hochwertiger Code ist nur hochwertig, wenn er auch so auf dem Server landet) Zwiespalt zwischen Gewinn an Code Qualität und Einschränkungen für die Developer
- #50 A Pair Programming Definition of Ready (Schlechte Tickets machen keinen guten Code) Definition of Done (Keine Entschuldigung für halbfertige Tickets) Scrum Iterationen Shippable Increments Interaktion zwischen PO und SM (technische) Retrospektiven (Erfahrungen fließen strukturiert in den Produktionsprozess zurück)
- #51 A Tests + Metriken bringen nichts, wenn schlechter Code daran vorbei deployed wird Einbauen in Build-/Deploy-Prozess dadurch entsteht mehr oder weniger sanfter Zwang zur Qualität
- #52 M Wo wir gerade schon beim Thema sind: Beschreibunssprache ist Teil von BDD Anstelle von Anforderungen an den Code - Methode gibt einen bestimmten Wert zurück Tritt: Anforderung an das Verhalten des Codes und damit der Software Aus “testThat” wird “bla should do that” Wie schon Cucumber erwähnt: Nahe an der Sprache des Kunden.
- #53 M Was ist Resilience? Die Fähigkeit eines Systems, bei Fehlersituationen die Funktionsfähigkeit aufrecht zu erhalten. Oder eben nur Teile ausfallen zu lassen Gerade in Micro-Service-Architekturen anwendbar Wenn der Checkout nicht funktioniert verdient ein Shop bspw. kein Geld Sollte nur die Recomendation fehlen, sollte das kurzfristig nicht so sehr auftragen Das heißt zum einem ist eine eine Art Priorisierung Bussiness-kritische Teile sind mehrfach gespielgelt, haben hohe Testabdeckung Nicht so kritische Teile blockieren nicht auch noch kritischere Teile Das betrifft aber weniger den Code als die gesamte Architektur, darum hier nur kurz angeschnitten.
- #54 A Tool aus dem BDD Bereich textuelle Spezifikation von Anforderungen Gherkin ist die Sprache, die Cucumber (Implementierung) versteht... Machen wir es eventuell einfacher ...