diff --git a/Writerside/images/image_663.png b/Writerside/images/image_663.png new file mode 100644 index 0000000..a6eb219 Binary files /dev/null and b/Writerside/images/image_663.png differ diff --git a/Writerside/images/image_664.png b/Writerside/images/image_664.png new file mode 100644 index 0000000..2444a12 Binary files /dev/null and b/Writerside/images/image_664.png differ diff --git a/Writerside/images/image_665.png b/Writerside/images/image_665.png new file mode 100644 index 0000000..c138ce8 Binary files /dev/null and b/Writerside/images/image_665.png differ diff --git a/Writerside/images/image_666.png b/Writerside/images/image_666.png new file mode 100644 index 0000000..88ebc87 Binary files /dev/null and b/Writerside/images/image_666.png differ diff --git a/Writerside/images/image_667.png b/Writerside/images/image_667.png new file mode 100644 index 0000000..88ebc87 Binary files /dev/null and b/Writerside/images/image_667.png differ diff --git a/Writerside/images/image_668.png b/Writerside/images/image_668.png new file mode 100644 index 0000000..f0640a5 Binary files /dev/null and b/Writerside/images/image_668.png differ diff --git a/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md b/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md index 030cfc0..c0ddace 100644 --- a/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md +++ b/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md @@ -519,4 +519,101 @@ - höhere Code-Qualität ### Pairing Styles -- \ No newline at end of file +#### Pairing Style: Driver and Navigator +- **Fahrer** + - Person an der Tastatur + - ist fokussiert das nächste kleine Ziel zu erreichen + - ignoriert größere Probleme + - sollte die ganze Zeit mitreden, was er tut +- **Navigator** (_hoffentlich ohne link rechts Schwäche_) + - ist in der überwachenden Position, während der Fahrer tippt + - Reviewed den Code durchgängig + - direktes Feedback + - Hat auch größere Probleme, Bugs im Kopf + - Notizen für mögliche nächste Schritte +- **Möglicher Arbeitsablauf:** + - ![image_663.png](image_663.png) + +#### Pairing Style - PingPong +- Perfekt für einen TDD-Task + - **Ping** + - Dev A schreibt einen fehlschlagenden Test + - **Pong** + - Dev B schreibt Implementierung damit er klappt + - **Ping** + - Dev B schreibt den nächsten Test +- Bei jedem Pong kann man auch nochmal refactoren + +#### Pairing Style - Strong-Style Pairing +- Super für Wissenstransfer +- Regel: "Jede Idee, die von deinem Kopf in den Computer soll, muss durch die Hände von jemand anderem gehen" +- **Navigator** + - erfahrene Person +- **Fahrer** + - Person die was lernen will/soll + - sollte dem Navigator voll vertrauen + - Warum?-Fragen und Challenges nach dem Implementieren besprechen + +#### Pairing Style - Research and Explore +- Überlegen und herausfinden ist häufig notwendig + - bspw. bei neuen Technologien etc. +- Wie kann man das im Pair-Modus angehen + - Liste mit Fragen für eine mögliche Situation machen + - Aufsplitten für einzelne Zeitslots + - entweder Fragen aufteilen oder gleichzeitig Antworten auf gleiche suchen + - Zusammenkommen und diskutieren/teilen was man gefunden hat + +#### Pairing Style - Documentation +- Je nach Situation und Präferenz + - Dokumentation zusammen machen + - Einer schreibt, anderer macht Anmerkungen + +### Benefits / Challenges + +| Vorteile | Herausforderungen | +|--------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------| +| Wissensaustausch | Kann anstrengend sein | +| Reflektion: hat mans wirklich (richtig) verstanden? | Verschiedene Skill Levels: Können zu falschen Erwartungen und Frustration führen | +| Fokus behalten: Zusammen arbeitet man strukturierter, keine "schnellen" side-quests | Power-Dynamics: Chef-Mitarbeiter → kann das ganze schwierig machen | +| Code Review on-the-go: | Pairing erfordert Verletzlichkeit: ist schwer zu sagen, dass man etwas nicht weiß/kann - aber notwendig | +| Zwei Denk-Modi kombiniert: verschiedene Perspektiven haben | Chef überzeugen, dass es gut ist | +| Gemeinsames Code-Ownership: Höhere Chance, dass jemand sich traut Änderungen vorzuschlagen | | +| Schnelles Onboarding | ![image_665.png](image_665.png) | +| ![image_664.png](image_664.png) | ![image_666.png](image_666.png) | + + +## Static Code Analysis +- Code analysieren, ohne ihn auszuführen +- Tools inspizieren das Programm für ... + - alle möglichen Verhalten + - suchen Coding-Fehler, Back-Doors, ... + - generieren Metriken für den Code die helfen die Qualität zu analysieren +- Kann Qualität verbessern + +### Beispiele für die Identifikation von Bekannten Problemen und Bad Practices +- **Generische Beispiele** + - Größe + - Kann verschieden gemessen werden + - _Code-Zeilen, Klassen, Dateien, Funktionen, ..._ + - Kommentare + - zeigen häufig, dass der Code zu komplex ist + - Duplikate + - _Dont repeat yourself!_ +- **Sicherheitsrelevante Issues** + - OWASP Top Ten + - Sammlung von kritischen Risiken für Anwendungssicherheit + - SAST Tools + - finden bekannte Risiken + +### Simple Metrik für Komplexität: McCabe Metrik +![image_667.png](image_667.png) +- Cyclomatische Komplexität + - Behandelt Programmstuktur als Graphen +- Wird folgendermaßen kalkuliert: + - $$C = E-N + 2P$$ + - E = Nummer der Ecken + - N = Nummer der Nodes + - P = Nummer der verbundenen Komponenten (für eine OO Funktion ist P = 1) +- Beispiel: + - $$C = 9-8+ (2*1) = 3$$ +- ![image_668.png](image_668.png) \ No newline at end of file