SlideShare ist ein Scribd-Unternehmen logo
Clean Coding
Theorie & Praxis Guide
Artem Kaftanenko
Dresden, 15.09.2016
Agenda
1. Einführung
 Lebenszyklus eines Chaos
 Chaos-Verursacher
 Leitfaden aus dem Chaos
 Professionelle Softwareentwicklung
 Lösungsansatz: Clean Code
2. Best Practice
 Namensgebung
 Funktionen
 Klassen
 Fehlerbehandlung
3. Ausblick
1.1 LEBENSZYKLUS
EINES CHAOS
Einführung
Seite 3
Einführung - Lebenszyklus eines Chaos
… Produktivitätsentwicklung
Seite 4
Zeit
Produktivität
Chaotische Entwicklung
Wunschentwicklung
Literaturklischee
Einführung - Lebenszyklus eines Chaos
… eine der wichtigsten Ursachen
Schlechter Code!
Seite 5
Einführung - Lebenszyklus eines Chaos
… Erkennungsmerkmale
 hohe Code-Redundanz
 unlesbar / schwer verständlich
 viele schwer nachvollziehbare Abhängigkeiten
 mehrere Lösungsvariationen für dieselben Probleme
 hohe unproduktive Aufwände, z.B. für
 Bug-Analyse und –Fixing
 Kommunikation mit Kollegen bzw. Kunde
 „Studieren“ von Spezifikationen / Pflichtenheften
Seite 6
Einführung - Lebenszyklus eines Chaos
… Konsequenzen (1)
1. Sehr hohe Einarbeitungszeiten (bei jeder einzelnen Aufgabe)
 für Einsteiger
 aber auch für Erfahrene
2. Sehr hohes Risiko bzgl. Folgefehler bei jeder kleinsten Code-Anpassung
 auch in Komponenten, deren Verantwortlichkeiten mit der aktuellen Änderung
eigentlich nichts zu tun haben
3. Sehr hoher Aufwand beim Anpassen allgemeiner Funktionalitäten
 jede einzelne (redundant) implementierte Funktionalität muss nachgezogen werden
 jede davon betroffene Komponente muss erneut getestet werden
Seite 7
Einführung - Lebenszyklus eines Chaos
… Konsequenzen (2)
4. Veranlagung zur kontinuierlich schlechten Produktqualität
 kann teilweise durch extrem hohe Testaufwände gemindert werden, aber nur unter
se-e-ehr bestimmten Bedingungen und nie auf Dauer
5. Schwer vorhersagbare Folgen einer neuen / geänderten Anforderung wg.
 unüberschaubaren Abhängigkeiten
6. Frustriertes Projektteam, das dauerhaft wie auf einem Vulkan lebt
7. Frustration und Unsicherheitsgefühl bis zu obersten Kundenetagen
Seite 8
1.2 CHAOS-
VERURSACHER
Einführung
Seite 9
Einführung - Chaos-Verursacher
Wer könnte es sein?
Ratet mal …
 Kunde?
 Vertrieb?
 Eigenes Management?
 … vielleicht andere „höhere Gewalt“?
Seite 10
Einführung - Chaos-Verursacher
… bittere Erkenntnis / primäre Ursache
Nein!
… das waren und sind WIR!
unser Entwicklerteam
und zwar durch unsere Unprofessionalität
Seite 11
1.3 LEITFADEN AUS DEM
CHAOS
Einführung
Seite 12
Einführung - Leitfaden aus dem Chaos
Professionelle Softwareentwicklung (1)
"Softwareentwicklung braucht Profis. Was aber sind Profis? Menschen die mit
der Softwareentwicklung Geld verdienen? Nein, ..., es gehört mehr und anderes
dazu. Professionalität in der Softwareentwicklung hat nichts mit Geld zu tun.
Sie hat auch nur bedingt mit einem bestimmten Ausbildungsweg zu tun.
<Es gibt> ... professionelle Softwareentwickler, die wenig oder gar kein Geld mit
ihrer Software verdienen und <es gibt> ... professionelle Softwareentwickler, die
weder Diplom noch Doktortitel haben.„
http://clean-code-developer.de (Stand: 10.05.2011)
Seite 13
Einführung - Leitfaden aus dem Chaos
Professionelle Softwareentwicklung (2)
Ein professioneller Softwareentwickler setzt sich mit dem Metier bewusst
auseinander. D.h. er reflektiert über sein Produkt, seine Arbeitsweise, seine
Materialien und Werkzeuge.
Ein professioneller Softwareentwickler ist nicht einfach zufrieden, wenn sein
Chef oder Kunde zufrieden sind. Er ist auch nicht einfach mit dem zufrieden, was
ein Hersteller ihm empfiehlt.
Stattdessen beobachtet und prüft er ständig seine Ergebnisse und bemüht sich
um die Weiterentwicklung seiner selbst wie auch des Metiers.
Seite 14
Einführung - Leitfaden aus dem Chaos
Professionelle Softwareentwicklung (3)
Ein professioneller Softwareentwickler hat ein inneres Wertesystem.
Gegen dieses Wertesystem prüft er seine Ergebnisse und Handlungen. Nur,
wenn seine Arbeit diesem Wertesystem entspricht, empfindet er sie als gut
getan, als professionell.
Sein Streben ist es daher, auch unter widrigen Umständen, unter Druck von
Kunden oder Herstellern, diesem Wertesystem treu zu sein.
Professionalität = Bewusstheit + Prinzipien
http://clean-code-developer.de (Stand: 24.07.2013)
Seite 15
1.4 Professionelle
Softwareentwicklung
Einführung
Seite 16
Einführung – Professionelle Softwareentwicklung
Zielbild (1)
Kunde
 Implementierung = Wunsch (im Endeffekt)
 Kosten der Änderungswünsche realistisch abschätzbar
Endbenutzer
 wenige Bugs
 schnelle Bug-Beseitigung
Projektleiter (PL)
 realistisch abschätzbare Implementierungsaufwände
 höhes Vertrauensniveau an die Entwicklung
Seite 17
Einführung – Professionelle Softwareentwicklung
Zielbild (2)
Softwarearchitekt (SWA)
 sauberes und überschaubares Design auch auf Implementierungs-Niveau
 leicht kontrollierbares Qualitätsniveau
 motiviert reguläre Aktualisierung der Style-Guides
 Implementierung mit den Anforderungen (leicht) abgleichbar
Entwickler
 schneller Einstieg
 leichte Nachvollziehbarkeit des Fremdcodes
 Lerneffekt ebenfalls sauber zu programmieren
 gutes Gefühl seine Pflichte zu 100% erfüllt zu haben
Seite 18
1.5 LÖSUNGSANSATZ:
CLEAN CODE
Einführung
Seite 19
Einführung – Lösungsansatz: Clean Code
Clean Code ist … (1)
Bjarne Stroustrup
 … Erfinder von C++ und Autor von “The C++ Programming Language“
Mein Code sollte möglichst elegant und effizient sein.
… die Logik sollte grandlinig sein, damit sich Bugs nur schwer verstecken können
… die Abhängikeiten sollten minimal sein, um die Wartung zu vereinfachen
… das Fehler-Handling sollte vollständig gemäß einer vordefinierten Strategie erfolgen
… das Leistungsverhalten sollte dem Optimum so nah wie möglich kommen, damit der
Entwickler nicht versucht ist, den Code durch Ad-hoc-Optimierungen zu verunstalten
Sauberer Code erledigt eine Aufgabe gut.
Seite 20
Einführung – Lösungsansatz: Clean Code
Clean Code ist … (2)
Grady Booch
 … Autor von “Object Oriented Analysis and Design with Applications“
Sauberer Code:
• … ist einfach und direct.
• … liest sich wie wohlgeschriebene Prosa.
• … verdunkelt niemals die Absicht des Designers, sondern ist voller griffiger
(engl. crisp) Abstraktionen und geradliniger Kontrollstukturen.
Seite 21
Einführung – Lösungsansatz: Clean Code
Clean Code ist … (3)
“Big” Dave Thomas
 ... Gründer der OTI, der Pate der Eclipse-Strategie
