Agile Entwickung

Wer in .net mit Resourcen arbeitet, wird sich über dieses Tool wahrhaftig freuen! Es erweitert das Context Menü im Visual Studio für Refactoring und ermöglicht ein schnelles auslagern von Strings in die Resourcen.

Zu finden ist es unter Codeplex oder direkt unter Resource Refactoring!

Von 20 Sekunden auf weniger 1 Sekunde!

Man sollte meinen, dass das Vergleichen zweier Strings nicht viel Performance in Anspruch nehmen sollte, aber man wird ja immer wieder eines besseren belehrt!

Ein relativ kurzer Codeabschnitt hatte eine enorm lange Durchlaufzeit. Problem war, das zwei Schleifen verschachtelt werden mussten und zudem in der zweiten Schleife noch zwei Stringvergleiche integriert werden mussten! Die Stringvergleiche sahen in etwa so aus:

string val = "SOMEVALUE"; if (val.ToLower() == "somevalue")

Da es sich um recht viele Daten gehandelt hat, wurde die ToLower Methode insgesamt 13,5 Mio mal aufgerufen. Für diesen simplen Code nahm der Prozessor gleich 20 Sekunden in Anspruch.

Nun änderten wir den Stringvergleich folgendermaßen ab:

string val = "SOMEVALUE"; if (val.Equals("somevalue", StringComparison.OrdinalIgnoreCase))

Das Ergebnis ist immer noch das selbe, allerdings wurde somit die Dauer auf weniger 1 Sekunde gebracht!

Die ToLower Methode erzeugt bei jedem Aufruf einen neuen String, der zurückgegeben wird. Allein die Erstellung des neuen Strings nimmt enorm viel Zeit in Anspruch!

Wir haben ein neues Projekt. Die Entwicklung soll mit insgesamt sechs Entwicklern von statten gehen. Wir haben uns wieder für die Programmiersprache c# entschieden, damit wir unseren Sourcecode testbar halten können. Die Entwicklungszeit wurde auf drei Monate geschätzt. Um wirklich alle Features in das Release integrieren zu können, dürften keine weiteren größeren Zwischenfälle auftreten.

Da wir schon seit einem Monat bei der Entwicklung sind, möchte ich jetzt auch schon einmal ein Zwischenfazit ziehen.
Zum einen haben wir in diesem Projekt zum ersten Mal viel weniger Storykarten als sonst immer. Wir haben uns dazu entschlossen die Karten dieses Mal großer zu fassen, da in den vergangenen Projekten die Übersichtlichkeit aufgrund viel zu vieler kleiner Karten erheblich litt. Dies hat sich bereits jetzt schon bewährt. Es ist nun leicht die Übersicht über das Projekt zu behalten.
Da wir nun weniger Karten haben, haben wir nun endlich ausführliche Taskkarten zu den Storykarten eingeführt. Diese beschreiben den technischen Part der Entwicklung einer Story. Mit diesen Karten hat der Projektleiter allerdings nichts zu tun, diese sind nur für uns Entwickler gedacht.
Auch 'Continuous Integration' funktioniert wunderbar. Jeder checkt seine Änderungen am Sourcecode mehrmals täglich in den gemeinsamen Datenbestand ein. Somit ist jeder immer auf dem aktuellsten Stand der Dinge. Hinzu kommt das unser Buildserver ständig alle Änderungen an diesem Projekt neu kompiliert und unsere Testassemblies komplett testet.
Was noch nicht so gut funktioniert hat, war die Planung vor Projektbeginn. Wir hatten zu wenige Informationen, um eine wirklich präzise Zeitabschätzung zu geben. Diese Fragen konnten wir mittlerweile durch den 'On-Site Customer' klären und können somit auf ein positives Projektende hoffen.

