Archive for November, 2009

Der vorherige DbC-Artikel ist ziemlich “abstrakt” ausgefallen, es haben einfach Beispiele gefehlt. Das möchte ich hiermit nachholen.

Erstens muss man die IDE anpassen: im März kommt .NET 4.0 raus und da wird Design by Contract mitgeliefert. Man kann das Konzept aber jetzt schon anwenden, wenn man die Assembly zusätzlich installiert. Danach muss man die dll referenzieren und im Eigenschaftenfenster des Projektes im neuen Tab Code Contracts das Runtime Checking einstellen.

Jetzt zum Code: Nehmen wir eine ganz einfache Klasse Bill deren Objekte mit einem IRepository gespeichert bzw. geladen werden.

    1 using System.Diagnostics.Contracts;

    2 namespace ContractsPrototyp

    3 {

    4     public class Bill

    5     {

    6         public int Id { get; set; }

    7         public string Number { get; set; }

    8         public double Value { get; set; }

    9     }

   10 

   11

   12     public interface IRepository

   13     {

   14         Bill GetBill(string number);

   15         void SaveBill(Bill bill);

   16     }

Die Kontrakte kann man in den einzelnen Methoden oder für eine ganze Klasse schreiben (unter dem Attribut ContractInvariantMethode) aber ich finde am schönsten, dass man die auch auslagern kann: durch eine gegenseitige Markierung können Kontrakt-Klassen und Interfaces als “Paare” definiert werden:

   11     [ContractClass(typeof(RepositoryContracts))]

   12     public interface IRepository

   13     {

   14         Bill GetBill(string number);

   15         void SaveBill(Bill bill);

   16     }

   17     [ContractClassFor(typeof(IRepository))]

   18     public class RepositoryContracts:IRepository

   19     {

   20         public Bill GetBill(string number)

   21         {

   22             Contract.Requires(!string.IsNullOrEmpty(number));

   23             return null;

   24         }

   25 

   26         public void SaveBill(Bill bill)

   27         {

   28             Contract.Ensures(bill.Id > 0);

   29         }

   30     }

Eine Vorbedingung wird mit Contract.Requires und eine Nachbedingung mit Contract.Ensures definiert. Beide Methoden bekommen boolische Ausdrücke. Diese Ausdrücke müssen frei von Seiteneffekten sein.

Die eigentliche Implementierung der Klasse schaut dann so aus:

   31     public class Repository:IRepository

   32     {

   33         public Bill GetBill(string nummer)

   34         {

   35             //Würde das Objekt aus Datenhaltung laden

   36             return new Bill();

   37         }

   38 

   39         public void SaveBill(Bill bill)

   40         {

   41             //Würde das Objekt speichern und ihm eine Id zuweisen

   42             if (BillIsValid( bill )) bill.Id++;

   43         }

   44 

   45         private static bool BillIsValid(Bill bill)

   46         {

   47             return !string.IsNullOrEmpty(bill.Nummer);

   48         }

   49     }

Woher können wir wissen, dass das funktioniert? Es ist einfach, wir schreiben ein Paar Tests dazu!
Bei Kontraktverletzung wird eine Exception geworfen. Um diese – und dadurch die genaue Verletzung – überprüfen zu können braucht man etwas Workaround:

   55     [TestFixture]

   56     public class BillTests

   57     {

   58         private IRepository m_repository;

   59         private string m_message;

   60 

   61         [SetUp]

   62         public void Setup()

   63         {

   64             m_repository = new Repository();

   65             m_message = string.Empty;

   66             Contract.ContractFailed += ( sender, e ) =>

   67             {

   68                 e.SetUnwind();

   69                 m_message = e.Message;

   70             };

   71         }

Danach sind die Tests dann einfach:

   73         [Test]

   74         public void Laden_mit_leerer_Nummer_verletzt_Kontrakt()

   75         {

   76 

   77             try

   78             {

   79                 m_repository.GetBill( null );

   80             }

   81             catch

   82             {

   83                 //Nichts

   84             }

   85 

   86             Assert.That( m_message, Is.EqualTo( "Precondition failed: !string.IsNullOrEmpty(number)" ) );

   87         }

   88 

   89         [Test]

   90         public void Speichern_Rechnung_ohne_Nummer_verletzt_Kontrakt()

   91         {

   92 

   93             try

   94             {

   95                 m_repository.SaveBill( new Bill{Value = 25} );

   96             }

   97             catch

   98             {

   99                 //Nichts

  100             }

  101 

  102             Assert.That( m_message, Is.EqualTo( "Postcondition failed: bill.Id > 0" ) );

  103         }

Ich hoffe, das Beispiel ist ausführlich genug, um die Vorteile von DbC zu highlighten. Stefan, vielen dank noch mal für den Artikel, ich habe mich natürlich von dir inspirieren lassen.

kick it on dotnet-kicks.de

Comments 2 Comments »

Endlich ist es geschafft. Ich habe das Buch “Clean Code” von Robert C. Martin a.k.a. Uncle Bob durchgelesen. Nach dem ersten Teil hier nun die versprochene Fortsetzung meiner Zusammenfassung:

10 Classes

Die erste Regel von Klassen lautet: Sie sollten klein sein.
Die zweite Regel von Klassen lautet: Sie sollten noch kleiner sein als das.

Klassen sollten eine hohe Kohäsion haben.
Kohäsion ist ein Maß dafür, wie stark die Methoden und Daten einer Klasse miteinander zu tun haben. Zur Verdeutlichung:
Eine Klasse, in der jede Membervariable von jeder Methode der Klasse verwendet wird, ist maximal kohäsiv.

Bei Klassen sollten folgende Prinzipien beachtet werden:

  • Das Single Responsibility Principle (SRP), welches besagt:
  • Eine Klasse oder ein Modul sollte nur einen Grund haben sich zu ändern. Eine Klasse sollte sich nur um EINE Sache kümmern.

  • Das Open Close Principle (OCP), welches besagt:
  • Klassen sollten offen für Erweiterungen sein, aber geschlossen für Modifikation.

  • Das Dependency Inversion Priniciple (DIP), welches besagt:
  • Klassen sollten von Abstraktionen abhängen und nicht von konkreten Klassen.

11 Systems

Separiere Konstruktion von Benutzung.
Realisiert werden kann das durch Dependency Injection.

Dependency Injection = Klassen bekommen ihre Abhängigkeiten von außen über den Konstruktor oder Setter übergeben. Dieses Pattern unterstützt das SRP, da sich die Klasse nicht mehr um das Instanzieren dieser Abhängigkeiten kümmern muss. Realisiert wird das ganze über Inversion of Control Container wie Windsor, Spring und wie sie alle heißen. Bei diesen Containern werden die Abhängigkeiten einmalig definiert, so dass man sich bei der Instanzierung nicht mehr darum kümmern muss.

Wenn Objekte zu einer bestimmten Zeit erstellt werden müssen, sollten Factories verwendet werden.

Systeme werden nicht von heute auf morgen gebaut. Sie werden nach und nach ausgebaut. Um sicherzustellen, dass dabei noch alles funktioniert, gibt es TDD, Refaktorisieren und Separation of Concerns.

12 Emergence

Viele Leute sagen, dass Kent Beck’s 4 “Rules of Simple Design” einem sehr helfen, gut designte Software zu erstellen.

Kent Beck sagt:
ein Design ist „simple“, wenn:

  • alle Tests durchlaufen
  • kein doppelter Code vorhanden ist
  • wenn es die Absicht des Programmierers ausdrückt
  • die Anzahl von Klassen und Methoden minimiert sind

in der Reihenfolge.

13 Concurrency

In Multithread-Anwendungen bekommt man schon bei minimaler Anforderung ein Problem mit der Komplexität. Da mit steigender Komplexität auch die Fehleranfälligkeit steigt, gibt es ein paar Prinzipien, die diese minimieren können:

Die Concurrency Defense Principles

  • Single Responsibility Principle
  • Trenne multithreaded Code von nicht-multithreaded Code

  • Limit the Scope of Data
  • Man sollte den Bereich, in dem multithreaded Code verwendet wird, möglichst klein halten.

  • Use Copies of Data
  • Verschiedene Threads sollten nicht mit demselben Objekt arbeiten. Wenn möglich sollte mit Kopien von diesem Objekt gearbeitet werden.

  • Independence
  • Threads sollten so unabhängig wie möglich sein

  • Library
  • Natürlich sollte man die Bibliothek, die man für Multithread-Anwendungen verwendet, sehr gut kennen.

14 Successive Refinement

Um Clean Code schreiben zu können, muss man erst Dirty Code schreiben und ihn dann bereinigen.

Einer der besten Wege, ein Programm zu ruinieren, ist, massive Änderungen an der Struktur vorzunehmen, um das Programm zu verbessern. Um das zu verhindern, nutzt man die Disziplinen von TDD. Eines der zentralen Doktrinen dieses Ansatzes ist es, das System zu jeder Zeit lauffähig zu halten. Mit TDD ist es also nicht erlaubt eine Veränderung am System vorzunehmen, die das System bricht.

15 JUnit Internals

JUnit Internals halt… (Kapitel überlesen)

16 Refactoring SerialDate

War mir eindeutig zu Java-lastig… (Kapitel überlesen)

17 Smells and Heuristics

In diesem Kapitel zeigt Uncle Bob eine Liste von Smells und wie man sie beseitigen kann. Er lobt das Buch “Refactoring” von Martin Fowler. Dieses Buch steht eh schon ganz oben auf meiner To-do-Liste. Das werde ich also demnächst angehen.

Zusammenfassung

An dieser Stelle ein Dank an mein Entwicklerteam, dass ich das Buch so lange in Beschlag nehmen durfte 🙂 (Teil 2 ging irgendwie zäher). Einen großen Dank auch an Peter Bucher und Rene Drescher-Hackel für ihre Ergänzungen bzw. Einwände. Man darf sicherlich nicht alles so ganz ernst nehmen und man kann es auch übertreiben (siehe Pyramiden etc.). Natürlich sollte man nicht blind durch die Welt laufen, sondern auch Dinge hinterfragen, aber man muss sagen, dass die Punkte von CCD (das ja auf diesem Buch beruht) durchaus plausibel sind. Ich denke schon, dass CCD unerfahrenen aber auch erfahrenen Entwicklern einen SOLIDen Weg zeigt, den man gehen kann und der sogar schon gepflastert ist. Man kann sich natürlich auch mit der Machete durch dichten Dschungel schlagen, was natürlich cool ist 🙂 – aber halt wesentlich langsamer. Es sei denn man ist Chuck Norris.

kick it on dotnet-kicks.de

Comments 1 Comment »

Seit Anfang des Jahres setzen wir nun SCRUM ein, wobei es, wie man jetzt merkt, doch nur SCRUMBUT war.

I call that phenomena “Scrumbut”. It shows up in the following way:
“We’re doing Scrum but…”
* our sprints are 12 weeks long…
* we do two normal sprints and one bugfix sprint…
* we do all our planning up front…
* we skip the daily meeting…
* our managers decide what’s in each sprint…
* we haven’t read the books yet…
* our team has 30 people…
http://blogs.msdn.com/ericgu/archive/2006/10/13/scrumbut.aspx

Auch bei uns wurden Anpassungen an SCRUM durchgeführt, was dazu geführt hat, dass die letzten Sprints immer schlechter wurden. Gerade die Retrospektive wurde fast nie durchgeführt, da es angeblich nichts zu besprechen gab.

Wir sind nun in Sprint 21 und nach 2 Open Spaces um ausreichenden Erfahrungsaustausch reicher. Wir halten wieder die Retrospektive-Meetings und bei dem letzten haben wir folgende Anpassungen beschlossen:

  • Es wurde eine “Definition-of-done” Richtlinie am Whiteboard erstellt.
  • Pair-Programming wird häufiger eingesetzt.
  • Zu jedem Backlog-Item werden gemeinsam die Architekturveränderungen und die notwendigen Tasks besprochen. Bisher wurde mit den Produkt-Backlogkarten direkt gearbeitet.

Ich rate allen, die SCRUM einführen wollen, sich wirklich so nah wie möglich an SCRUM zu halten. Die Sprints 1 – 15 wirkten bei uns auch sehr gut, doch erst danach fiel uns auf, dass gerade die Sprint-Retrospektive ein sehr wichtiges Meeting ist. All diese Regeln sind durch mehrjährige Erfahrungen entstanden und sie haben sich schon in größeren Firmen bewährt. Warum dann nicht davon profitieren?

kick it on dotnet-kicks.de

Comments 2 Comments »