CleanCode: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
| (8 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
{{TOCRight}} | |||
== Clean Code Development == | == Clean Code Development == | ||
Clean Code ist ein von Robert C. Martin in seinem gleichnamigen Buch <ref> | Clean Code ist ein von Robert C. Martin in seinem gleichnamigen Buch <ref> | ||
Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 Edition, 2008. [http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Bei Amazon.]</ref> geprägter Begriff aus der Softwareentwicklung welcher in erster Linie Quellcode aber auch andere Dokumente und Konzepte bezeichnet welche intuitiv verständlich sind. <ref>Seite „Clean Code“. In: Wikipedia | Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 Edition, 2008. [http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Bei Amazon.]</ref> geprägter Begriff aus der Softwareentwicklung welcher in erster Linie Quellcode aber auch andere Dokumente und Konzepte bezeichnet welche intuitiv verständlich sind. <ref>Seite „Clean Code“. In: Wikipedia https://de.wikipedia.org/wiki/Clean_Code</ref> | ||
=== Warum Clean Code? === | === Warum Clean Code? === | ||
Als Clean Code bezeichnet man intuitiv verständlichen Programmcode. Die Idee von Clean Code basiert auf der Beobachtung, dass ein Großteil der Arbeitszeit in einem Projekt auf der Arbeit mit bereits bestehendem Programmcode basiert (Wartung, Erweiterung, Debugging). Programmcode der „clean“ ist unterstützt diese Arbeit durch seine Verständlichkeit und Struktur. Umgekehrt ist arbeiten mit nicht „clean“ Code oft eine zeitaufwändig und | Als Clean Code bezeichnet man intuitiv verständlichen Programmcode. Die Idee von Clean Code basiert auf der Beobachtung, dass ein Großteil der Arbeitszeit in einem Projekt auf der Arbeit mit bereits bestehendem Programmcode basiert (Wartung, Erweiterung, Debugging). Programmcode der „clean“ ist unterstützt diese Arbeit durch seine Verständlichkeit und Struktur. Umgekehrt ist arbeiten mit nicht „clean“ Code oft eine zeitaufwändig und fehleranfällige Übung in Geduld während man versucht das Werk eines anderen (oder eines jüngeren Selbst) nachzuvollziehen. | ||
=== Benennung === | === Benennung === | ||
| Zeile 30: | Zeile 31: | ||
Programmteile sollten sich so verhalten, "wie man es erwartet". Funktionen sollten sich ihrem Namen entsprechend verhalten und Seiteneffekte sollten klar ersichtlich und gut dokumentiert sein. | Programmteile sollten sich so verhalten, "wie man es erwartet". Funktionen sollten sich ihrem Namen entsprechend verhalten und Seiteneffekte sollten klar ersichtlich und gut dokumentiert sein. | ||
[ | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment → mehr dazu] | ||
===== [http://clean-code-developer.de/die-grade/roter-grad/#Dont_Repeat_Yourself_DRY Don't repeat yourself (DRY)] ===== | ===== [http://clean-code-developer.de/die-grade/roter-grad/#Dont_Repeat_Yourself_DRY Don't repeat yourself (DRY)] ===== | ||
| Zeile 38: | Zeile 39: | ||
Einfache Lösungen sind immer zu bevorzugen. Zerlege komplizierte Probleme in Teilprobleme, bis die Teilprobleme nicht weiter zerlegbar sind. | Einfache Lösungen sind immer zu bevorzugen. Zerlege komplizierte Probleme in Teilprobleme, bis die Teilprobleme nicht weiter zerlegbar sind. | ||
[ | [https://de.wikipedia.org/wiki/KISS-Prinzip → mehr dazu] | ||
===== [http://clean-code-developer.de/die-grade/gruener-grad/#Law_of_Demeter Law of Demeter] ===== | ===== [http://clean-code-developer.de/die-grade/gruener-grad/#Law_of_Demeter Law of Demeter] ===== | ||
| Zeile 53: | Zeile 54: | ||
Zerteile ein Programm in unterschiedliche Bereiche (eigentlich auf Klassenebene, aber auch auf Komponentenebene anwendbar), die jeweils eine Aufgabe haben und die sich so wenig wie möglich überlappen. | Zerteile ein Programm in unterschiedliche Bereiche (eigentlich auf Klassenebene, aber auch auf Komponentenebene anwendbar), die jeweils eine Aufgabe haben und die sich so wenig wie möglich überlappen. | ||
[ | [https://en.wikipedia.org/wiki/Separation_of_concerns → mehr dazu] | ||
===== [http://clean-code-developer.de/die-grade/gelber-grad/#Liskov_Substitution_Principle Liskov Substitution Principle (LSP)] ===== | ===== [http://clean-code-developer.de/die-grade/gelber-grad/#Liskov_Substitution_Principle Liskov Substitution Principle (LSP)] ===== | ||
| Zeile 69: | Zeile 70: | ||
===== [http://clean-code-developer.de/die-grade/gruener-grad/#Tell_dont_ask Tell, don't ask] ===== | ===== [http://clean-code-developer.de/die-grade/gruener-grad/#Tell_dont_ask Tell, don't ask] ===== | ||
Eine Klasse sollte nicht von außen über ihren internen Zustand befragt werden können. Es ist besser dem Objekt mitzuteilen was es zu tun hat. Das verlagert die Logik zur Benutzung der Klasse in die Klasse selbst und der Benutzer muss sich darüber keine Gedanken mehr machen. Als Ergebnis entstehen Objekte mit Verhalten statt "dummer" Datenhaltungsobjekte. | Eine Klasse sollte nicht von außen über ihren internen Zustand befragt werden können. Es ist besser dem Objekt mitzuteilen was es zu tun hat. Das verlagert die Logik zur Benutzung der Klasse in die Klasse selbst und der Benutzer muss sich darüber keine Gedanken mehr machen. Als Ergebnis entstehen Objekte mit Verhalten statt "dummer" Datenhaltungsobjekte. | ||
===== [http://clean-code-developer.de/die-grade/gelber-grad/#Dependency_Inversion_Principle Dependency Inversion Principle (DIP)] ===== | ===== [http://clean-code-developer.de/die-grade/gelber-grad/#Dependency_Inversion_Principle Dependency Inversion Principle (DIP)] ===== | ||
| Zeile 81: | Zeile 80: | ||
===== [http://clean-code-developer.de/die-grade/roter-grad/#Vorsicht_vor_Optimierungen Beware of Optimizations] ===== | ===== [http://clean-code-developer.de/die-grade/roter-grad/#Vorsicht_vor_Optimierungen Beware of Optimizations] ===== | ||
Optimierung bedeutet Aufwand und komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man darauf verzichten. | Optimierung bedeutet Aufwand und komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man darauf verzichten. | ||
===== Favour Composition over Inheritance (FCoI) ===== | ===== Favour Composition over Inheritance (FCoI) ===== | ||
Komposition ist flexibler als Ableitung. Bevor man von einer Klasse ableitet, sollte man sich daher immer zuerst fragen, ob man dasselbe Ergebnis nicht auch mit Komposition erreichen kann. | Komposition ist flexibler als Ableitung. Bevor man von einer Klasse ableitet, sollte man sich daher immer zuerst fragen, ob man dasselbe Ergebnis nicht auch mit Komposition erreichen kann. | ||
[http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ → mehr dazu] | [http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ → mehr dazu] | ||