Scott Guthrie und Scott Hanselman haben in Ihren Blogs das MVC Framework vorgestellt, das schon bald als Download zur Verfügung gestellt werden soll. Ich arbeite nun seit über zwei Jahren nach dem Model View Controller Pattern. Mit den Erfahrungen, die ich mir in dieser Zeit erarbeitet habe, muss ich das Framework leider kritisieren.
Wir haben vor zwei Jahren mit dem selben Schema angefangen. Unsere Projekte wurden mit Hilfe von drei Verzeichnissen (Model, View und Controller) unterteilt. Für kleine Projekte ist das auch vollkommen ausreichend. Die Datenbindung wird im Model vollzogen und die gebundenen Daten werden mit Hilfe des Controllers an die View gegeben und dort wiederum ausgegeben.
Die Verzeichnisstruktur verleitet dazu sich direkt Daten aus dem Model zu holen und auf der Webseite anzuzeigen und somit den Controller komplett zu übergehen.
Für kleine Projekte, die im Endeffekt nur Daten aus der Datenbank holen und diese auf der Webseite darstellen sollen bzw. Daten auch wieder in der Datenbank abspeichern sollen, ist das so auch in Ordnung. Doch schon bei etwas größeren Projekten fehlt ein wesentlicher Bestandteil, der normalerweise im Model mit abgebildet sein soll: Die Businesslogik.
Die Businesslogik ist bei komplexeren Projekten am wichtigsten und ist der Hauptteil des Models. Die Model-Schicht bietet eine API an, die dem Controller zur Verfügung gestellt wird. Um eine saubere Trennung zwischen den Schichten herzustellen, hat uns die Erfahrung gelehrt für jede Schicht ein eigenes Projekt anzulegen.
Die drei Schichten sind immer noch folgende:

• View
• Controller
• Model

Allerdings hat jede Schicht ein eigenes Projekt. Somit werden unerwünschte Zugriffe z.B. von der View direkt zum Model, unterbunden. D.h. die View darf nur mit dem Controller kommunizieren und das Model selbst darf auch nur mit dem Controller kommunizieren.
Wie schon erwähnt ist das Model die wohl wichtigste Schicht. Um in diese Schicht nochmal Struktur zu bringen, haben wir diese Schicht nochmals in drei kleineren Schichten unterteilt:

• API
• DataModel
• DAL

Die drei Schichten sind klar definiert und helfen einem sehr bei der Entwicklung bzw. auch bei späteren Weiterentwicklungen.
API: Das Application Programming Interface ist die oberste Schicht und besitzt als einzige Klassen mit öffentlichen Methoden. Der Controller hat nur die Möglichkeit mit der API zu kommunizieren.
DataModel: Das DataModel ist ein Abbild der Datenbank. In dieses DataModel werden die Daten aus der Datenbank geladen und können dort verändert werden.
DAL: Der Data Access Layer ist für die Datenbindung zuständig. Dieser füllt die Daten aus der Datenbank in das DataModel bzw. speichert geänderte Daten wieder in der Datenbank ab.

Die Businesslogik kann sich je nach Anwendung entweder in der API oder im DataModel befinden.

Meine Meinung: Momentan scheint es leider so, dass das MVC Framework kein Platz für die eigentliche Businesslogik lässt. Für die kleinen Beispiel-Projekte wird diese auch nicht nötig sein. Allerdings werden bei der Entwicklung großer Projekte noch einige Unebenheiten aufteten, die durch das Framework entstehen werden.
Ich möchte aber nicht alles negativ reden! Das Mapping der URL's zu den Controller Klassen verspricht doch eine ganze Menge. Somit können die .NET Projekte endlich auf einfache Weise google-freundliche URL's anbieten.

Beim Herumstöbern in alten Projekten fand ich ein Projekt, das schon ca. 1 Jahr alt ist. Es handelt sich hierbei um ein Framework, das in php geschrieben ist. Es ist eine Nachstellung des .NET Framework's von Microsoft. Dieses Projekt ist meiner Meinung nach sehr Interessant, da man sieht, wie schnell php5 an seine Grenzen stößt. php5 hat im Gegensatz zu seinem Vorgänger php4 zwar einen riesigen Sprung in Richtung OOP gemacht, trotzdem ist in c# immernoch eine Menge mehr möglich!

In erster Linie ging es mir darum die Klassen DataTable, DataColumn, DataRow und die anderen dazugehörigen Klassen nachzustellen. Ziel des Projektes war es die Klassen möglichst genau den .NET Klassen nachzustellen. Diese Klassen sind zwar noch nicht sehr weit fortgeschritten, trotzdem stelle ich euch diese mal zum Download bereit. Die dazugehörigen Tests sind ebenfalls im Download enthalten.

framework_0.1.rar

Nachdem die Priorität in der letzten Zeit immer wieder gesunken ist und wir uns auf andere Projekte mehr konzentriert haben, stieg die Priorität in der letzten Woche wieder extrem an! Somit konnten wir nun auch schon den ersten Testlauf starten. Die neue Software wird nun Firmenintern genutzt und soll in den nächsten Wochen auch anderen Internetusern zur Verfügung gestellt werden!

In der Version 1.0 werden vorerst nur die rudimentären Funktionalitäten zur Verfügung gestellt werden. Neue Features sind schon in Planung und werden wohl nicht lange auf sich warten lassen!

Nach dem ersten Dämpfer folgt zugleich der zweite!