Sauberer Code kann von anderen Entwickler gelesen und verbessert werden.
… verfügt über Unit- und Acceptance-Tests.
… erhält bedeutungsvolle Namen.
… stellt zur Lösung einer Aufgabe nicht mehrere, sondern eine Lösung zur Verfügung.
… erhält minimale Abhängigkeiten, die ausdrücklich definiert sind, und stellt ein klares
und minimales API zur Verfügung.
… sollte “literate” sein, da je nach Sprache nicht alle erforderliche Informationen allein im
Code klar ausgedrückt werden können.
Seite 22
Einführung – Lösungsansatz: Clean Code
Clean Code ist … (4)
Dirty Code = Schlechter Code
 „natürlich“ entstandener Code
 gefährdet
 Langlebigkeit eines SW-Produktes
 seine Stabilität und Erweiterbarkeit
Clean Code = Guter Code
 legt einen besonderen Wert auf
 Lesbarkeit
 Nebeneffektfreiheit
 Isolierung der Systemänderungen
Seite 23
Einführung – Lösungsansatz: Clean Code
… und den Preis fürs Vergnügen
Mehrkosten
• fraglich, aber eher so gut wie keine + langfristige Spareffekte
• der einzige Unterschied: natürliches/ungeübtes vs. systematisches Vorgehen
Mehrwerte
• meidet Kreativitätskrisen beim Entwicklungsteam
• leicht gemachter fachlichen Einstieg für die Neueinsteiger
• Synergieeffekte durch etwa gleichen Gedankenfluss / Vorgehensweise, z.B.:
• Code-Konsistenz
• niedrige Redundanz
• gute Modifizierbarkeit
• hohe Wiederverwendungsgrad
• Grundlage für rechtzeitige Refactoring
Seite 24
Einführung – Lösungsansatz: Clean Code
Weiterführende Informationen
Seite 25
[MR09] Clean Code: A Handbook of
Agile Software Craftsmanship;
Robert C. Martin (aka Uncle Bob)
ISBN-13: 978-0132350884
[CCD] Clean Code Developer –
Initiative von Ralf Westphal und
Stefan Lieser
2.1 NAMENSGEBUNG
Clean Code - Best Practice
Seite 26
13.05.2011
Clean Coding - Theory & Praxis Guide
27
Clean Code – Namensgebung (1)
…
Charakteristik guter Namen
 aussagekräftig
 aussprechbar
 auffindbar (IDE)
 eindeutig & klar
Auswahl der Schlüsselwörter
 ein Wort per Konzept
 aus der Domainsprache
=> (Problem/Lösungs-Domain)
 Verwenden von Namenskonventionen
=> z. Bsp. für Funktionen: is<…>, set<…>, get<…>, …
13.05.2011
Clean Coding - Theory & Praxis Guide
28
Clean Code – Namensgebung (2)
…
Prinzipien
 Mehrdeutigkeit vermeiden
 Desinformationen vermeiden
=> „say what you mean, mean what you say.“
 aussagekräftigen Kontext verwenden
=> meist durch gut benannte Klassen, Funktionen und andere Namensräume gegeben
=> wenn kein klarer Kontext gegeben, muss dieser ein Teil des Namens sein
 Verwendung desselben Schlüsselworts für mehrere Konzepte vermeiden
 Typ/Scope/Mitgliedschaft bedingte Präfixe vermeiden
13.05.2011
Clean Coding - Theory & Praxis Guide
29
Clean Code – Namensgebung (3)
…
Gute Namen zu finden ist schwierig, aber
 zahlt sich sehr schnell aus
 animiert zur Suche nach einem Konsensus
 schafft gemeinsame Basis für alle Entwickler
 trägt der inkrementeller Entstehung von DSL bei
2.2 FUNKTIONEN
Clean Code - Best Practice
Seite 30
13.05.2011
Clean Coding - Theory & Praxis Guide
31
Clean Code – Funktionen
Einführung (1)
Funktionen
… sollten eine Aufgabe erledigen.
… sollten sie gut erledigen.
… sollten nur diese Aufgabe erledigen.
Diese Beschreibung
 bestimmt die Größe der Funktion
 sichert ihre Nebeneffekt-Freiheit
 weist auf die Auswahl der Funktionsnamen hin
13.05.2011
Clean Coding - Theory & Praxis Guide
32
Clean Code - Funktionen
Einführung (2)
Funktionsgröße
Regel 1: … muss KLEIN sein
Regel 2: … muss noch KLEINER sein
Funktionsname
… soll deskriptiv sein
… soll beschreiben WAS die Funktion tut
… soll beschreiben ALLES was die Funktion tut
Eine Funktion ist sauber wenn:
… implementiert nur eine einzige Handlung
… implementiert Handlung nur eines Abstraktionsniveaus
… ihre Funktionalität ist durch Funktionsnamen vollständig beschrieben
=> Nebeneffekt-Freiheit
13.05.2011
Clean Coding - Theory & Praxis Guide
33
Clean Code - Funktionen
Logikfluss
Als Ergebnis
 viele kurze Funktionen (3-10 Zeilen)
 nicht selten eine Funktion nur von einer einzigen Stelle aufgerufen
„Step-Down“-Regel
 aufzurufende nach den aufrufenden Funktionen (vertikale Anordnung)
Gruppierung der Funktionen
 die einander aufrufen
 die ähnliche Funktionalität umsetzen
 die die gleichen Objekte bzw. Instanzvariablen behandeln
sich wiederholende Switch-Anweisungen
 meist durch Polymorphie lösbar
13.05.2011
Clean Coding - Theory & Praxis Guide
34
Clean Code - Funktionen
Benennung
Muss ein Verb enthalten
Namenskonventionen wichtig
 dieselben Verben für dieselben Handlungen
