Themenabend/Clean Code: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Astro (Diskussion | Beiträge) (slides link) |
Vater (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
Zeile 1: | Zeile 1: | ||
{{historisch}}[[Kategorie:Themenabend]][[Kategorie:2015]] | {{historisch}}[[Kategorie:Themenabend]][[Kategorie:2015]] | ||
<div style="float:right"> | <div style="float:right"> | ||
{{Themenabend| | {{Themenabend | ||
TITEL= Clean Code | | | TITEL= Clean Code | ||
UNTERTITEL= | | | UNTERTITEL= | ||
TERMIN= 23.07.2015 | | | TERMIN= 23.07.2015 | ||
ORT= HQ | | | ORT= HQ | ||
THEMA= | | | THEMA= | ||
| REFERENTEN= Nico Krebs | |||
REFERENTEN= Nico Krebs | | | C3D2WEB= http://www.c3d2.de/news/ta-clean-code.html | ||
C3D2WEB= http://www.c3d2.de/news/ta-clean-code.html | | | TOPIC= | ||
TOPIC= | | | SLIDES= [[Themenabend/Clean Code]] | ||
SLIDES= [[ Themenabend/ | |||
}} | }} | ||
</div> | </div> | ||
Zeile 17: | Zeile 16: | ||
__TOC__ | __TOC__ | ||
<pre>How to code | <pre> | ||
How to code | |||
_______ _______ _______ __ _ _______ _____ ______ _______ | _______ _______ _______ __ _ _______ _____ ______ _______ | ||
| | |______ |_____| | \ | | | | | \ |______ | | | |______ |_____| | \ | | | | | \ |______ | ||
|_____ |_____ |______ | | | \_| |_____ |_____| |_____/ |______</pre> | |_____ |_____ |______ | | | \_| |_____ |_____| |_____/ |______ | ||
</pre> | |||
;name | ; name: Nico Krebs | ||
:Nico Krebs | ; blog: [http://www.mensch-und-maschine.de www.mensch-und-maschine.de] | ||
;blog | ; work:[http://www.projektmotor.de www.projektmotor.de] | ||
:[http://www.mensch-und-maschine.de www.mensch-und-maschine.de] | ; mail: nkoding@gmail.com | ||
;work | |||
:[http://www.projektmotor.de www.projektmotor.de] | |||
;mail | |||
:nkoding@gmail.com | |||
Alles, was im Folgenden beschrieben wird, ist eine Utopie, ein | Alles, was im Folgenden beschrieben wird, ist eine Utopie, ein | ||
Zeile 39: | Zeile 36: | ||
sondern man sollte sich heraussuchen, was praktikabel ist. | sondern man sollte sich heraussuchen, was praktikabel ist. | ||
= Warum sind wir hier? = | == Warum sind wir hier? == | ||
Wir alle haben das schon erlebt und wollen es in Zukunft vermeiden: | Wir alle haben das schon erlebt und wollen es in Zukunft vermeiden: | ||
* Projekte werden mit der Zeit immer träger | * Projekte werden mit der Zeit immer träger. | ||
* Neue Features implementieren dauert länger, je mehr Features es gibt | * Neue Features implementieren dauert länger, je mehr Features es gibt. | ||
* Bugs fixt man nicht mehr in Minuten sondern in Wochen oder Monaten (z.b. wenn Architekturfehler erst spät sichtbar werden) | * Bugs fixt man nicht mehr in Minuten sondern in Wochen oder Monaten (z.b. wenn Architekturfehler erst spät sichtbar werden). | ||
* | * Evtl. wird ein paralleles Projekt gestartet, das alles besser machen soll - aber dann dieselben Methoden verwendet. | ||
* Beide Arbeitsgruppen konkurrieren, keine kommt wirklich voran | * Beide Arbeitsgruppen konkurrieren, keine kommt wirklich voran. | ||
* User sind unzufrieden | * User sind unzufrieden. | ||
* Das Projekt stirbt an seiner Größe und die Firma ggf. gleich mit | * Das Projekt stirbt an seiner Größe und die Firma ggf. gleich mit. | ||
* Es gibt sehr viele Sicherheitslücken im Projekt | * Es gibt sehr viele Sicherheitslücken im Projekt. | ||
* Bekannteres | * Bekannteres Bsp.: flash. Vermutlich ist das Code mit ähnlichen Eigenschaften. Entsprechend anfällig ist das Ganze für Sicherheitslücken. | ||
= Wie kommt man aus diesem Teufelskreis? = | == Wie kommt man aus diesem Teufelskreis? == | ||
== Analyse: Was ist schlechter Code und warum? == | === Analyse: Was ist schlechter Code und warum? === | ||
* große Funktionen und Klassen/Scriptfiles | * große Funktionen und Klassen/Scriptfiles | ||
* eine Funktion erledigt viele Aufgaben | * eine Funktion erledigt viele Aufgaben | ||
* Abhängigkeiten sind hard coded | * Abhängigkeiten sind hard coded | ||
* Verschachtelte Schleifen und Konstrukte wie Branches ("switch" und "if/then/else") werden häufig genutzt | * Verschachtelte Schleifen und Konstrukte wie Branches ("switch" und "if/then/else") werden häufig genutzt. | ||
* Logik befindet sich innerhalb von if- | * Logik befindet sich innerhalb von if-Blöcken. | ||
* Klassen-/Funktions-/Variablennamen sind nicht aussagekräftig | * Klassen-/Funktions-/Variablennamen sind nicht aussagekräftig. | ||
* Funktionen mit vielen Parametern | * Funktionen mit vielen Parametern | ||
* | * Um den Code nachzuvollziehen, muss ständig zwischen Dateien gewechselt und darin über mehrere hundert/tausend Zeilen gescrollt werden. | ||
* Funktionen sind schlecht oder gar nicht testbar, weil ein Testcase so komplex werden würden, | * Funktionen sind schlecht oder gar nicht testbar, weil ein Testcase so komplex werden würden, dass sie selbst Tests bräuchten. | ||
* im worst case GOTO-Anweisungen | * im worst case GOTO-Anweisungen | ||
* hohe Wahrscheinlichkeit von Sicherheitslücken<br>=> Spaghetti code | * hohe Wahrscheinlichkeit von Sicherheitslücken<br>=> Spaghetti code | ||
== Im Umfeld schlechten Codes findet man häufig auch: == | === Im Umfeld schlechten Codes findet man häufig auch: === | ||
* keine automatischen Tests, weil untestbar (z.b. jUnit) | * keine automatischen Tests, weil untestbar (z.b. jUnit) | ||
* keine Versionskontrolle (z. | * keine Versionskontrolle (z.B. git) | ||
* kein Ticketsystem (z. | * kein Ticketsystem (z.B. Redmine) | ||
* kein CI-System (z.b. | * kein CI-System (z.b. Jenkins/Hudson) | ||
* keine Nutzung von IDEs (z. | * keine Nutzung von IDEs (z.B. NetBeans) | ||
* keine Dokumentation | * keine Dokumentation | ||
* keine leistungsfähigen Kommunikationskanäle (twitter/foren/chat/...), sondern höchstens per | * keine leistungsfähigen Kommunikationskanäle (twitter/foren/chat/...), sondern höchstens per E-Mail-/Telefonsupport | ||
== Was ist sauberer Code? == | === Was ist sauberer Code? === | ||
* | * verständlich im Hinblick auf Leistungsfähigkeit des Gehirns (drei bis sieben Elemente im Kurzzeitgedächtnis) | ||
* lesbar wie ein Buch | * lesbar wie ein Buch | ||
* | * Eine Funktion hat genau eine Funktion. | ||
* wenige Kontrollkonstrukte | * wenige Kontrollkonstrukte | ||
* strikte Trennung von Logik und Fehlerprüfung | * strikte Trennung von Logik und Fehlerprüfung | ||
Zeile 88: | Zeile 85: | ||
* Nutzung von Test Driven Development, Ticketsystem, Buildsystem etc., um sich selbst zu organisieren und Überblick zu behalten | * Nutzung von Test Driven Development, Ticketsystem, Buildsystem etc., um sich selbst zu organisieren und Überblick zu behalten | ||
== Wie schreibt man sauberen Code? == | === Wie schreibt man sauberen Code? === | ||
=== | ==== Leistungsfähigkeit des Gehirns als Grundlage ==== | ||
* möglichst drei bis sieben Packages pro Modul/Plugin | * möglichst drei bis sieben Packages pro Modul/Plugin | ||
Zeile 96: | Zeile 93: | ||
* möglichst nicht mehr als sieben Funktionen pro Klasse -> besser drei | * möglichst nicht mehr als sieben Funktionen pro Klasse -> besser drei | ||
* möglichst drei bis sieben Zeilen Logik pro Funktion | * möglichst drei bis sieben Zeilen Logik pro Funktion | ||
* Klassen müssen so geplant oder | * Klassen müssen so geplant oder refaktoriert werden, dass sie möglichst wenige hard coded Abhängigkeiten haben. | ||
* Kommentare möglichst vermeiden, da sie meist sowieso nicht gepflegt werden. Besser sind selbsterklärende Funktions- und | * Kommentare möglichst vermeiden, da sie meist sowieso nicht gepflegt werden. Besser sind selbsterklärende Funktions- und Variablennamen. | ||
* | * Ein doc-Block für API-Methoden muss jedoch sein (für die User der API). | ||
=== Lesbar wie ein Buch === | ==== Lesbar wie ein Buch ==== | ||
* Buch = Modul | * Buch = Modul | ||
Zeile 109: | Zeile 106: | ||
* sinnvolle Funktionsnamen verwenden | * sinnvolle Funktionsnamen verwenden | ||
==== Eine Funktion hat genau eine Funktion. ==== | |||
=== Eine Funktion hat genau eine Funktion === | |||
* Parameter sparen, möglichst viel über Klassenproperties abdecken | * Parameter sparen, möglichst viel über Klassenproperties abdecken | ||
Zeile 116: | Zeile 112: | ||
* keine Branches ("if/then/else" Verzweigungen) in der Logik | * keine Branches ("if/then/else" Verzweigungen) in der Logik | ||
==== Kontrollkonstrukte eliminieren! ==== | |||
* Durch Branches (if-Konstrukte) in der Logik hat eine Funktion meist nicht mehr nur eine Funktion. | |||
* | |||
* Branches und Switches (switch/if-Konstrukte) aufteilen | * Branches und Switches (switch/if-Konstrukte) aufteilen | ||
** interface mit canRun()/run()- | ** interface mit canRun()/run()-Methoden | ||
** in einer Schleife alle Implementierungen des Interfaces durchlaufen, die erste die canRun() mit true beantwortet, deren run() | ** in einer Schleife alle Implementierungen des Interfaces durchlaufen, die erste die canRun() mit true beantwortet, deren run()-Methode wird aufrufen | ||
=== Strikte Trennung von Logik und Fehlerprüfung === | ==== Strikte Trennung von Logik und Fehlerprüfung ==== | ||
* Trennung von Fehlerbehandlung und Logik | * Trennung von Fehlerbehandlung und Logik | ||
Zeile 133: | Zeile 127: | ||
*** idealerweise in eine eigene Funktion abkapseln | *** idealerweise in eine eigene Funktion abkapseln | ||
=== Teile und herrsche === | |||
== Teile und herrsche == | |||
* monolithische Systeme immer weiter aufteilen | * monolithische Systeme immer weiter aufteilen | ||
* | * Je kleiner die Teile eines Systems sind, desto beherrschbarar sind sie für Menschen. | ||
* siehe Quicksort, Design Patterns, rekursive Funktionen allgemein | * siehe Quicksort, Design Patterns, rekursive Funktionen allgemein | ||
== Emergenz == | === Emergenz === | ||
* Zusammenschluss vieler einfacher Komponenten | * Zusammenschluss vieler einfacher Komponenten | ||
* | * Bsp.: Schwärme, neuronale Netze, Würfelhaufen/Flummis, Conway's Game of Life, genetische/evolutionäre Algorithmen | ||
* Was passiert da? | * Was passiert da? | ||
** Kontrolle an die Einzelteile abgeben | ** Kontrolle an die Einzelteile abgeben | ||
** | ** Jedes Element kennt selbst den besten Weg, eine Situation zu behandeln. | ||
** Komponenten können miteinander kommunizieren | ** Komponenten können miteinander kommunizieren. | ||
** | ** Durch die Verbindungen entstehen neue Eigenschaften des Gesamtsystems (leider nur schwer vorhersagbar, welche. siehe Bewusstsein und freier Wille). | ||
** | ** Einige Eigenschaften sind jedoch vorhersagbar - und das kann man nutzen! | ||
** | ** Es gibt keinen "master", der die Einzelteile kontrolliert (Anmerkung: also auch kein Script, das Kommandos verbindet. Als emergent könnte man es bezeichnen, wenn zwei oder mehr Scripte autonom agieren und Daten miteinander austauschen.) | ||
** | ** Insofern können auch autonome Module, Klassen und Funktionen emergentes Verhalten produzieren. -> siehe Multithreading | ||
= Aktuelle Forschungsschwerpunkte = | == Aktuelle Forschungsschwerpunkte == | ||
* Erhöhung der Systemsicherheit | * Erhöhung der Systemsicherheit |
Version vom 26. Juli 2015, 01:50 Uhr
Achtung! Historisch! |
---|
Dieser Artikel enthält keine relevanten Informationen zu den aktuellen Geschehnissen. Ferner handelt es sich um einen archivierten Artikel. |
Veranstaltung | |
---|---|
Titel | Clean Code |
Untertitel | |
Termin | 23.07.2015 |
Ort | HQ |
Thema | |
Vortragende(r) | |
Referent(inn)en: | Nico Krebs |
Links | |
C3D2 Webseite | http://www.c3d2.de/news/ta-clean-code.html |
Thema | |
Folien | Themenabend/Clean Code |
How to code _______ _______ _______ __ _ _______ _____ ______ _______ | | |______ |_____| | \ | | | | | \ |______ |_____ |_____ |______ | | | \_| |_____ |_____| |_____/ |______
- name
- Nico Krebs
- blog
- www.mensch-und-maschine.de
- work
- www.projektmotor.de
- nkoding@gmail.com
Alles, was im Folgenden beschrieben wird, ist eine Utopie, ein nie erreichbares Ideal und keine dogmatische Handungsanweisung. Doch ich versuche mich, so nah wie möglich da heran zu bringen - immer pragmatisch auf den Anwendungsfall bezogen. Jeder der folgenden Vorschläge kann für sich allein angewendet werden, man muss nicht das Komplettpaket einbauen, sondern man sollte sich heraussuchen, was praktikabel ist.
Warum sind wir hier?
Wir alle haben das schon erlebt und wollen es in Zukunft vermeiden:
- Projekte werden mit der Zeit immer träger.
- Neue Features implementieren dauert länger, je mehr Features es gibt.
- Bugs fixt man nicht mehr in Minuten sondern in Wochen oder Monaten (z.b. wenn Architekturfehler erst spät sichtbar werden).
- Evtl. wird ein paralleles Projekt gestartet, das alles besser machen soll - aber dann dieselben Methoden verwendet.
- Beide Arbeitsgruppen konkurrieren, keine kommt wirklich voran.
- User sind unzufrieden.
- Das Projekt stirbt an seiner Größe und die Firma ggf. gleich mit.
- Es gibt sehr viele Sicherheitslücken im Projekt.
- Bekannteres Bsp.: flash. Vermutlich ist das Code mit ähnlichen Eigenschaften. Entsprechend anfällig ist das Ganze für Sicherheitslücken.
Wie kommt man aus diesem Teufelskreis?
Analyse: Was ist schlechter Code und warum?
- große Funktionen und Klassen/Scriptfiles
- eine Funktion erledigt viele Aufgaben
- Abhängigkeiten sind hard coded
- Verschachtelte Schleifen und Konstrukte wie Branches ("switch" und "if/then/else") werden häufig genutzt.
- Logik befindet sich innerhalb von if-Blöcken.
- Klassen-/Funktions-/Variablennamen sind nicht aussagekräftig.
- Funktionen mit vielen Parametern
- Um den Code nachzuvollziehen, muss ständig zwischen Dateien gewechselt und darin über mehrere hundert/tausend Zeilen gescrollt werden.
- Funktionen sind schlecht oder gar nicht testbar, weil ein Testcase so komplex werden würden, dass sie selbst Tests bräuchten.
- im worst case GOTO-Anweisungen
- hohe Wahrscheinlichkeit von Sicherheitslücken
=> Spaghetti code
Im Umfeld schlechten Codes findet man häufig auch:
- keine automatischen Tests, weil untestbar (z.b. jUnit)
- keine Versionskontrolle (z.B. git)
- kein Ticketsystem (z.B. Redmine)
- kein CI-System (z.b. Jenkins/Hudson)
- keine Nutzung von IDEs (z.B. NetBeans)
- keine Dokumentation
- keine leistungsfähigen Kommunikationskanäle (twitter/foren/chat/...), sondern höchstens per E-Mail-/Telefonsupport
Was ist sauberer Code?
- verständlich im Hinblick auf Leistungsfähigkeit des Gehirns (drei bis sieben Elemente im Kurzzeitgedächtnis)
- lesbar wie ein Buch
- Eine Funktion hat genau eine Funktion.
- wenige Kontrollkonstrukte
- strikte Trennung von Logik und Fehlerprüfung
- testbare Funktionen und Klassen
- Nutzung von Test Driven Development, Ticketsystem, Buildsystem etc., um sich selbst zu organisieren und Überblick zu behalten
Wie schreibt man sauberen Code?
Leistungsfähigkeit des Gehirns als Grundlage
- möglichst drei bis sieben Packages pro Modul/Plugin
- möglichst drei bis sieben Klassen pro Package
- möglichst nicht mehr als sieben Funktionen pro Klasse -> besser drei
- möglichst drei bis sieben Zeilen Logik pro Funktion
- Klassen müssen so geplant oder refaktoriert werden, dass sie möglichst wenige hard coded Abhängigkeiten haben.
- Kommentare möglichst vermeiden, da sie meist sowieso nicht gepflegt werden. Besser sind selbsterklärende Funktions- und Variablennamen.
- Ein doc-Block für API-Methoden muss jedoch sein (für die User der API).
Lesbar wie ein Buch
- Buch = Modul
- Packagenames = Kapitelüberschriften
- Kapitel = Sammlung von Klassen
- Buchseite = Klasse
- aufgerufene Funktionen immer im Code unter der aufrufenden schreiben
- sinnvolle Funktionsnamen verwenden
Eine Funktion hat genau eine Funktion.
- Parameter sparen, möglichst viel über Klassenproperties abdecken
- geschlossene Systeme mit Klassen schaffen
- keine Branches ("if/then/else" Verzweigungen) in der Logik
Kontrollkonstrukte eliminieren!
- Durch Branches (if-Konstrukte) in der Logik hat eine Funktion meist nicht mehr nur eine Funktion.
- Branches und Switches (switch/if-Konstrukte) aufteilen
- interface mit canRun()/run()-Methoden
- in einer Schleife alle Implementierungen des Interfaces durchlaufen, die erste die canRun() mit true beantwortet, deren run()-Methode wird aufrufen
Strikte Trennung von Logik und Fehlerprüfung
- Trennung von Fehlerbehandlung und Logik
- error checking standardisieren
- immer am Anfang einer Methode
- Logik ohne störende Kontrollkonstrukte am Ende
- idealerweise in eine eigene Funktion abkapseln
- error checking standardisieren
Teile und herrsche
- monolithische Systeme immer weiter aufteilen
- Je kleiner die Teile eines Systems sind, desto beherrschbarar sind sie für Menschen.
- siehe Quicksort, Design Patterns, rekursive Funktionen allgemein
Emergenz
- Zusammenschluss vieler einfacher Komponenten
- Bsp.: Schwärme, neuronale Netze, Würfelhaufen/Flummis, Conway's Game of Life, genetische/evolutionäre Algorithmen
- Was passiert da?
- Kontrolle an die Einzelteile abgeben
- Jedes Element kennt selbst den besten Weg, eine Situation zu behandeln.
- Komponenten können miteinander kommunizieren.
- Durch die Verbindungen entstehen neue Eigenschaften des Gesamtsystems (leider nur schwer vorhersagbar, welche. siehe Bewusstsein und freier Wille).
- Einige Eigenschaften sind jedoch vorhersagbar - und das kann man nutzen!
- Es gibt keinen "master", der die Einzelteile kontrolliert (Anmerkung: also auch kein Script, das Kommandos verbindet. Als emergent könnte man es bezeichnen, wenn zwei oder mehr Scripte autonom agieren und Daten miteinander austauschen.)
- Insofern können auch autonome Module, Klassen und Funktionen emergentes Verhalten produzieren. -> siehe Multithreading
Aktuelle Forschungsschwerpunkte
- Erhöhung der Systemsicherheit
- fehlertolerante Systeme
- fehlerbehebende Systeme
- cyber physical systems
- Standardisierung von Komponenten & model driven development (nutzbare Variante, nicht CASE)
- Vorbild: Automobilindustrie
- Zuverlässigkeit
- Vorhersagbarkeit der Kosten & Entwicklungszeit
- standardisierte Tests
- hochgradig wiederverwendbare Komponenten
- standardisierte Schnittstellen
- Vorbild: Automobilindustrie
=> das Ziel: Software Design => Software *Engineering*