Clean Coding - Theorie und Praxis Guide.pptx

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

… eine der wichtigsten Ursachen
Schlechter Code!
Seite 5

… 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

… 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

… 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

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

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

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

“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

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

… 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

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
28
…
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
29
…
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
Seite 30

13.05.2011
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
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
33
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
34
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
35
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
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)
Argumente (2)

13.05.2011
37
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
38
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
39
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
Seite 40

13.05.2011
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
42
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
43
public class SuperDashboard extends JFrame {
public int getMajorVersionNumber()
public int getMinorVersionNumber()
public int getBuildNumber()
}

13.05.2011
44
public class SuperDashboard extends JFrame {
}
public class Version {
}

13.05.2011
45
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
46
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
Seite 47

13.05.2011
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
49
…
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
50
…
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
51
…
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

13.05.2011
53
Clean Code - Ausblick
 Formatierungsregeln
 Kommentare
 Unit Tests
 Nebenläufigkeit
 Fehlerbehandlung
 Allgemeine Systemaufbau
 …
Weitere hier nicht behandelte Themen

13.05.2011
54
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
55
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
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
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
59
Praxis Guide
Technische Abstraktionsniveau
Frameworks
 commons
 Datenpersistenz
 Dependency Injection
 …
(Kommunikations-) Schnittstellen zu anderen Systemen
 JMS
 FTP
 Email
 …

13.05.2011
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
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
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

Clean Coding - Theorie und Praxis Guide.pptx

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

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

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

Clean Coding - Theorie und Praxis Guide.pptx