XP

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!

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.

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!