Dann könnte dieser Artikel sehr hilfreich sein:
http://polywogsys.livejournal.com/286952.html
Monday, December 5, 2011
Saturday, February 5, 2011
Clean Code Developer: 3. Gelber Grad - Zusammenfassung
Also, dann auf zum dritten Grad...1. Prinzipien
1.1 Interface Segregation Principle
Warum? Leistungsbeschreibungen, die unabhängig von einer konkreten Erfüllung sind, machen unabhängig.
- Interfaces sollten möglichst klein sein, um unnötige Kopplung zu vermeiden.
- Interfaces sollten nur Dinge enthalten, die wirklich eng zusammen gehören (hohe Kohäsion).
- Ziel: möglichst geringe Kopplung ziwschen den Komponenten
Warum? Punktgenaues Testen setzt Isolation von Klassen voraus. Isolation entsteht, wenn Klassen keine Abhängigkeiten von Implementationen mehr enthalten – weder zur Laufzeit, noch zur Übersetzungszeit. Konkrete Abhängigkeiten sollten deshalb so spät wie möglich entschieden werden. Am besten zur Laufzeit.
- High-Level Klassen sollen nicht von Low-Level Klassen abhängig sein, sondern beide von Interfaces.
- Interfaces sollen nicht von Details abhängig sein, sondern Details von Interfaces.
- Mindestanforderung im 3. Grad: Abhängigkeiten über Konstruktoren injizieren
Warum? Wer mit Erben zu tun hat, möchte keine Überraschungen erleben, wenn er mit Erblassern vertraut ist.
- Kernaussage: Subtypen müssen sich so verhalten wie ihr Basistyp
- allgemeiner: ein Subtyp darf die Funktionalität eines Basistyps lediglich erweitern, aber nicht einschänken
- Empfehlung: über Vererbung genau nachdenken
- siehe Favor Composition over Inheritance (FCoI), roter Grad
- bei Vererbung über Verhalten nachdenken, nicht nur über Struktur
Warum? Wenn sich eine Komponente überraschenderweise anders verhält als erwartet, wird ihre Anwendung unnötig kompliziert und fehleranfällig.
- Software sollte überraschungsarm implementiert sein. Jede Überraschung stellt eine Unterbrechung dar und stört den kreativen Prozess der Softwareentwicklung.
- Die testgetriebene Entwicklung fördert überraschungsarme Schnittstellen.
Warum? Durch das Verbergen von Details in einer Schnittstelle werden die Abhängigkeiten reduziert.
- Je mehr Details von außen sichtbar sind, desto höher ist die Kopplung zwischen der Klasse und ihren Verwendern.
- Benutzen die Verwender einer Klasse erstmal ein Detail, wird es schwerer, dieses Detail zu verändern.
2.1 Automatisierte Unit-Tests
Warum? Nur automatisierte Tests werden auch wirklich konsequent ausgeführt. Je punktgenauer sie Code testen, desto besser.
- Regressionstests, um Korrektheit von Änderungen sicherzustellen und Angst vor Änderungen zu nehmen
- Automatisierung notwendig, da händisch nicht praktikabel
- Automatisierte Tests sparen Zeit und nehmen Angst.
Warum? Ohne Attrappen keine einfach kontrollierbaren Tests.
- Will man eine Komponente isoliert testen, müssen die Abhängigkeiten zu anderen Komponenten abgetrennt werden.
- Beim Isolieren werden sogenannte Mockups anstelle der echten Komponenten verwendet.
- andere Bezeichnungen für Attrappen: Stub, Dummy, Fake (teilweise mit unterschiedlichen Funktionsweisen)
Warum? Traue nur Tests, von denen du weißt, dass sie auch wirklich das Testareal abdecken.
- Unit Tests sollten nach Möglichkeit alle Pfade durch unseren Code abdecken.
- Die Code Coverage Analyse dient dazu, Bereiche im Code aufzudecken, die noch nicht während der automatisierten Tests ausgeführt werden.
- Mögliche Metriken:
- C0-Überdeckung = Anweisungsüberdeckung
- C1-Überdeckung = Entscheidungs- / Zweigüberdeckung
- Ziel: theoretisch 100% Überdeckung, praktisch mehr als 90% Überdeckung
Warum? Am besten lernen wir von anderen und in Gemeinschaft.
- Gedankenaustausch, Diskussionen, Erfahrungen austauschen, "über den Tellerrand blicken"
- z.B. regionale User Groups, überregionale Entwicklerkonferenzen
Warum? Es ist nicht möglich, Code direkt in der ultimativen Form zu schreiben.
- Erweiterung zum roten Grad
- unbedingte Voraussetzung: automatisierte Tests
Wednesday, February 2, 2011
Clean Code Developer: 2. Oranger Grad - Erfahrungen
Puhhh, der orange Grad hat sich sehr in die Länge gezogen. Nicht etwa weil ich ständig das Armband auf die andere Seite hätte wechseln müssen, sondern eher weil ich so wenig zum Programmieren gekommen bin. Zum Jahresende 2010 war's dann endlich geschafft und schon Anfang Februar 2011 komme ich dazu, den Blog nachzuziehen. Eine Zusammenfassung der Prinzipien und Praktiken sind in meinem Post vom 07. Juni 2010 zu finden. Hier meine Erfahrungen und Meinungen...3. Ergebnisse
3.1 Single Level of Abstraction (SLA)
- Status: gelb
- Meine Meinung: Beachte ich meist "aus dem Gefühl heraus". Dieses Prinzip muss ich in Zukunft noch mehr verinnerlichen.
- Erkenntnisse:
- Eine manuelle Überprüfung, ob dieses Prinzip eingehalten wurde, ist sehr mühselig. Eine automatische Überprüfung ist unmöglich.
- Man sollte beim Lesen einer Methode auf sein Bauchgefühl hören und bei Bedarf dann genauer hinsehen, ob SLA eingehalten wurde.
- Status: grün
- Meine Meinung: Im Tagesgeschäft beachte ich diese Regel. Immer, wenn ich neue Funktionalität zu einer Klasse hinzufüge, frage ich mich vorher, ob dies noch zur Aufgabe der Klasse gehört oder nicht.
- Erkenntnisse:
- Natürlich ist man manchmal versucht, noch eine "Kleinigkeit" zu einer Klasse hinzuzufügen, aber hier muss man Disziplin wahren...
- Status: gelb
- Meine Meinung: Ich achte insgesamt stärker auf die Einhaltung von SoC. Manchmal ist es nicht einfach, die verschiedenen Belange sauber zu trennen, so dass ich in berechtigten Fällen durchaus der pragmatischeren Lösung den Vorzug gebe.
- Erkenntnisse:
- Die Aspektorientierte Programmierung scheint hier das Mittel der Wahl zu sein.
- Meine persönlichen Erfahrungen mit der AOP waren bisher allerdings eher ernüchternd bis frustrierend. Die Integration in die Eclipse IDE funktionierte nicht richtig und das Zusammenspiel mit RCP bzw. OSGi ist ein einziger Alptraum. Natürlich gibt's da haufenweise tolle Präsentationen von smarten Consultants zu dem Thema, aber ich halte die Kombination RCP / OSGi / AOP im Moment nicht für praxistauglich.
- Status: grün
- Meine Meinung: Code-Konventionen sind vorhanden und werden seit längerer Zeit schon angewendet. Es existiert ein schriftliches Regelwerk plus Konfigurationen für Checkstyle und PMD. Beide Tools werden sowohl in der Eclipse IDE, als auch im Nightly Build ausgeführt.
- Status: grün
- Meine Meinung: Wird seit längerem bereits eingesetzt und hat sich ohne Frage bewährt.
- Tools:
- früher Mantis, http://www.mantisbt.org/
- aktuell Trac, http://trac.edgewall.org/
- und die Tracker der SourceForge-Projekte
- Status: gelb
- Meine Meinung: Automatisierte Integrationstest sind nur wenige vorhanden. Die Integrations- und Unit-Tests werden aktuell in den Nightly Build integriert.
- Tools:
- Hudson, http://hudson-ci.org/
- JUnit, http://www.junit.org/
- Ant, http://ant.apache.org/
- Eclipse Test Framework (ETF), http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.test/testframework.html?view=co
- PDE Test Utilities, http://www.eclipse.org/articles/Article-PDEJUnitAntAutomation/index.html#PDE_Test_Utilities
- Erkenntnisse:
- Seit Eclipse Helios wird JUnit 4 vom automatischen PDE-Build unterstützt.
- Status: gelb
- Meine Meinung: Vom Java-Magazin und Eclipse-Magazin lese ich jede Ausgabe, Blogs nur bei Bedarf und Fachbücher max. 2 pro Jahr. Mehr ist zeitlich leider nicht drin.
- Status: gelb
- Meine Meinung: Pair-Reviews sind bei mir nicht möglich. Direkt vor jedem Commit führe ich immer einen Review meines eigenen Codes durch, was sich sehr bewährt hat.
Friday, January 28, 2011
Zurück von der OOP 2011
Wow, nun ist sie leider schon wieder vorbei, die OOP 2011. Es wurde diesmal ein tolles Programm geboten, inklusive einige lebender Legenden, wie z.B. Erich Gamma, Martin Fowler, Tom DeMarco und Gunter Dueck. Spitze!
Subscribe to:
Posts (Atom)
Posts