Als wir am 14. Mai das Projekt starteten, war noch sehr viel Optimismus im Spiel. Das Projekt wurde als wichtig empfunden und es wurden alle Hebel in Bewegung gesetzt, um möglichst schnell, online gehen zu können. Nicht mal einen Monat später sieht nun wieder alles anders aus. Andere Projekte werden als wichtiger empfunden. Wobei ich dem nicht immer ganz zustimmen kann. Momentan haben wir ganze fünf Projekte, die auf's endgültige Release warten, aber keines kommt wirklich zum Abschluss!

Vielleicht irre ich mich, aber ich denke, dass das alles damit zu tun hat, das wir keinen Releaseplan haben. Wir arbeiten zwar nach und nach unsere Karten ab, doch niemand weiß, wann ein Produkt als fertig gilt!

Allerdings möchte ich nicht alles schlecht reden! Wir haben ein Projekt, das nach einem strickten Plan abgearbeitet wird. Es wird genau definiert, wann es ein neues Release geben wird und was in diesem Release enthalten sein soll! Ein Team aus drei Mitarbeitern scheint dort wirklich alles im Griff zu haben! An dieser Stelle möchte ich dem Team ein großes Lob aussprechen: "Echt super... macht weiter so!!"

Der anfängliche Optimismus hat einen Dämpfer erhalten.

Nachdem wir in den letzten beiden Wochen gut voran gekommen sind, kamen wir nun unverhofft ins Stocken. In den aktuellen Sprint haben wir zwei Stories genommen, die auf eine externe Komponente zugreifen. Diese externe Komponente wird auch von einem Team aus der gleichen Firma programmiert. Leider ist diese nicht rechtzeitig fertig geworden.

Sofort nach erhalt der Nachricht, haben wir unsere beiden Stories aus dem Sprint genommen und eine neue Karte wieder in den Sprint hineingezogen. Allerdings war der Zeitaufwand der neuen Karte nicht identisch, sondern kürzer.

Den Rest der Zeit haben wir, nach Absprache, für ein großes Refactoring genutzt. Somit haben wir einen großen Teil des Quellcodes neu strukturiert. Die Handhabung des Projektes wurde somit wesentlich erleichtert und in zukünftigen Sprints könnte somit mehr geschafft werden.

Bei der Neu-Planung eines Projektes ist uns aufgefallen, das wir vor genau einem Jahr schon mal damit angefangen haben! Dieses Projekt geriet im Laufe der Zeit immer weiter in den Hintergrund, bis es dann irgendwann komplett zum Stillstand kam und nie online gegangen ist.

Nun, ein Jahr später, sehen wir für das Projekt wieder eine Chance am Markt und wollen das erste Release zügig online bringen. Dazu muss zwar noch einiges gemacht werden, trotzdem sind wir guten Mutes, dass wir das erste Release innerhalb von einem Monat erstellen werden!

Ein erster Blick auf den Quellcode verriet mir allerdings, dass ich meinen "Refactoring-Hut" wieder aufsetzten muss. Es war schon immer so und es wird wohl auch immer so bleiben: Alter Quellcode ist nie gut und neuer Quellcode ist nach einer Woche meistens schon wieder alt!
Das ist einfach ein ewiger Kreislauf, aber genau deswegen ist auch das Refactoring so extrem wichtig!

Nach knapp drei Wochen arbeit, habe ich mit meinem Team endlich die neue Kundenverwaltung unserer Firma fertig gestellt. Diese musste erneuert werden, da das Hinzufügen von Funktionalität bei der alten Kundenverwaltung nahezu unmöglich war. Zudem hat sich Firmenintern einiges getan, was zur Folge hatte, dass das Konzept der alten Verwaltung komplett über den Haufen geworfen werden musste.

Bei der Neuerstellung sind allerdings viele Probleme aufgetreten, die wir nach und nach aber alle lösen konnten.