=> Bsp.: get, set, is, find, query, check, enrich, …
Schlüsselwörter aus der Domainsprachen
… sonst der allgemeinen Regeln der Namensgebung folgen (s. oben)
13.05.2011
Clean Coding - Theory & Praxis Guide
35
Clean Code - Funktionen
Argumente (1)
Argumentenanzahl
keine Argumente
ist ideal => ganzen Zustand durch Instanzvariablen bestimmt
ein Argument
… prüft Annahmen
=> Rückgabe: boolesche Typ boolean fileExists(“MyFile”)
… behandelt Ereignisse
=> keine Rückgabe void onDataLoad(Event event)
… transformiert dieses Argument/Objekt
=> Rückgabe: transformiertes Objekt InputStream fileOpen(“MyFile”)
13.05.2011
Clean Coding - Theory & Praxis Guide
36
Argumentenanzahl
zwei Argumente
assertEquals(expected, actual)
=> leicht zu verwechselnde Reihenfolge gleichartiger Argumenten
p = new Point(0,0);
=> sind geordnete Bestandteile desselben Wert-Objekts!
drei Argumente
assertEquals(message, expected, actual)
=> leicht zu verwechselnde Reihenfolge gleichartiger Argumenten
assertEquals(1.0, amount, .001)
=> sind fachlich bedingt (Vergleich von zwei Floatpoint-Werten ist nur mit
einem Genauigkeitsgrad möglich)
Clean Code - Funktionen
Argumente (2)
13.05.2011
Clean Coding - Theory & Praxis Guide
37
Clean Code - Funktionen
Argumente (3)
Argumentanzahl
mehr als drei Argumente
eindeutiges Warnsignal zum Refactoren
Mittel zur Reduzierung der Argumentanzahl:
… in Instanzvariablen umwandeln
… in Wrapper-Klassen kapseln
… Funktion in Kontext eines der Argumente verschieben, z.B.:
<some-class>.write (outputStream, name) => outputStream.write (name)
13.05.2011
Clean Coding - Theory & Praxis Guide
38
Clean Code - Funktionen
Argumente (4)
Argumentarten
Flag-Argumente (boolesche)
=> verletzt „do one thing“-Regel
in/out Argumente
=> Nebeneffekte
=> verschlechtern Nachvollziehbarkeit
Argument-Listen
=> wenn diese gleich behandelt werden = ein Argument vom List-Typ
=> im übrigen dieselben Begrenzungen auf die Argumentenanzahl
13.05.2011
Clean Coding - Theory & Praxis Guide
39
Clean Code - Funktionen
Fehlerbehandlung
Exception werfen bevorzugt über Rückgabe eines ErrorCode‘s
Fehlerbehandlung = one thing
=> in die Extrafunktion auslagern
… sonst ist dies das Thema für eine Extrapräsentation.
2.3 KLASSEN
Clean Code - Best Practice
Seite 40
13.05.2011
Clean Coding - Theory & Praxis Guide
41
Clean Code - Klassen
Einführung
… es gibt eine gewisse Korrelation mit den Anforderungen zu den Funktionen
Klassengröße
Regel 1: … muss KLEIN sein
Regel 2: … muss noch, Ihr wisst schon, KLEINER sein
Klassenname
… soll deskriptiv sein
… soll beschreiben WOFÜR die Klasse verantwortlich ist
… soll beschreiben ALLES WOFÜR die Klasse verantwortlich ist
13.05.2011
Clean Coding - Theory & Praxis Guide
42
Clean Code - Klassen
Klassenorganisation – Responsibility-Merkmal
Single Responsibility Principle (SRP)
public class SuperDashboard extends JFrame implements MetaDataUser
public String getCustomizerLanguagePath()
public void setSystemConfigPath(String systemConfigPath)
public String getSystemConfigDocument()
public void setSystemConfigDocument(String systemConfigDocument)
public boolean getGuruState()
public boolean getNoviceState()
public boolean getOpenSourceState()
public void showObject(MetaObject object)
public void showProgress(String s)
public void setIsMetadataDirty(boolean isMetadataDirty)
public Component getLastFocusedComponent()
public void setLastFocused(Component lastFocused)
public void setMouseSelectState(boolean isMouseSelected)
public boolean isMouseSelected()
public LanguageManager getLanguageManager()
public Project getProject()
public Project getFirstProject()
public Project getLastProject()
public String getNewProjectName()
13.05.2011
Clean Coding - Theory & Praxis Guide
43
Clean Code - Klassen
Klassenorganisation – Responsibility-Merkmal
Single Responsibility Principle (SRP)
public class SuperDashboard extends JFrame implements MetaDataUser
public String getCustomizerLanguagePath()
public void setSystemConfigPath(String systemConfigPath)
public String getSystemConfigDocument()
public void setSystemConfigDocument(String systemConfigDocument)
public boolean getGuruState()
public boolean getNoviceState()
public boolean getOpenSourceState()
public void showObject(MetaObject object)
public void showProgress(String s)
public void setIsMetadataDirty(boolean isMetadataDirty)
public Component getLastFocusedComponent()
public void setLastFocused(Component lastFocused)
public void setMouseSelectState(boolean isMouseSelected)
public boolean isMouseSelected()
public LanguageManager getLanguageManager()
public Project getProject()
public Project getFirstProject()
public Project getLastProject()
public String getNewProjectName()
public class SuperDashboard extends JFrame {
public Component getLastFocusedComponent()
public void setLastFocused(Component lastFocused)
public int getMajorVersionNumber()
public int getMinorVersionNumber()
public int getBuildNumber()
}
13.05.2011
Clean Coding - Theory & Praxis Guide
44
Clean Code - Klassen
Klassenorganisation – Responsibility-Merkmal
Single Responsibility Principle (SRP)
public class SuperDashboard extends JFrame implements MetaDataUser
public String getCustomizerLanguagePath()
public void setSystemConfigPath(String systemConfigPath)
public String getSystemConfigDocument()
public void setSystemConfigDocument(String systemConfigDocument)
public boolean getGuruState()
public boolean getNoviceState()
public boolean getOpenSourceState()
public void showObject(MetaObject object)
public void showProgress(String s)
public void setIsMetadataDirty(boolean isMetadataDirty)
public Component getLastFocusedComponent()
public void setLastFocused(Component lastFocused)
public void setMouseSelectState(boolean isMouseSelected)
public boolean isMouseSelected()
public LanguageManager getLanguageManager()
public Project getProject()
public Project getFirstProject()
public Project getLastProject()
public String getNewProjectName()
public class SuperDashboard extends JFrame {
public Component getLastFocusedComponent()
public void setLastFocused(Component lastFocused)
public int getMajorVersionNumber()
public int getMinorVersionNumber()
public int getBuildNumber()
}
public class Version {
public int getMajorVersionNumber()
public int getMinorVersionNumber()
public int getBuildNumber()
}
13.05.2011
Clean Coding - Theory & Praxis Guide
45
Clean Code - Klassen
Klassenorganisation – Kohäsion-Merkmal
Clean-Code-Anforderung zu den Funktionen – Minimierung der Argumentenanzahl
als Folge – viele kleinere Funktionen
der ganze Objektzustand ist durch seine Instanzvariablen präsentiert
Wenn eine Untermenge der Instanzvariablen ausschließlich von einer Untermenge der
Klassenmethoden benutzt wird => Warnsignal zur Klassen-Spaltung
13.05.2011
Clean Coding - Theory & Praxis Guide
46
Clean Code - Klassen
Klassenorganisation – Änderungsrisiko-Merkmal
Moderne SW-Systeme sind permanenten Änderungen unterworfen
Änderung eines Systemteils => Systemrest funktioniert nicht mehr als erwartet
Aus diesem Grund sollte man das System so organisieren, damit die Funktionalität der nicht
angefassten Systemteile erhalten bleibt
2.4 FEHLERBEHANDLUNG
Clean Code - Best Practice
Seite 47
13.05.2011
Clean Coding - Theory & Praxis Guide
48
Clean Code – Fehlerbehandlung (1)
…
Ausnahmen statt Rückgabe-Codes
• Problem von Rückgabe-Codes:
• veraltete Technik
• begrenzter Informationsgehalt im Ausnahme-Fall
• Zwang den Code direkt an der aufrufenden Stelle zu prüfen
• Lösungsansatz:
• Exceptions / Ausnahmen werfen
Ausnahmen mit Kontext auslösen
• Zweck:
• Nachvollziehbarkeit und Reproduzierbarkeit des Fehlerfalls
• Lösungsansätze:
• informative Fehlermeldungen
• spezialisierte Exception-Klassen mit entsprechenden Fach-Properties
13.05.2011
Clean Coding - Theory & Praxis Guide
49
Clean Code – Fehlerbehandlung (2)
…
Exception-Klassen aus Sicht des Aufrufers
• Zweck:
• Eingrenzung nur auf die für Aufrufer relevante Ausnahmefälle
• Bewertung der internen Ausnahmefälle aus der fachlichen Sicht
• Lösungsansätze:
• Erstellung eigener fachlichen Exception-Klassensätzen:
• wird zur Bestandteil von API und des API-Vertrags
• Einhüllung der internen oft technischen Exception in die fachlichen
Checked Exceptions
• Problem:
• Abfangstelle oft weit weg vom eigentlichen Aufruf
• unnötige Exception-Deklarationen in zahlreichen Funktion-Signaturen
• Lösungsansatz:
• im Allgemeinen: keine mehr einsetzen!
• Ausnahme: kritische Bibliotheken bzw. ihre API
13.05.2011
Clean Coding - Theory & Praxis Guide
50
Clean Code – Fehlerbehandlung (3)
…
Try-Catch-Finally Anweisungen
• bestimmen Geltungsbereich
• sind ähnlich dem Transaktionen-Konzept
• somit muss catch-Code das Programm im konsistenten Stand zurücklassen
• müssen möglichst zuerst geschrieben werden, bevor Geschäftslogik im try-Abschnitt
Den normalen Ablauf definieren
• …
13.05.2011
Clean Coding - Theory & Praxis Guide
51
Clean Code – Fehlerbehandlung (4)
…
Keine Null zurückgeben
Keine Null übergeben
• Themen wurden in einer der Architektur-Runden abgesprochen, für mehr:
• Wiki: Richtlinien: Quellcode / Umgang mit NULL-Werten
Ausblick
Seite 52
13.05.2011
Clean Coding - Theory & Praxis Guide
53
Clean Code - Ausblick
 Formatierungsregeln
 Kommentare
 Unit Tests
 Nebenläufigkeit
 Fehlerbehandlung
 Allgemeine Systemaufbau
 …
