Stufe 1: Roter Grad von CCD - Lutz Prechelt Institut für Informatik, Freie Universität Berlin
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Stufe 1: Roter Grad von CCD Lutz Prechelt Institut für Informatik, Freie Universität Berlin
Aldo Cavini Benedetti, Flickr
Bevor wir starten:
4 wichtige Begriffe
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
2
1. "Abwägung"
dance-dream.de fritz-berger.de
• Kosten/Aufwand gegen Nutzen
oder
• verschiedene Vorteil/Nachteil-Kombinationen gegen einander
Ist schwierig wegen:
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
3
2. "Risiko"
• Möglichkeit eines unerwünschten Ereignisses
• z.B. Aufwand (Nutzen bleibt aus), Defekt,
schlechte Lesbarkeit
• Eintrittswahrscheinlichkeit
• bei uns meist sehr unklar
• Schadenshöhe
• bei uns oft unklar
Benötigt
wird:
http://i.imgur.com/B2QZHtr.jpg
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
4
3. "Zutrauen" ("confidence")
• Gewissheit von
"Eintrittswahrscheinlichkeit ist genügend niedrig"
Problem
im Kurs
dabei oft:
peter heck
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
5
4. "Kurpfuscherei"
("snake oil")
• Behauptete Wirkung
einer Technik tritt
nicht immer ein
James Gillray - Der Aderlass (um 1805)
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
6
Also bitte…
…nicht zu leicht
beeindrucken lassen
Äh, wo waren wir?
Ach ja:
Stefano Mortellaro, Flickr
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
7
Stufe 1: Roter Grad von CCD Lutz Prechelt Institut für Informatik, Freie Universität Berlin
Übersicht
Prinzipien: Praktiken:
• Don't Repeat Yourself (DRY) • Pfadfinderregel befolgen
• Keep it simple, stupid • Root Cause Analysis
(KISS) durchführen (RCA)
• Vorsicht vor Optimierungen! • Versionskontrollsystem
• Favour Composition over einsetzen
Inheritance (FCoI) • Einfache Refaktorisierungen
• Integration/Operation anwenden
Segregation Principle (IOSP) • Extract Method, Rename
• Täglich reflektieren
Gestalt des Codes Eigenes Verhalten
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
9
Don't Repeat Yourself (DRY)
• Was? • Hinderungsgrund:
• Redundanz im Code • Anfangs ist Code mit
vermeiden Redundanz oft sehr viel
• Logik schneller zu produzieren
• Daten, Konstanten
• Annahmen!
• Wofür?
• Evolvierbarkeit
• Korrektheit
• Produktionseffizienz
(immer gleicher Aufbau der ersten Folie)
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
10Don't Repeat Yourself (DRY)
• Arten von Verletzungen: • Hilfreiche Techniken:
• Erhöhen den Pflegeaufwand • Abstraktion
• Code-Klone • Unterprogramme, Klassen,
• Werden sehr oft Konstanten etc.
inkonsistent geändert • Funktionale Programmierg.
(Defekte) • Aspekt-orientierte
[CloneEvol, ClonesMatter] Programmierung (manchmal)
• Verstreut hartkodierte • Convention over configurat.
Annahmen aller Art • Objekt-relationales Mapping
• z.B. Stringformate mit Schemamanagement
• Domänenspezif. Sprachen
(DSLs), Generatoren
• auch Javadoc u.ä.
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
11Don't Repeat Yourself (DRY)
nicht übertreiben
• Für alle Regeln in diesem • Beispiel für Übertreiben:
Kurs gilt: • Clean Code, Ch.14, p.195:
Maß halten ist wichtig! • Bibliothek zur Verarbeitung
v. Kommandozeilen-Args.
• Was, wenn man diese
• DRY übertreiben heißt: erlaubten Formate in einer
Zu viel Aufwand für die Fehlermeldung auflisten
Redundanzvermeidung möchte?
treiben • Falsch:
• Ziel ist • Formate in Konstanten-
Komplexitäts-Reduktion! Array speichern
• Indices als symbolische
Konstanten definieren
• Richtig:
• Redundanz in Kauf nehmen
• Kommentar an Else-If-
Ansichtssache! Kette kleben, der darauf
hinweist
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
12Don't Repeat Yourself (DRY)
auf Prozessebene
• Auch mehrfach wiederholte Tätigkeiten verletzten DRY
• Dagegen hilft
• Automatisierung (z.B. Build, Tests, Release/Deployment)
• Teamkoordination
• Firmenweite Koordination
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
13Keep it simple, stupid (KISS)
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
14Keep it simple, stupid (KISS)
• Was? • Hinderungsgrund:
• Versuche überall • Einfach ist oft schwierig
(Architektur, • Saint-Exupéry: "Perfektion
Klassenentwurf, Logik, ist nicht dann erreicht,
Datenstrukturen, wenn es nichts mehr
Infrastruktur usw. usf.) hinzuzufügen gibt,
einfache Lösungen zu finden sondern
wenn man nichts mehr
• Verwende kompliziertere weglassen kann."
nur, wenn es gewichtige
• Unbedingt Maß halten!
Gründe für sie gibt
• Ob ein Grund gewichtig ist,
ist oft unklar
• Wofür? • Ob etwas einfach wirkt,
• Evolvierbarkeit hängt vom Vorwissen ab
• Korrektheit • Siehe "Simplicity by
• Produktionseffizienz Design" in Java EE 6
2
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
15Kleiner KISS-Scherz:
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
16Keep it simple, stupid (KISS)
• XP1's rules of simple design • Hilfreiche Techniken:
[DesignDead]: • Funktionalität ganz
1. Runs all the tests weglassen
• tests are comprehensive • Inkrementelle Entwicklung
and do not fail • Mehrere Entwerfer fragen
2. Reveals all the intention
3. Contains no duplication
• OAOO: Do it once and only
once (=DRY)
4. Has the smallest number
of classes or methods
• 4 ist das Gegengift gegen
übertriebene Anwendung
der hiesigen Ideen
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
17Keep it simple, stupid (KISS):
vorher/nachher Beispiel
Vorher: schlecht
• Saros hat Operationen auf Dateiebene (FileUtils.java). 2
• Deren Teile wurden intern mittels WorkspaceRunnables
zu atomaren Transaktionen zusammengefasst.
• Tatsächlich enthielt aber jede Transaktion
ohnehin nur 1 Operation
• (Plus noch zwei andere überflüssige Sachen)
Nachher: gut
• 230 LOC eingespart, auch mehrere komplexe Methoden
• https://github.com/saros-project/saros/commit/3adb19a
• Man lasse mengenmäßig rot (=entfernt) und grün (=neu)
auf sich wirken.
• Die Änderungen sind im Detail schwierig zu verstehen,
weil viele Methoden fusioniert werden
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
18Keep it simple, stupid (KISS)
auf Prozessebene
• KISS gilt nicht nur für das Produkt,
sondern auch für alle Methoden und Arbeitsprozesse
Und für die Berührstellen (Abhängigkeiten) der beiden:
• "Simple" heißt auch, die Qualitätsmaßstäbe geeignet an die
Umstände anzupassen
• Beispiel: Unsauberkeit im Code belassen, wenn
• das Aufräumen viel Arbeit macht
• aber die Unsauberkeit fast keine Probleme erwarten lässt.
• Beispiel im Artikel [SuffDesign]:
• einen "return null"-Smell im Code belassen,
weil nur wenige alltägliche Änderungen dem Smell begegnen,
2
aber viele Änderungen nötig wären, ihn zu beseitigen
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
19Keep it simple, stupid (KISS)
auf Metaebene
• Viele der Prinzipien in diesem Kurs sind
Konkretisierungen von KISS
• z.B. SLA, SRP, SoC, LSP, YAGNI
• Die Mehrzahl von diesen führt jedoch von KISS weg,
wenn man die Anwendung übertreibt
• z.B. alle obigen
• Eine zusätzliche, sehr wichtige Konkretisierung lautet deshalb:
Sei nicht dogmatisch
bei der Anwendung von Prinzipien!
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
20KISS: The Zen of Python 2
• http://legacy.python.org/de • Special cases aren't special
v/peps/pep-0020/ enough to break the rules.
• Beautiful is better than ugly. • Although practicality beats
purity.
• Explicit is better than
implicit. • Errors should never pass
silently.
• Simple is better than
complex. • Unless explicitly silenced.
• Complex is better than • In the face of ambiguity,
complicated. refuse the temptation to
• Flat is better than nested. guess.
• Sparse is better than dense. • There should be one-- and
• Readability counts. preferably only one --
obvious way to do it.
(plus 6 other,
less important rules)
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
21KISS: Nochmal eine Definition 2
KISS bedeutet
• das Unnötige bleiben lassen
• das Nötige tun
• und zwar auf die geradlinigste, robusteste, einleuchtendste Art,
die man mit moderatem Aufwand finden kann.
• Das Problem:
• Die Begriffe geradlinig, robust, einleuchtend, moderat
sind allesamt auslegungsbedürftig.
• Wir kommen um Urteilskraft nicht herum
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
22Das vielleicht schwierigste
Prinzip von allen
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
23Vorsicht vor Optimierungen!
• Was? • Hinderungsgrund:
• Optimiere nur, wo das • Manchmal juckt es einen
wirklich nötig ist halt…
• Denn unnötige Optimierung • Gelegentlich ist es schwierig
kostet Aufwand und macht herauszufinden, wo eine
den Code meistens Optimierung hin muss
fehleranfällig, schwer zu
verstehen und schwer zu
ändern
• (Donald Knuth: "Premature
optimization is the root of
all evil")
• Diskussion
• Wofür?
• Evolvierbarkeit
• Korrektheit
• Produktionseffizienz
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
24Vorsicht vor Optimierungen!
• Arten von Verletzungen: • Hilfreiche Techniken:
• Unnötig komplizierte • Rules of Optimization
Algorithmen/Verfahren 1. Don't do it.
• Unnötiges Caching 2. For experts only:
• Verzicht auf Don't do it yet
Fehlerprüfungen (Michael A. Jackson)
• Verzicht auf Abstraktion • Überschlagsrechnungen
• Einsparen weniger, • Teile ganz weglassen
schneller Anweisungen • insbes. Ein-/Ausgaben:
Platte, Netz, Bildschirm
• etc.
• Profiling
2
• Lazy Optimization
[LazOpt]
• Eine Mustersprache
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
25Vorsicht vor Optimierungen!:
Negativ- und Positivbeispiel
• Negativ: • Positiv anschließend:
• Oracle-Transaktionsanwdg. • Was wirklich half: Nicht
lief zu langsam mehr zu Beginn 1 Satz in
• Berater empfahl die leere Markertabelle
Entfernung von Dutzenden schreiben und am Ende
"if global_debug_flag then wieder löschen
call trace routine" • Datensatz 1 ist bei Oracle
• Quatsch!, denn: sehr langsam
• Jede Transaktion umfasste • Dadurch wurde die Anwdg.
~200 solche Abfragen, um Faktor 3 schneller!
aber auch ~20 DB-Abfragen
• Negativ:
2
• Singleton-Cache für ein
wichtiges Objekt zerbrach
die Testisolation bei
"anwesende" (Django)
• Zugriff war aber gar nicht
sehr häufig
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
26Favour Composition over Inheritance
(FCoI)
• Was? • Hinderungsgrund:
• Verwende Vererbung nur • Faulheit
für is-a-Beziehungen • Zufügungen zu einer
• nicht zur Wieder- Oberklasse
verwendung von Methoden • und dabei übersehen: Nicht
• In allen anderen Fällen alle Unterklassen brauchen
bette hilfreiche Objekte dies!
lieber ein (Komposition) • aktuelle oder künftige
und schreibe einzeilige
Methoden zur Verwendung
(Delegation)
• Wofür?
• Evolvierbarkeit
• Korrektheit
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
27Favour Composition over Inheritance
(FCoI)
• Effekte von Verletzungen: • Hilfreiche Techniken:
• Verwirrende • Komposition und Delegation
Klassenhierarchie • die GoF-Entwurfsmuster
• Hohe Kopplung (zur basieren oft darauf
Oberklasse) • Erlaubt Auswählen/Aus-
• evtl. ungünstige tauschen zur Laufzeit
Methodennamen
• Schlechtere Testbarkeit • Aber:
• Unsinnige Methoden mit • Evtl. ist Vererbung
geerbt einfacher zu verstehen
• Abwägung nötig
• Beispiel von
Melle Koning 2
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
28Favour Comp. over Inheritance (FCoI):
Negativbeispiele (zu wenig)
1. FCoI/apache-aries-MDBStats.java (lokal)
• Singleton-Klasse!
• benötigt von Oberklasse nur: manche Leseoperationen
• aber z.B. nicht: containsValue, put, putAll
2. Beispiel von https://de.wikipedia.org/w/index.php?title=Mixin&oldid=130573817
Aua!
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
29Integration/Operation Segregation
Principle (IOSP)
• Was? • Wofür?
• Unterscheide Methoden • Evolvierbarkeit
streng in zwei Sorten: • Korrektheit
• Operationen:
Kontrollstrukturen und
Fremd-API-Aufrufe
• aber keine Aufrufe der Häh? Wie soll das denn
eigenen Codebasis gehen? Kein 'if'?
• Integrationen: nur Aufrufe
anderer Methoden dieser
Codebasis
• Spezialfall des Single
oder: Responsibility Principle
• Aufrufer einer Methode (SRP)
verarbeitet nie selbst einen
• Orangener Grad
Rückgabewert
• [MsgProgModel]
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
30/46Übersicht
Prinzipien: Praktiken:
• Don't Repeat Yourself (DRY) • Pfadfinderregel befolgen
• Keep it simple, stupid • Root Cause Analysis
(KISS) durchführen (RCA)
• Vorsicht vor Optimierungen! • Versionskontrollsystem
• Favour Composition over einsetzen
Inheritance (FCoI) • Einfache Refaktorisierungen
• Integration/Operation anwenden
Segregation Principle (IOSP) • Extract Method, Rename
• Täglich reflektieren
Gestalt des Codes Eigenes Verhalten
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
31Pfadfinderregel befolgen
• Was? • (Anmerkung:
• [ClC], S.14: • in Wirklichkeit heißt es bei
"The Boy Scout Rule […] den Scouts nur:
• If we all checked-in our "Leave No Trace")
code a little cleaner than
when we checked it out, the • Wofür?
code simply could not rot. • Evolvierbarkeit
• The cleanup doesn’t have to
be something big.
• Change one variable name
• Hinderungsgrund:
for the better, • zu fokussiert auf aktuelles
• break up one function eigenes Ziel
that’s a little too large, • zu faul
• eliminate one small bit of • es ist schon alles super
duplication,
• clean up one composite if
statement."
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
32Pfadfinderregel befolgen
• Martin Fowler nennt das • Hilfreiche Techniken:
"Opportunistic Refactoring" • Code smells kennen
• dann sind eigene
Zeitabschnitte für
[Smells]
• Aber immer schön
2
Refactoring unnötig locker bleiben, bitte!
• weil sich Technische • IDE gut beherrschen
Schulden (technical debt) • Nicht ärgern, sondern
gar nicht erst ansammeln handeln
• siehe Dilbert
• [HowRefac]: Refactoring
nebenbei ("Zahnseide") ist
viel häufiger als
massenhaftes Refactoring
("Wurzelbehandlung")
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
33Pfadfinderregel befolgen:
Positivbeispiel
• Saros benutzt eine ganze Reihe Threads
• Für das Debugging ist es hilfreich, deren Zweck leicht
zuordnen zu können.
• Leider waren die Namen unsystematisch.
• Diese Änderung räumt (nur) diese Namen auf:
https://github.com/saros-project/saros/commit/7c9bae
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
34Pfadfinderregel befolgen:
Negativbeisp. ("broken window theory")
Broken Windows Theory
(Wikipedia)
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
35/46Pfadfinderregel befolgen:
Negativbeispiel (zu wenig) 2
• Dieser größere Patch für Saros fügt mehrere Tests zu
• auch ganze Klassen
• und räumt nebenbei einige Kleinigkeiten auf.
• Pfadfinderregel wird also angewendet!
• Dabei werden in JIDTest.java
• sowohl 2 neue Tests zugefügt (Z49-78neu) als auch
• zwei schlechte Namen verbessert (Z83,91).
• Leider gehören die beiden alten TO DO-Kommentare in Z80,88
jetzt eigentlich vor testMalformedJID (Z73) gezogen.
• Hier hat der Pfadfinder also geschlafen
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
36Root Cause Analysis durchführen (RCA)
• Was? • Hinderungsgrund:
• Wenn ein Problem auftritt • Kognitiv evtl. schwierig
(Defekt oder anderes), • Relevante Fakten oft
beseitige es nicht nur, schwierig zu ermitteln
sondern ermittle die ganze • Für die Betroffenen oft
Ursachenkette, um den Ur- peinlich
Grund (eine frühe Ursache)
abstellen zu können
• Wofür?
• Reflexion
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
37Root Cause Analysis durchführen (RCA)
• Phänomene ohne: • Hilfreiche Techniken:
• Prozessverbesserung erfolgt • Verletzte Prinzipien
nur langsam aufdecken
• Erfahrungslernen erfolgt • und dann weiter "Warum?"
nur langsam fragen
• Man erkennt Problemlagen • Gute Bücher oder Artikel zu
wieder, kann sich aber nicht denkbaren Ursachen lesen
mehr erinnern, wie sie sich • Kolleg_innen fragen
beim letzten Mal lösen
ließen
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
38Root Cause Analysis durchführen (RCA):
Nicht-Software-Beispiel
• Nach der Explosion des Space • Auslösender Grund des
Shuttle Challenger 1986 suchte Unfalls: Die Start-Entschei-
Richard Feynman in der Unter- dungsprozesse gaben den
Ingenieuren zu wenig Stimme.
suchungskommission auch
nach soziologischen Ursachen • Fazit (Urgrund): "[NASA
officials] must be realistic in
• Sein Ergebnis: making contracts, in estimating
• Direkter Grund: O-Ring costs, and the difficulty of the
undicht projects. […] For a successful
• Der war schon früher durch technology, reality must take
Beschädigungen aufgefallen. precedence over public
Diese waren unerwartet. relations, for nature cannot be
• Für Ingenieure bedeutet so fooled."
etwas höchste Alarmstufe.
• Management befand die
Konstruktion für flugtauglich,
wegen d. "Sicherheitsreserven"
• Die Reserven kennt man aber
nur, wenn man die Konstruk-
tionseigenschftn versteht. Das
war hier nicht der Fall.
•
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
39Versionskontrollsystem einsetzen
• Was? • Hinderungsgrund:
• Verwalte allen Quellcode • schreiende Ignoranz
und andere Artefakte des
ganzen Teams stets in einer
Versionsverwaltung
• Wofür?
• Korrektheit
• Produktionseffizienz
• Reflexion
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
40Versionskontrollsystem einsetzen
• Symptome ohne: • Hilfreiche Techniken:
• Strenge Eigentümerschaft • Just do it
von Code • Git verstehen
• Manuelle Absprachen über • Ziemlich kompliziert, aber
Änderungserlaubnis an für Könner unerhört
Datei X hilfreich
• Seltene Integration von • Git ist faktisch ein
Änderungen im Team Dateibaum-Änderungs-
• Defekte, die nach Editor
Beseitigung erneut
"auftauchen"
• Verlust von Quellcode
• ab dann: Änderungen auf
Assembler-Ebene
2
• Lesen: Kapitel
3, 7, A3 im
Pro Git Buch
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
41Versionskontrollsystem einsetzen:
Negativbeispiel
Ca. 1992:
• Bei der Entwicklung des Modula-2* Compilers trat
ein Defekt auf, dessen Debugging zwei Tage dauerte
• Zwei Wochen später nochmal einer gleicher Schwere
• Wieder langes Debugging
• Der stellte sich als derselbe heraus:
Ein Entwickler hatte die letzten Änderungen versehentlich
auf einer alten Kopie des Quellcode-Dateibaums gemacht
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
42Versionskontrollsystem einsetzen:
Arbeitsstil mit Git
• Änderungen werden in die • Vollendete Teil-Änderungen
kleinsten sinnhaltigen Teil- werden prompt auf den
Änderungen zerlegt, Hauptzweig vereint
• die noch in sich • Häufig, da Teil-Änd. klein
abgeschlossen sind. • Probleme selten, da
• Jede solche wird einzeln Vereinigung häufig
eingecheckt • Bei Problemen ist
• Mit einer klaren Lokalisierung einfach
Beschreibung • Nach Abschluss wird der
• Jede Änderung zunächst auf Zweig geschlossen
einem privaten Zweig • Er dokumentiert ggf.,
• Defekte beim welche Teil-Änderungen
Integrationstest lassen sich zusammen gehörten
dann ggf. leicht lokalisieren
• Durchsichten sind schnell http://git-scm.com/about
und effektiv
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
43Einfache Refaktorisierungen anwenden
(Extract Method, Rename)
• Was? • Hinderungsgrund:
• Benenne blöd benannte • Faulheit
Pakete, Klassen, Methoden, • Keine automatisierten Tests
Variablen, Parameter etc. vorhanden ( Angst)
um • Bei eigenem Code:
• Extrahiere kleine Hilfs- Man bemerkt das Problem
methoden aus unschön groß nicht
gewordenen Methoden • Bei fremdem Code:
Man ist evtl. zu sehr vom
• Wofür? Verstehen abgelenkt
• das sollte aber gerade das
• Evolvierbarkeit
Signal sein!
• Reflexion
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
44Einfache Refaktorisierungen anwenden
(Extract Method, Rename)
• Arten von Verletzungen: • Hilfreiche Techniken:
• kryptische Namen • Entsprechende IDE-
• nichtssagende Namen Operationen beherrschen
• irreführende Namen • und ihre Grenzen kennen
• hier sind dynamische
• mehrdeutige Namen
Sprachen im Nachteil!
• lange Methoden • und Code so schreiben,
• tiefe Verschachtelung in dass diese Grenzen wenig
Methoden stören
• Verletzungen von DRY oder • Kollegen nach Meinung über
SLA, SRP, LoD meinen Code fragen
• siehe nächste Wochen
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
45Einfache Refaktorisierungen anwenden:
Beispiele 1, 2
1. 2. Extract Method
• Rename instance variable createAccountMenuItem()
sarosSession session • Hier war zuvor das Prinzip
• 11x in 1 Datei Single Level of Abstraction
verletzt
• Rename method
accept run
• siehe nächste Woche
2
• 2x in 2 Dateien
• Es ist ein schlechtes
• Rename method Zeichen, wenn Methoden
start run mehrmals hintereinander
• 2x in 2 Dateien wachsen
• Dies ist in diesem Commit 2
kombiniert
• plus:
Exemplarvariable zugefügt,
toter Code entfernt
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
46Täglich reflektieren
• Was? • Hinderungsgrund:
• Reflektiere nach jedem • Angst vor der eigenen
Arbeitspaket: Unvollkommenheit
- Was war gut? • Denkfaulheit
- Was nicht? Warum?
- Was kann ich besser
machen? Wie? • Zeitnot darf kein
• Bilde genügend kleine Hinderungsgrund sein:
Arbeitspakete • Reflektion senkt Stress,
• ca. 0,5 bis 1 Tag weil man sich weniger als
Opfer der Umstände fühlt
• Wofür?
• Reflexion
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
47Täglich reflektieren
• Phänomene ohne: • Hilfreiche Techniken:
• Den "gleichen" Fehler • Aktuellen CCD-Grad
mehrfach machen checklistenartig durchgehen
• Dogmatisches Verfolgen • Vergleich mit ähnlichen
von Regeln Situationen ein Jahr zuvor
• Langsames Hinzulernen • Nach längerem Debugging
• Wenige Lernerfolge werden und übersehenen
bemerkt Anforderungen RCA machen
• Mit Kolleg_innen diskutieren
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
48Täglich reflektieren:
Positivbeispiel (gelungen)
• Ich habe mich mit dem TDD-Entwicklungsstil schwergetan
• Das war mir durch Reflektion klar bewusst
• Im Gespräch darüber mit einem TDD-Forscher fiel mir auf,
dass das mit meinem Denkstil (MBTI intuitive, d.h. top-down-
orientiert) zusammenhängen dürfte
• Beim späteren Lesen über TDD fiel mir deshalb
ein Rat sofort als sehr hilfreich auf:
Testliste vorab formulieren
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
49Übersicht
Prinzipien: Praktiken:
• Don't Repeat Yourself (DRY) • Pfadfinderregel befolgen
• Keep it simple, stupid • Root Cause Analysis
(KISS) durchführen (RCA)
• Vorsicht vor Optimierungen! • Versionskontrollsystem
• Favour Composition over einsetzen
Inheritance (FCoI) • Einfache Refaktorisierungen
• Integration/Operation anwenden
Segregation Principle (IOSP) • Extract Method, Rename
• Täglich reflektieren
Gestalt des Codes Eigenes Verhalten
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
50Hausaufgabe
(nächste Wochen gehen analog)
• Setzen Sie mindestens zwei • Stellen Sie uns das nächste
der heutigen Elemente in Woche vor
Ihrem Projekt ein • in max. 8 Minuten:
• möglichst 1 Prinzip und • Erinnerung an Projekt
1 Praktik • Ausgangssituation
• Gern auch mehr, • Probleme, Chancen
wenn es sich ergibt • Praktik
• Warum gerade diese?
• Einsatzweise
• Achtung: Wir interessieren
• Wir machen später noch uns für die Praktik,
einen zweiten Durchgang nicht für ihr Projekt
2
• Dann bitte andere • Kritik: Was war/ist gut,
Prinzipien/Praktiken was noch nicht?
auswählen • Reflektion:
Was nehme ich daraus mit?
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
51Danke!
AG Software Engineering, Institut für Informatik, Freie Universität Berlin
52Sie können auch lesen