• Das Schätzen ist uns sehr schwer gefallen! Die Karten waren einfach zu Umfangreich. Und trotzdem haben wir diese nicht in mehrere kleine Karten aufgeteilt!?! Das müssen wir beim nächsten Projekt unbedingt verbessern, da unser letzter Sprint ziemlich schlecht verlief. Wir haben Aufgrund der Verschätzungen, die Karten nicht abarbeiten können, so gab es am Ende des Sprints noch offene Karten.
• Wir haben uns vorgenommen, unsere Projekte in einem bestimmten Pattern zu programmieren. Dieses Pattern hat drei Schichten: Application Programming Interface (API), Model und Data Access Layer (DAL). Um dieses Pattern Vernünftig durchzuziehen, haben wir lange Diskusionen geführt! Diese Gespräche waren oft zu lange und sollten sich beim nächsten Mal aufs Wesentliche beschränken.
• Wir haben uns beim Projektstart dazu entschlossen alle Schichten für sich zu testen. Das heißt, dass jeder Test nur seine eigentliche Funktionalität testet. Somit hätten wir auch die Möglichkeit gehabt, zuerst die API komplett fertig zu stellen und erst danach das Model oder auch den DAL fertig zu stellen. Um dies zu ermöglichen, kamen wir nicht drumrum die Funktionalität, die wir nicht testen wollten, zu mocken. Dies hat nicht nur erstaunlich gut funktioniert, sondern hat auch noch den Vorteil gebracht, das unsere Tests unglaublich schnell wurden! Dies lag daran, dass sowohl die API, als auch das Model nicht mehr auf die langsame Datenbank zugreifen musste. Die Daten kann nun der Mock zur Verfügung stellen!
• Das Pair Programming fiel in der zweiten Woche nahezu komplett flach! Dies lag daran, dass ein Mitarbeiter diese Woche über ausfiel und dadurch eine ungrade Anzahl an Programmierern entstand! Ansonsten ist das Pair Programming wirklich empfehlenswert, auch wenn (meiner Meinung nach) das Projekt nicht ganz so schnell voranschreitet. Es zahlt sich aber spätestens aus, sobald ein Mitarbeiter, aus welchen Gründen auch immer, ausfällt. Dieser Mitarbeiter kann dann ohne Probleme ersetzt werden!

Alles in allem war es ein erfolgreiches Projekt, welches mir sehr viel Spaß gemacht hat!

Das Testen des Quellcodes ist für mich mittlerweile etwas vollkommen selbstverständliches! Mittlerweile wir jede öffentliche Methode getestet! In c# besteht mittlerweile auch die Möglichkeit Methoden, die Internal sind, zu testen. Dazu muss lediglich das Attribut "InternalsVisibleTo" in der jeweiligen Assembly für die sogenannte "Friend Assembly" gesetzt werden! Somit besteht die Möglichkeit auch nicht öffentliche Methoden zu testen! Ob dies allerdings nötig ist, muss man selber abschätzen!
Als Faustregel gilt: Solange alle Tests für die öffentlichen Methoden laufen, sind auch die privaten Methoden korrekt!
Trotzdem gibt es manchmal private Methoden bei denen es sich vielleicht doch lohnt, Tests zu schreiben! Dies empfiehlt sich dann, wenn recht viel Funktionalität dahinter steckt!

Jetzt stellt sich noch die Frage, wann eigentlich getestet werden muss!? Mein Favorit ist ganz klar der Test-First Ansatz! Hierbei wird zuerst der Test und erst dann die eigentliche Funktionalität geschrieben! Zudem wird nicht mehr Code geschrieben als eigentlich nötig ist, um den Test erfolgreich abschließen zu können! Für den ersten Test (siehe unten) reicht es vollkommen aus nur den Wert 15 zurück zu geben! Sobald der Kunde allerdings definiert, dass er verschiedene Zahlen addieren will, muss sich natürlich auch die Methode an sich ändern! Das ist ein einfaches Beispiel, mit dem ich klar machen möchte, das Simple Design bei mir ganz weit oben steht! Das heißt, dass ich nie mehr programmiere als der Kunde von mir verlangt! Somit verhindere ich auch den Code auf Vorrat!

Hier nochmal ein paar hilfreiche Links, die das Testen wesentlich erleichtern:

• Testdriven
• NUnit
• ReSharper
• UnitRunner
• Profiler
• NCover
• NCoverExplorer
• Reflector
• TypeMock
• TeamSystem

Continue reading "Testing"

Unser Team trifft sich täglichen um Punkt 9.30 Uhr zum Standup-Meeting! Jeder berichtet kurz, welche Stories er am Tag davor bearbeitet hat und welche Besonderheiten es gab. Es passiert auch häufiger mal, dass sich daraus eine Diskusion entwickelt, diese wird dann aber umgehen unterbrochen, weil das Standup-Meeting nur zum Berichten des Projektfortschrittes gedacht ist. Diskusionen können im Nachhinein ausführlich und nur mit den direkt betroffenen Personen ausgetragen werden.

Wenn die Entwickler berichtet haben, was sie am vorigen Tag alles geschafft haben, kommt auch noch mal der Projektleiter und ausgewählte Kunden zu Wort. Diese berichten dann von aktuellen Ereignissen! Dadurch können wir unser Tagesgeschäft besser planen und effektiver an unseren Stories arbeiten!