Weitere hier nicht behandelte Themen
13.05.2011
Clean Coding - Theory & Praxis Guide
54
Clean Code - Ausblick
Heuristiken - Beispiele (1)
Comments
C1: Inappropriate Information
C2: Obsolete Comment
C3: Redundant Comment
C4: Poorly Written Comment
C5: Commented-Out Code
Environment
E1: Build Requires More Than One Step
E2: Tests Require More Than One Step
Functions
F1: Too Many Arguments
F2: Output Arguments
F3: Flag Arguments
F4: Dead Function
13.05.2011
Clean Coding - Theory & Praxis Guide
55
Clean Code - Ausblick
Heuristiken - Beispiele (2)
General
G1: Multiple Languages in One Source File
G2: Obvious Behavior Is Unimplemented
G3: Incorrect Behavior at the Boundaries
G4: Overridden Safeties
G5: Duplication
G6: Code at Wrong Level of Abstraction
G7: Base Classes Depending on Their Derivatives
...
… und viele anderen sind im [MR09] zu finden.
PRAXIS GUIDE
Sample Slides utilizing the
template features of Powerpoint
2010
Seite 56
13.05.2011
Clean Coding - Theory & Praxis Guide
57
Praxis Guide
Aufgabenstellung
Ausgangsdaten für die Entwickler
Fachliche Spezifikation des zu realisierenden Systems
 durch Fachabteilung/Analysten erarbeitet
 mittels Dekomposition des Gesamtsystems in
 Fachbereiche/Fachklassen
 fachliche Abhängigkeiten/Operationen
Aufgabe des Entwicklers
Umsetzung dieser Spezifikation
13.05.2011
Clean Coding - Theory & Praxis Guide
58
Praxis Guide
Fachliche Abstraktionsniveau
Businesslogik (BL) Schnittstelle
 spiegelt die Fachspezifikation auf die Implementierungssprache
… um Implementierung mit der Spezifikation abgleichbar zu halten
=> Verwendung einer fachlichen DSL nötig
 muss beschreiben WAS implementiert werden muss
=> Strukturierungseinheiten: Aggregate, Fachklassen, …
=> nächste Hierarchiestufe: Businessoperationen
Businesslogik Implementierung
 muss das WIE beschreiben, aber immerhin im Scope des BL-Abstraktionsniveaus
 evtl. zwischen mehreren Aggregaten teilbaren lower-level BL-Framework
 immerhin Realisierung in den Begriffen einer fachlichen DSL
13.05.2011
Clean Coding - Theory & Praxis Guide
59
Praxis Guide
Technische Abstraktionsniveau
Frameworks
 commons
 Datenpersistenz
 Dependency Injection
 …
(Kommunikations-) Schnittstellen zu anderen Systemen
 JMS
 FTP
 Email
 …
13.05.2011
Clean Coding - Theory & Praxis Guide
60
Praxis Guide
Clean Coding – Verfahren (1)
Inkrementelle Verbesserung des Codes, rechtzeitigen Reviews/Refactorings
Einhaltung der Grenzen einzelner Abstraktionsebenen
 auf Schnittstellen-Niveau
 innerhalb der Implementierung einzelner Funktionen
Passende Benennung der Artefakte
 Pakete/Module
 Klassen
 Funktionen und ihre Argumente
 Instanz- bzw. lokale Variablen
 …
Eindeutiger Kontext
13.05.2011
Clean Coding - Theory & Praxis Guide
61
Praxis Guide
Clean Coding – Verfahren (2)
Suche nach passender Benennung führt zu richtigen Designentscheidungen
 Pakete/Klassen/Funktionen/… (Kontexte)
 zu spezialisieren bzw. zu generalisieren
 zu spalten bzw. in anderen Kontext auszulagern
 die Artefakte ähnlicher Abstraktionsniveau/Funktionalität landen in den
naheliegenden/denselben Kontexten und werden sogar oft ähnlich/gleich benannt
 erleichtert Identifikation der Artefakte mit gleicher/ähnlicher Funktionalität
 ermöglicht beste Implementierung auszuwählen und Redundanzen zu beseitigen
13.05.2011
Clean Coding - Theory & Praxis Guide
62
Theorie & Praxis Guide
[MR09] Clean Code: A Handbook of
Agile Software Craftsmanship;
Robert C. Martin (aka Uncle Bob)
ISBN-13: 978-0132350884
Weiterführende Informationen
[CCD] Clean Code Developer –
Initiative von Ralf Westphal und
Stefan Lieser
Deutschland
IMPAQ GmbH & Co. KG
Clemensstraße 10
D - 60487 Frankfurt
Phone: +49 69 92 00 80 0
Schweiz
IMPAQ AG
Flurstrasse 32
Postfach
CH-8066 Zürich
Phone: +41 44 4 05 21 00
Weitere Informationen zur IMPAQ Gruppe und unseren
Niederlassungen finden Sie auf: www.impaqgroup.com
Name
Job Title
IMPAQ Location
Street xxx
Post
Country – Postcode City
Phone: +country code (number)
Fax: +country code (number)
 email@impaqgroup.com
 www.impaqgroup.com
Wir freuen uns auf
Ihre Kontaktaufnahme
United Kingdom
IMPAQ UK Ltd.
9 Bridle Close
Surbiton Road
Kingston upon Thames
Surrey KT1 2JW
Phone: +44 20 85 49 2133
Polen
IMPAQ Sp. z o.o.
ul. Wołoska 22
02-675 Warsaw
Phone: +48 22 31 46 000

Weitere ähnliche Inhalte

Ähnlich wie Clean Coding - Theorie und Praxis Guide.pptx

Die wichtigsten Technologien für die Entwicklung von Webanwendungen
Die wichtigsten Technologien für die Entwicklung von WebanwendungenDie wichtigsten Technologien für die Entwicklung von Webanwendungen
Die wichtigsten Technologien für die Entwicklung von Webanwendungen
YUHIRO
 
BASTA! Spring 2017 - Warum warten auf die IDE? Direct Coding in der eigenen A...
BASTA! Spring 2017 - Warum warten auf die IDE? Direct Coding in der eigenen A...BASTA! Spring 2017 - Warum warten auf die IDE? Direct Coding in der eigenen A...
BASTA! Spring 2017 - Warum warten auf die IDE? Direct Coding in der eigenen A...
Robin Sedlaczek
 
Mehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean CodingMehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-CleancodingMehr Softwarequalität: Team-Cleancoding
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-UmgebungDas Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
OPITZ CONSULTING Deutschland
 
Top 10 Internet Trends 2001
Top 10 Internet Trends 2001Top 10 Internet Trends 2001
Top 10 Internet Trends 2001
Jürg Stuker
 
Oracle Forms: How to create a Framework
Oracle Forms: How to create a FrameworkOracle Forms: How to create a Framework
Oracle Forms: How to create a Framework
OPITZ CONSULTING Deutschland
 
WordPress sprachfähig machen - Lokalisierung Kür oder Krampf? - WordCamp Deut...
WordPress sprachfähig machen - Lokalisierung Kür oder Krampf? - WordCamp Deut...WordPress sprachfähig machen - Lokalisierung Kür oder Krampf? - WordCamp Deut...
WordPress sprachfähig machen - Lokalisierung Kür oder Krampf? - WordCamp Deut...
David Decker
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Markus Unterauer
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Andreas Schreiber
 
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
OPEN KNOWLEDGE GmbH
 
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareAndreas Schreiber
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Mastering architecture, design- and code-quality
Mastering architecture, design- and code-qualityMastering architecture, design- and code-quality
Mastering architecture, design- and code-quality
Sebastian Dietrich
 
