Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
14 Cards in this Set
- Front
- Back
|
Was ist "Technical Debt"? |
- die "technischen Schulden" - Gefahren/Probleme/Konsequenzen durch schlecht geschriebene Software - häufig in Manntagen und Geld anzugeben |
|
|
Break-Even von Design zu no-Design |
- no-design kommt schneller auf den Markt - später zahlt sich gutes Design durch shcnellere Features und bessere Wartbarkeit jedoch aus -> break-even-point |
|
|
Warum werden Entscheidungen gegen guten Code/gutes Design getroffen?
|
Technical Debt Quadranten:
* Reckless/Deliberate: - schnelles Geld - bewusst schlechten Code - Verantwortung durch "harten Markt" von sich weisen * Reckless/Inadvertent: - unwissende - meist andere Fachbereiche - Intoleranz: ist mir egal was das ist * Prudent/Deliberate - irgendwie den Gefahren bewusst - Probelm verdrängen und nach hinten schieben - ausliefern immer noch an erster Stelle * Prudent/Inadvertent: - bewusst irgendwie Qualität im Auge gehabt (evt. von Beginn an) - Fehler erkennen und auf Geld und Zeit zum fixen hoffen - trotz guten Willens schon schief gelaufen |
|
|
Aufgaben des Entwicklers gegen technical debt? |
- Management überzeugen das guter Code sich lohnt - zu 90% der Zeit wird Code gelesen und nicht geschrieben (nicht von mir selbst) - Kosten für Wartung und Erweiterung mehr als 80% der Gesamtkosten - Code mit Begeisterung verteidigen! |
|
|
Was ist ein Scope? |
Geltungsbereich/Sichtbarkeitsbereich |
|
|
Coding Basics |
- kill useless code - delete useless comments - inverstiere in Namensfindung - SLA: Single Level of Abstraction - Code sollte sich lesen wie Prosa - Avoid magic numbers - prefer polymorphism to if/else/switch/case - changes have local consequences - fields should define states (and are often not) - richtiges Exception Handling - einfaches refactoring anwenden |
|
|
Coding Source |
- lokale deklaration von Variablen (vertical separation, keine definitionam blockbeginn, sondern da wo sie eingesetzt werden)
- erklärenden Variablen / optimale Anzahl an Variablen um einzelne Schritte lesbar zu machen - tiefer geschachtelter Code sollte immer spezifischere Aufgaben übernehmen. Aufrufwahrscheinlichkeit und Abstraktion auf höherer Ebene also höher sein - Abtrennung von Multi-Threaded-Code: keinen thread-code mit "normalem" code mischen |
|
|
Coding Conditionals |
- komplexe Logikoperationen in sprechende Methode extrahieren - negative logikoperationen vermeiden - Randbedingungen (zB für Schleifen) an einer Stelle außerhalb des Kerncodes der Schleife offen legen |
|
|
Coding Principles |
- DRY: Dont repeat yourself - Einfachheit als oberstes Prinzip (roter Grad): * KISS: Keep it simple, stupid (komplexity kills) * YAGNI: You aint gonna need it - Code Communication, Simplicity, Flexibility: * Communication: selbst erklärender, sprechender Code * Simplicity -> KISS * Flexibility: Änderbarkeit und Wartbarkeit des Codes - Vorsicht vor Optimierungen (roter Grad) * Avoid early Optimizations (1. Dont do it, 2. Dont do it yet) - "doing" vs. "calling" Code (oranger Grad): * Single Level of Abstraction: SLA * auf welcher Abstraktionseben liegt der Code * unterschied zwischen wirklich etwas tuendem code und aufrufendem Code * Entwickler muss sich klar sein auf welcher Ebene er grade ist - Konfiguration auf High-Level Ebene ziehen * besser wiederauffindbar und damit auch schneller verständlich - Vorsicht vor Konfigurationen * Über-Konfigurierbarkeit ist gefährlich * Komplexität erhöht sich für Anwender und Entwickler meist unnötig (um wirklich jeden edge case abzudecken) - Implizite Reihenfolgen sicherstellen * Hidden temporal coupling: aufruf von Methoden sollte keine feste Reihenfolge vorgeben * wenn doch muss es ersichtlich sein und nicht falsch aufgerufen werden können: kein read() vor open() - Richtlinien beibehalten * Dont be arbitrary * wenn man sich selbst nicht durchgängig, logisch und konsequent an die Regeln hält machen es andere auch nicht |
|
|
Code Quality |
- Source Code Conventions - Automatisierte Unit Tests (nehmen Angst, sparen zeit) - Code Coverage Analyse (>80% erstrebenswert; zeigt ungetesteten Code, Gesamtüberblick über Abdeckung für PL, schnelles Feedback für Dev) - TDD, erst den Test, dann den Code (man denkt gezielt über Schnittstellen nach, schnelles Fehler entdecken, Code wird leichter zu schreiben) - Mockups benutzen um Codestellen/Units für den Test zu isolieren (durch definierte Mocks als Umgebung) - Funktionale Techniken (Funktional legt Wert auf Seiteneffektfreiheit, und gibt andere Sichtweise auf Probleme) - Lange Funktionen zerlegen (Method Object Pattern) und Code Reviews zur Qualitätsssicherung nutzen - Messen von Fehlern (Fehler die nicht da sein dürften, zB nach einer Iteration daran hindern weiterzuentwickeln) -> Ticket Systeme etc - durch statische Codeanalyse und Kennzahlen wie zB Komplexität, Coverage, etc. - Technical debt messen und täglich eigene Arbeit reflektieren |
|
|
Architektur und Klassendesign |
- Composition over Inheritance (FCoI) - Single Responsibility (SRP) - Separation of Concerns (SoC) - Interface Segregation Principle (ISP) - Information Hiding Principle - Use Dependency Injection (DI/IoC) - Liskov Substitutions Prinzip - Komplexe Refaktorisierungen - Open Closed Principle - Tell, dont ask - Law of Demeter - Basic Patterns (Pluggable Selector, DSL, etc.) - Design and Implementation must not overlap - Implementation corresponds design - Visualize, Measure and Constrain your Architecture - Check Enterprise patterns Common Closure + Common Reuse Principle (CCP, CRP)-> Klasse nicht auf Veränderungen aber auf Erweiterung auslegen |
|
|
Packages |
- zusammenpacken was zusammengehört - Visualisiere Abhängigkeiten von Paketen - Zugriff nur von unten nach oben und link nach rechts - Acyclic Dependencies Principle (ADP), zyklenfreier Graph der Packages -> Wartbarkeit sinkt extrem bei Zyklen - unstabile Packages hängen von stabilen ab -> Stable Dependencies Principle (SDP) - Je stabiler, desto Abstrakter die Komponenten (Stable Abstractions Principle SAP) - Ca und Ce sind hier wicthtig -> JDepend |
|
|
Produktivität beeinflussen durch |
- Pfadpfinderregel/Scout Rule -> Besser hinterlassen als vorgefunden (Broken window theory) - bekämpfe ursachen, nicht wirkung (root cause analysis) - Komponentenorientierung (Think and create components) - Keine goldenen Wasserhähne -> YAGNI - Prinzip der kleinstmöglichen Überraschungen, Principle of least astonishment - VCS einsetzen -> Git etc - Issue und Defect tracking - Effektives Buildmanagement mit Buildtool - automatisierte Integrationstests - CI/CD - Prüfen ob eine DSL sinnvoll sein kann |
|
|
Management / Produktivität steigern |
- Kill distraction -> Ablenkung ausschalten - zB Pomodoro - gutes Launchpad nutzen - Keyboard Wizard -> Keys und Shortcuts kennen - Mehrere Monitore oder virtuelle Desktops - Skripte einsetzen und Makros - Use unix - Nutze die für dich beste IDE - kenne wichtige Libraries, nicht das Rad neu erfinden - Iterative Entwicklung, zb Scrum - Lesen Lesen Lesen - Teilnahme an Fachveranstaltungen - Erfahrungen teilen |