Plone im Kontext des WCMS Marktes
Plone im Kontext des WCMS MarktesPlone im Kontext des WCMS Marktes
Plone im Kontext des WCMS Marktes
Alexander Loechel
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
ChristinaLerch1
 
Froscamp2010_padre
Froscamp2010_padreFroscamp2010_padre
Froscamp2010_padre
Renee Baecker
 
Architectures for .Net Core Applications
Architectures for .Net Core ApplicationsArchitectures for .Net Core Applications
Architectures for .Net Core Applications
Robin Sedlaczek
 
Authoring Management
Authoring ManagementAuthoring Management
Authoring Management
vzimmermann
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
Claudia Haußmann 🦋
 

Ähnlich wie Clean Coding - Theorie und Praxis Guide.pptx (20)

Die wichtigsten Technologien für die Entwicklung von Webanwendungen
Die wichtigsten Technologien für die Entwicklung von WebanwendungenDie wichtigsten Technologien für die Entwicklung von Webanwendungen
Die wichtigsten Technologien für die Entwicklung von Webanwendungen
 
BASTA! Spring 2017 - Warum warten auf die IDE? Direct Coding in der eigenen A...
BASTA! Spring 2017 - Warum warten auf die IDE? Direct Coding in der eigenen A...BASTA! Spring 2017 - Warum warten auf die IDE? Direct Coding in der eigenen A...
BASTA! Spring 2017 - Warum warten auf die IDE? Direct Coding in der eigenen A...
 
Mehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean CodingMehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean Coding
 
Mehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-CleancodingMehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-Cleancoding
 
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-UmgebungDas Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
 
Top 10 Internet Trends 2001
Top 10 Internet Trends 2001Top 10 Internet Trends 2001
Top 10 Internet Trends 2001
 
Oracle Forms: How to create a Framework
Oracle Forms: How to create a FrameworkOracle Forms: How to create a Framework
Oracle Forms: How to create a Framework
 
WordPress sprachfähig machen - Lokalisierung Kür oder Krampf? - WordCamp Deut...
WordPress sprachfähig machen - Lokalisierung Kür oder Krampf? - WordCamp Deut...WordPress sprachfähig machen - Lokalisierung Kür oder Krampf? - WordCamp Deut...
WordPress sprachfähig machen - Lokalisierung Kür oder Krampf? - WordCamp Deut...
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
 
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
 
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
 
Mastering architecture, design- and code-quality
Mastering architecture, design- and code-qualityMastering architecture, design- and code-quality
Mastering architecture, design- and code-quality
 
Plone im Kontext des WCMS Marktes
Plone im Kontext des WCMS MarktesPlone im Kontext des WCMS Marktes
Plone im Kontext des WCMS Marktes
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
 
Froscamp2010_padre
Froscamp2010_padreFroscamp2010_padre
Froscamp2010_padre
 
Architectures for .Net Core Applications
Architectures for .Net Core ApplicationsArchitectures for .Net Core Applications
Architectures for .Net Core Applications
 
Authoring Management
Authoring ManagementAuthoring Management
Authoring Management
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
 

Clean Coding - Theorie und Praxis Guide.pptx

  • 1. Clean Coding Theorie & Praxis Guide Artem Kaftanenko Dresden, 15.09.2016
  • 2. Agenda 1. Einführung  Lebenszyklus eines Chaos  Chaos-Verursacher  Leitfaden aus dem Chaos  Professionelle Softwareentwicklung  Lösungsansatz: Clean Code 2. Best Practice  Namensgebung  Funktionen  Klassen  Fehlerbehandlung 3. Ausblick
  • 4. Einführung - Lebenszyklus eines Chaos … Produktivitätsentwicklung Seite 4 Zeit Produktivität Chaotische Entwicklung Wunschentwicklung Literaturklischee
  • 5. Einführung - Lebenszyklus eines Chaos … eine der wichtigsten Ursachen Schlechter Code! Seite 5
  • 6. Einführung - Lebenszyklus eines Chaos … Erkennungsmerkmale  hohe Code-Redundanz  unlesbar / schwer verständlich  viele schwer nachvollziehbare Abhängigkeiten  mehrere Lösungsvariationen für dieselben Probleme  hohe unproduktive Aufwände, z.B. für  Bug-Analyse und –Fixing  Kommunikation mit Kollegen bzw. Kunde  „Studieren“ von Spezifikationen / Pflichtenheften Seite 6
  • 7. Einführung - Lebenszyklus eines Chaos … Konsequenzen (1) 1. Sehr hohe Einarbeitungszeiten (bei jeder einzelnen Aufgabe)  für Einsteiger  aber auch für Erfahrene 2. Sehr hohes Risiko bzgl. Folgefehler bei jeder kleinsten Code-Anpassung  auch in Komponenten, deren Verantwortlichkeiten mit der aktuellen Änderung eigentlich nichts zu tun haben 3. Sehr hoher Aufwand beim Anpassen allgemeiner Funktionalitäten  jede einzelne (redundant) implementierte Funktionalität muss nachgezogen werden  jede davon betroffene Komponente muss erneut getestet werden Seite 7
  • 8. Einführung - Lebenszyklus eines Chaos … Konsequenzen (2) 4. Veranlagung zur kontinuierlich schlechten Produktqualität  kann teilweise durch extrem hohe Testaufwände gemindert werden, aber nur unter se-e-ehr bestimmten Bedingungen und nie auf Dauer 5. Schwer vorhersagbare Folgen einer neuen / geänderten Anforderung wg.  unüberschaubaren Abhängigkeiten 6. Frustriertes Projektteam, das dauerhaft wie auf einem Vulkan lebt 7. Frustration und Unsicherheitsgefühl bis zu obersten Kundenetagen Seite 8
  • 10. Einführung - Chaos-Verursacher Wer könnte es sein? Ratet mal …  Kunde?  Vertrieb?  Eigenes Management?  … vielleicht andere „höhere Gewalt“? Seite 10
  • 11. Einführung - Chaos-Verursacher … bittere Erkenntnis / primäre Ursache Nein! … das waren und sind WIR! unser Entwicklerteam und zwar durch unsere Unprofessionalität Seite 11
  • 12. 1.3 LEITFADEN AUS DEM CHAOS Einführung Seite 12
  • 13. Einführung - Leitfaden aus dem Chaos Professionelle Softwareentwicklung (1) "Softwareentwicklung braucht Profis. Was aber sind Profis? Menschen die mit der Softwareentwicklung Geld verdienen? Nein, ..., es gehört mehr und anderes dazu. Professionalität in der Softwareentwicklung hat nichts mit Geld zu tun. Sie hat auch nur bedingt mit einem bestimmten Ausbildungsweg zu tun. <Es gibt> ... professionelle Softwareentwickler, die wenig oder gar kein Geld mit ihrer Software verdienen und <es gibt> ... professionelle Softwareentwickler, die weder Diplom noch Doktortitel haben.„ http://clean-code-developer.de (Stand: 10.05.2011) Seite 13
  • 14. Einführung - Leitfaden aus dem Chaos Professionelle Softwareentwicklung (2) Ein professioneller Softwareentwickler setzt sich mit dem Metier bewusst auseinander. D.h. er reflektiert über sein Produkt, seine Arbeitsweise, seine Materialien und Werkzeuge. Ein professioneller Softwareentwickler ist nicht einfach zufrieden, wenn sein Chef oder Kunde zufrieden sind. Er ist auch nicht einfach mit dem zufrieden, was ein Hersteller ihm empfiehlt. Stattdessen beobachtet und prüft er ständig seine Ergebnisse und bemüht sich um die Weiterentwicklung seiner selbst wie auch des Metiers. Seite 14
  • 15. Einführung - Leitfaden aus dem Chaos Professionelle Softwareentwicklung (3) Ein professioneller Softwareentwickler hat ein inneres Wertesystem. Gegen dieses Wertesystem prüft er seine Ergebnisse und Handlungen. Nur, wenn seine Arbeit diesem Wertesystem entspricht, empfindet er sie als gut getan, als professionell. Sein Streben ist es daher, auch unter widrigen Umständen, unter Druck von Kunden oder Herstellern, diesem Wertesystem treu zu sein. Professionalität = Bewusstheit + Prinzipien http://clean-code-developer.de (Stand: 24.07.2013) Seite 15
  • 17. Einführung – Professionelle Softwareentwicklung Zielbild (1) Kunde  Implementierung = Wunsch (im Endeffekt)  Kosten der Änderungswünsche realistisch abschätzbar Endbenutzer  wenige Bugs  schnelle Bug-Beseitigung Projektleiter (PL)  realistisch abschätzbare Implementierungsaufwände  höhes Vertrauensniveau an die Entwicklung Seite 17
  • 18. Einführung – Professionelle Softwareentwicklung Zielbild (2) Softwarearchitekt (SWA)  sauberes und überschaubares Design auch auf Implementierungs-Niveau  leicht kontrollierbares Qualitätsniveau  motiviert reguläre Aktualisierung der Style-Guides  Implementierung mit den Anforderungen (leicht) abgleichbar Entwickler  schneller Einstieg  leichte Nachvollziehbarkeit des Fremdcodes  Lerneffekt ebenfalls sauber zu programmieren  gutes Gefühl seine Pflichte zu 100% erfüllt zu haben Seite 18
  • 20. Einführung – Lösungsansatz: Clean Code Clean Code ist … (1) Bjarne Stroustrup  … Erfinder von C++ und Autor von “The C++ Programming Language“ Mein Code sollte möglichst elegant und effizient sein. … die Logik sollte grandlinig sein, damit sich Bugs nur schwer verstecken können … die Abhängikeiten sollten minimal sein, um die Wartung zu vereinfachen … das Fehler-Handling sollte vollständig gemäß einer vordefinierten Strategie erfolgen … das Leistungsverhalten sollte dem Optimum so nah wie möglich kommen, damit der Entwickler nicht versucht ist, den Code durch Ad-hoc-Optimierungen zu verunstalten Sauberer Code erledigt eine Aufgabe gut. Seite 20
  • 21. Einführung – Lösungsansatz: Clean Code Clean Code ist … (2) Grady Booch  … Autor von “Object Oriented Analysis and Design with Applications“ Sauberer Code: • … ist einfach und direct. • … liest sich wie wohlgeschriebene Prosa. • … verdunkelt niemals die Absicht des Designers, sondern ist voller griffiger (engl. crisp) Abstraktionen und geradliniger Kontrollstukturen. Seite 21
  • 22. Einführung – Lösungsansatz: Clean Code Clean Code ist … (3) “Big” Dave Thomas  ... Gründer der OTI, der Pate der Eclipse-Strategie Sauberer Code kann von anderen Entwickler gelesen und verbessert werden. … verfügt über Unit- und Acceptance-Tests. … erhält bedeutungsvolle Namen. … stellt zur Lösung einer Aufgabe nicht mehrere, sondern eine Lösung zur Verfügung. … erhält minimale Abhängigkeiten, die ausdrücklich definiert sind, und stellt ein klares und minimales API zur Verfügung. … sollte “literate” sein, da je nach Sprache nicht alle erforderliche Informationen allein im Code klar ausgedrückt werden können. Seite 22
  • 23. Einführung – Lösungsansatz: Clean Code Clean Code ist … (4) Dirty Code = Schlechter Code  „natürlich“ entstandener Code  gefährdet  Langlebigkeit eines SW-Produktes  seine Stabilität und Erweiterbarkeit Clean Code = Guter Code  legt einen besonderen Wert auf  Lesbarkeit  Nebeneffektfreiheit  Isolierung der Systemänderungen Seite 23
  • 24. Einführung – Lösungsansatz: Clean Code … und den Preis fürs Vergnügen Mehrkosten • fraglich, aber eher so gut wie keine + langfristige Spareffekte • der einzige Unterschied: natürliches/ungeübtes vs. systematisches Vorgehen Mehrwerte • meidet Kreativitätskrisen beim Entwicklungsteam • leicht gemachter fachlichen Einstieg für die Neueinsteiger • Synergieeffekte durch etwa gleichen Gedankenfluss / Vorgehensweise, z.B.: • Code-Konsistenz • niedrige Redundanz • gute Modifizierbarkeit • hohe Wiederverwendungsgrad • Grundlage für rechtzeitige Refactoring Seite 24
  • 25. Einführung – Lösungsansatz: Clean Code Weiterführende Informationen Seite 25 [MR09] Clean Code: A Handbook of Agile Software Craftsmanship; Robert C. Martin (aka Uncle Bob) ISBN-13: 978-0132350884 [CCD] Clean Code Developer – Initiative von Ralf Westphal und Stefan Lieser
  • 26. 2.1 NAMENSGEBUNG Clean Code - Best Practice Seite 26
  • 27. 13.05.2011 Clean Coding - Theory & Praxis Guide 27 Clean Code – Namensgebung (1) … Charakteristik guter Namen  aussagekräftig  aussprechbar  auffindbar (IDE)  eindeutig & klar Auswahl der Schlüsselwörter  ein Wort per Konzept  aus der Domainsprache => (Problem/Lösungs-Domain)  Verwenden von Namenskonventionen => z. Bsp. für Funktionen: is<…>, set<…>, get<…>, …
  • 28. 13.05.2011 Clean Coding - Theory & Praxis Guide 28 Clean Code – Namensgebung (2) … Prinzipien  Mehrdeutigkeit vermeiden  Desinformationen vermeiden => „say what you mean, mean what you say.“  aussagekräftigen Kontext verwenden => meist durch gut benannte Klassen, Funktionen und andere Namensräume gegeben => wenn kein klarer Kontext gegeben, muss dieser ein Teil des Namens sein  Verwendung desselben Schlüsselworts für mehrere Konzepte vermeiden  Typ/Scope/Mitgliedschaft bedingte Präfixe vermeiden
  • 29. 13.05.2011 Clean Coding - Theory & Praxis Guide 29 Clean Code – Namensgebung (3) … Gute Namen zu finden ist schwierig, aber  zahlt sich sehr schnell aus  animiert zur Suche nach einem Konsensus  schafft gemeinsame Basis für alle Entwickler  trägt der inkrementeller Entstehung von DSL bei
  • 30. 2.2 FUNKTIONEN Clean Code - Best Practice Seite 30
  • 31. 13.05.2011 Clean Coding - Theory & Praxis Guide 31 Clean Code – Funktionen Einführung (1) Funktionen … sollten eine Aufgabe erledigen. … sollten sie gut erledigen. … sollten nur diese Aufgabe erledigen. Diese Beschreibung  bestimmt die Größe der Funktion  sichert ihre Nebeneffekt-Freiheit  weist auf die Auswahl der Funktionsnamen hin
  • 32. 13.05.2011 Clean Coding - Theory & Praxis Guide 32 Clean Code - Funktionen Einführung (2) Funktionsgröße Regel 1: … muss KLEIN sein Regel 2: … muss noch KLEINER sein Funktionsname … soll deskriptiv sein … soll beschreiben WAS die Funktion tut … soll beschreiben ALLES was die Funktion tut Eine Funktion ist sauber wenn: … implementiert nur eine einzige Handlung … implementiert Handlung nur eines Abstraktionsniveaus … ihre Funktionalität ist durch Funktionsnamen vollständig beschrieben => Nebeneffekt-Freiheit
  • 33. 13.05.2011 Clean Coding - Theory & Praxis Guide 33 Clean Code - Funktionen Logikfluss Als Ergebnis  viele kurze Funktionen (3-10 Zeilen)  nicht selten eine Funktion nur von einer einzigen Stelle aufgerufen „Step-Down“-Regel  aufzurufende nach den aufrufenden Funktionen (vertikale Anordnung) Gruppierung der Funktionen  die einander aufrufen  die ähnliche Funktionalität umsetzen  die die gleichen Objekte bzw. Instanzvariablen behandeln sich wiederholende Switch-Anweisungen  meist durch Polymorphie lösbar
  • 34. 13.05.2011 Clean Coding - Theory & Praxis Guide 34 Clean Code - Funktionen Benennung Muss ein Verb enthalten Namenskonventionen wichtig  dieselben Verben für dieselben Handlungen => Bsp.: get, set, is, find, query, check, enrich, … Schlüsselwörter aus der Domainsprachen … sonst der allgemeinen Regeln der Namensgebung folgen (s. oben)
  • 35. 13.05.2011 Clean Coding - Theory & Praxis Guide 35 Clean Code - Funktionen Argumente (1) Argumentenanzahl keine Argumente ist ideal => ganzen Zustand durch Instanzvariablen bestimmt ein Argument … prüft Annahmen => Rückgabe: boolesche Typ boolean fileExists(“MyFile”) … behandelt Ereignisse => keine Rückgabe void onDataLoad(Event event) … transformiert dieses Argument/Objekt => Rückgabe: transformiertes Objekt InputStream fileOpen(“MyFile”)
  • 36. 13.05.2011 Clean Coding - Theory & Praxis Guide 36 Argumentenanzahl zwei Argumente assertEquals(expected, actual) => leicht zu verwechselnde Reihenfolge gleichartiger Argumenten p = new Point(0,0); => sind geordnete Bestandteile desselben Wert-Objekts! drei Argumente assertEquals(message, expected, actual) => leicht zu verwechselnde Reihenfolge gleichartiger Argumenten assertEquals(1.0, amount, .001) => sind fachlich bedingt (Vergleich von zwei Floatpoint-Werten ist nur mit einem Genauigkeitsgrad möglich) Clean Code - Funktionen Argumente (2)
  • 37. 13.05.2011 Clean Coding - Theory & Praxis Guide 37 Clean Code - Funktionen Argumente (3) Argumentanzahl mehr als drei Argumente eindeutiges Warnsignal zum Refactoren Mittel zur Reduzierung der Argumentanzahl: … in Instanzvariablen umwandeln … in Wrapper-Klassen kapseln … Funktion in Kontext eines der Argumente verschieben, z.B.: <some-class>.write (outputStream, name) => outputStream.write (name)
  • 38. 13.05.2011 Clean Coding - Theory & Praxis Guide 38 Clean Code - Funktionen Argumente (4) Argumentarten Flag-Argumente (boolesche) => verletzt „do one thing“-Regel in/out Argumente => Nebeneffekte => verschlechtern Nachvollziehbarkeit Argument-Listen => wenn diese gleich behandelt werden = ein Argument vom List-Typ => im übrigen dieselben Begrenzungen auf die Argumentenanzahl
  • 39. 13.05.2011 Clean Coding - Theory & Praxis Guide 39 Clean Code - Funktionen Fehlerbehandlung Exception werfen bevorzugt über Rückgabe eines ErrorCode‘s Fehlerbehandlung = one thing => in die Extrafunktion auslagern … sonst ist dies das Thema für eine Extrapräsentation.
  • 40. 2.3 KLASSEN Clean Code - Best Practice Seite 40
  • 41. 13.05.2011 Clean Coding - Theory & Praxis Guide 41 Clean Code - Klassen Einführung … es gibt eine gewisse Korrelation mit den Anforderungen zu den Funktionen Klassengröße Regel 1: … muss KLEIN sein Regel 2: … muss noch, Ihr wisst schon, KLEINER sein Klassenname … soll deskriptiv sein … soll beschreiben WOFÜR die Klasse verantwortlich ist … soll beschreiben ALLES WOFÜR die Klasse verantwortlich ist
  • 42. 13.05.2011 Clean Coding - Theory & Praxis Guide 42 Clean Code - Klassen Klassenorganisation – Responsibility-Merkmal Single Responsibility Principle (SRP) public class SuperDashboard extends JFrame implements MetaDataUser public String getCustomizerLanguagePath() public void setSystemConfigPath(String systemConfigPath) public String getSystemConfigDocument() public void setSystemConfigDocument(String systemConfigDocument) public boolean getGuruState() public boolean getNoviceState() public boolean getOpenSourceState() public void showObject(MetaObject object) public void showProgress(String s) public void setIsMetadataDirty(boolean isMetadataDirty) public Component getLastFocusedComponent() public void setLastFocused(Component lastFocused) public void setMouseSelectState(boolean isMouseSelected) public boolean isMouseSelected() public LanguageManager getLanguageManager() public Project getProject() public Project getFirstProject() public Project getLastProject() public String getNewProjectName()
  • 43. 13.05.2011 Clean Coding - Theory & Praxis Guide 43 Clean Code - Klassen Klassenorganisation – Responsibility-Merkmal Single Responsibility Principle (SRP) public class SuperDashboard extends JFrame implements MetaDataUser public String getCustomizerLanguagePath() public void setSystemConfigPath(String systemConfigPath) public String getSystemConfigDocument() public void setSystemConfigDocument(String systemConfigDocument) public boolean getGuruState() public boolean getNoviceState() public boolean getOpenSourceState() public void showObject(MetaObject object) public void showProgress(String s) public void setIsMetadataDirty(boolean isMetadataDirty) public Component getLastFocusedComponent() public void setLastFocused(Component lastFocused) public void setMouseSelectState(boolean isMouseSelected) public boolean isMouseSelected() public LanguageManager getLanguageManager() public Project getProject() public Project getFirstProject() public Project getLastProject() public String getNewProjectName() public class SuperDashboard extends JFrame { public Component getLastFocusedComponent() public void setLastFocused(Component lastFocused) public int getMajorVersionNumber() public int getMinorVersionNumber() public int getBuildNumber() }
  • 44. 13.05.2011 Clean Coding - Theory & Praxis Guide 44 Clean Code - Klassen Klassenorganisation – Responsibility-Merkmal Single Responsibility Principle (SRP) public class SuperDashboard extends JFrame implements MetaDataUser public String getCustomizerLanguagePath() public void setSystemConfigPath(String systemConfigPath) public String getSystemConfigDocument() public void setSystemConfigDocument(String systemConfigDocument) public boolean getGuruState() public boolean getNoviceState() public boolean getOpenSourceState() public void showObject(MetaObject object) public void showProgress(String s) public void setIsMetadataDirty(boolean isMetadataDirty) public Component getLastFocusedComponent() public void setLastFocused(Component lastFocused) public void setMouseSelectState(boolean isMouseSelected) public boolean isMouseSelected() public LanguageManager getLanguageManager() public Project getProject() public Project getFirstProject() public Project getLastProject() public String getNewProjectName() public class SuperDashboard extends JFrame { public Component getLastFocusedComponent() public void setLastFocused(Component lastFocused) public int getMajorVersionNumber() public int getMinorVersionNumber() public int getBuildNumber() } public class Version { public int getMajorVersionNumber() public int getMinorVersionNumber() public int getBuildNumber() }
  • 45. 13.05.2011 Clean Coding - Theory & Praxis Guide 45 Clean Code - Klassen Klassenorganisation – Kohäsion-Merkmal Clean-Code-Anforderung zu den Funktionen – Minimierung der Argumentenanzahl als Folge – viele kleinere Funktionen der ganze Objektzustand ist durch seine Instanzvariablen präsentiert Wenn eine Untermenge der Instanzvariablen ausschließlich von einer Untermenge der Klassenmethoden benutzt wird => Warnsignal zur Klassen-Spaltung
  • 46. 13.05.2011 Clean Coding - Theory & Praxis Guide 46 Clean Code - Klassen Klassenorganisation – Änderungsrisiko-Merkmal Moderne SW-Systeme sind permanenten Änderungen unterworfen Änderung eines Systemteils => Systemrest funktioniert nicht mehr als erwartet Aus diesem Grund sollte man das System so organisieren, damit die Funktionalität der nicht angefassten Systemteile erhalten bleibt
  • 47. 2.4 FEHLERBEHANDLUNG Clean Code - Best Practice Seite 47
  • 48. 13.05.2011 Clean Coding - Theory & Praxis Guide 48 Clean Code – Fehlerbehandlung (1) … Ausnahmen statt Rückgabe-Codes • Problem von Rückgabe-Codes: • veraltete Technik • begrenzter Informationsgehalt im Ausnahme-Fall • Zwang den Code direkt an der aufrufenden Stelle zu prüfen • Lösungsansatz: • Exceptions / Ausnahmen werfen Ausnahmen mit Kontext auslösen • Zweck: • Nachvollziehbarkeit und Reproduzierbarkeit des Fehlerfalls • Lösungsansätze: • informative Fehlermeldungen • spezialisierte Exception-Klassen mit entsprechenden Fach-Properties
  • 49. 13.05.2011 Clean Coding - Theory & Praxis Guide 49 Clean Code – Fehlerbehandlung (2) … Exception-Klassen aus Sicht des Aufrufers • Zweck: • Eingrenzung nur auf die für Aufrufer relevante Ausnahmefälle • Bewertung der internen Ausnahmefälle aus der fachlichen Sicht • Lösungsansätze: • Erstellung eigener fachlichen Exception-Klassensätzen: • wird zur Bestandteil von API und des API-Vertrags • Einhüllung der internen oft technischen Exception in die fachlichen Checked Exceptions • Problem: • Abfangstelle oft weit weg vom eigentlichen Aufruf • unnötige Exception-Deklarationen in zahlreichen Funktion-Signaturen • Lösungsansatz: • im Allgemeinen: keine mehr einsetzen! • Ausnahme: kritische Bibliotheken bzw. ihre API
  • 50. 13.05.2011 Clean Coding - Theory & Praxis Guide 50 Clean Code – Fehlerbehandlung (3) … Try-Catch-Finally Anweisungen • bestimmen Geltungsbereich • sind ähnlich dem Transaktionen-Konzept • somit muss catch-Code das Programm im konsistenten Stand zurücklassen • müssen möglichst zuerst geschrieben werden, bevor Geschäftslogik im try-Abschnitt Den normalen Ablauf definieren • …
  • 51. 13.05.2011 Clean Coding - Theory & Praxis Guide 51 Clean Code – Fehlerbehandlung (4) … Keine Null zurückgeben Keine Null übergeben • Themen wurden in einer der Architektur-Runden abgesprochen, für mehr: • Wiki: Richtlinien: Quellcode / Umgang mit NULL-Werten
  • 53. 13.05.2011 Clean Coding - Theory & Praxis Guide 53 Clean Code - Ausblick  Formatierungsregeln  Kommentare  Unit Tests  Nebenläufigkeit  Fehlerbehandlung  Allgemeine Systemaufbau  … Weitere hier nicht behandelte Themen
  • 54. 13.05.2011 Clean Coding - Theory & Praxis Guide 54 Clean Code - Ausblick Heuristiken - Beispiele (1) Comments C1: Inappropriate Information C2: Obsolete Comment C3: Redundant Comment C4: Poorly Written Comment C5: Commented-Out Code Environment E1: Build Requires More Than One Step E2: Tests Require More Than One Step Functions F1: Too Many Arguments F2: Output Arguments F3: Flag Arguments F4: Dead Function
  • 55. 13.05.2011 Clean Coding - Theory & Praxis Guide 55 Clean Code - Ausblick Heuristiken - Beispiele (2) General G1: Multiple Languages in One Source File G2: Obvious Behavior Is Unimplemented G3: Incorrect Behavior at the Boundaries G4: Overridden Safeties G5: Duplication G6: Code at Wrong Level of Abstraction G7: Base Classes Depending on Their Derivatives ... … und viele anderen sind im [MR09] zu finden.
  • 56. PRAXIS GUIDE Sample Slides utilizing the template features of Powerpoint 2010 Seite 56
  • 57. 13.05.2011 Clean Coding - Theory & Praxis Guide 57 Praxis Guide Aufgabenstellung Ausgangsdaten für die Entwickler Fachliche Spezifikation des zu realisierenden Systems  durch Fachabteilung/Analysten erarbeitet  mittels Dekomposition des Gesamtsystems in  Fachbereiche/Fachklassen  fachliche Abhängigkeiten/Operationen Aufgabe des Entwicklers Umsetzung dieser Spezifikation
  • 58. 13.05.2011 Clean Coding - Theory & Praxis Guide 58 Praxis Guide Fachliche Abstraktionsniveau Businesslogik (BL) Schnittstelle  spiegelt die Fachspezifikation auf die Implementierungssprache … um Implementierung mit der Spezifikation abgleichbar zu halten => Verwendung einer fachlichen DSL nötig  muss beschreiben WAS implementiert werden muss => Strukturierungseinheiten: Aggregate, Fachklassen, … => nächste Hierarchiestufe: Businessoperationen Businesslogik Implementierung  muss das WIE beschreiben, aber immerhin im Scope des BL-Abstraktionsniveaus  evtl. zwischen mehreren Aggregaten teilbaren lower-level BL-Framework  immerhin Realisierung in den Begriffen einer fachlichen DSL
  • 59. 13.05.2011 Clean Coding - Theory & Praxis Guide 59 Praxis Guide Technische Abstraktionsniveau Frameworks  commons  Datenpersistenz  Dependency Injection  … (Kommunikations-) Schnittstellen zu anderen Systemen  JMS  FTP  Email  …
  • 60. 13.05.2011 Clean Coding - Theory & Praxis Guide 60 Praxis Guide Clean Coding – Verfahren (1) Inkrementelle Verbesserung des Codes, rechtzeitigen Reviews/Refactorings Einhaltung der Grenzen einzelner Abstraktionsebenen  auf Schnittstellen-Niveau  innerhalb der Implementierung einzelner Funktionen Passende Benennung der Artefakte  Pakete/Module  Klassen  Funktionen und ihre Argumente  Instanz- bzw. lokale Variablen  … Eindeutiger Kontext
  • 61. 13.05.2011 Clean Coding - Theory & Praxis Guide 61 Praxis Guide Clean Coding – Verfahren (2) Suche nach passender Benennung führt zu richtigen Designentscheidungen  Pakete/Klassen/Funktionen/… (Kontexte)  zu spezialisieren bzw. zu generalisieren  zu spalten bzw. in anderen Kontext auszulagern  die Artefakte ähnlicher Abstraktionsniveau/Funktionalität landen in den naheliegenden/denselben Kontexten und werden sogar oft ähnlich/gleich benannt  erleichtert Identifikation der Artefakte mit gleicher/ähnlicher Funktionalität  ermöglicht beste Implementierung auszuwählen und Redundanzen zu beseitigen
  • 62. 13.05.2011 Clean Coding - Theory & Praxis Guide 62 Theorie & Praxis Guide [MR09] Clean Code: A Handbook of Agile Software Craftsmanship; Robert C. Martin (aka Uncle Bob) ISBN-13: 978-0132350884 Weiterführende Informationen [CCD] Clean Code Developer – Initiative von Ralf Westphal und Stefan Lieser
  • 63. Deutschland IMPAQ GmbH & Co. KG Clemensstraße 10 D - 60487 Frankfurt Phone: +49 69 92 00 80 0 Schweiz IMPAQ AG Flurstrasse 32 Postfach CH-8066 Zürich Phone: +41 44 4 05 21 00 Weitere Informationen zur IMPAQ Gruppe und unseren Niederlassungen finden Sie auf: www.impaqgroup.com Name Job Title IMPAQ Location Street xxx Post Country – Postcode City Phone: +country code (number) Fax: +country code (number)  email@impaqgroup.com  www.impaqgroup.com Wir freuen uns auf Ihre Kontaktaufnahme United Kingdom IMPAQ UK Ltd. 9 Bridle Close Surbiton Road Kingston upon Thames Surrey KT1 2JW Phone: +44 20 85 49 2133 Polen IMPAQ Sp. z o.o. ul. Wołoska 22 02-675 Warsaw Phone: +48 22 31 46 000