ACHTUNG - NEUES BLOG

Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen EintrÃ¤gen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.

Clean Code Developer - Gedanken zum Online-Meeting

10.02.09 - Entwicklung, Diskussionen, Patterns, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder

Gestern hatte es das 3. Online Meeting von ALT.NET DE zum Thema Clean Code Developer (CCD) gegeben. Mit dabei war jede Menge Prominenz der deutschsprachigen .NET Community.

Ich möchte an dieser Stelle jetzt nicht das Thema Clean Code Developer (= die Initiative) breittreten - da kann sich jeder auf oben verlinkter Site informieren. Vielmehr möchte ich auf einen gestrigen Aspekt eingehen, dem ich nicht so wirklich zustimmen möchte und den ich gerne diskutieren würde.

Grundsätzlich, damit ich nicht falsch verstanden werde: Ich finde diese Initiative sehr gut, sie erhält meine vollste Unterstützung und auch ich versuche tagtäglich, mich und meinen Output zu verbessern.

Einer der Punkte, der gestern aufkam, betraf die Verteilung der Prinzipien, Paradigmen und Werte. Hier kam mehrfach zur Sprache, dass denn die Hersteller von Entwicklungstools, als auch die Lehre (konkret wurden Fachhochschulen angesprochen) hauptsächlich zur Verbreitung dieser Bewegung beitragen sollten, dies aber lange Zeit vernachlässigt wurde bzw. immer noch wird. Durch das Eine oder Andere Zitat eines FH-Professors sollte dies weiter unterstrichen werden.

Da ich selbst an einer Fachhochschule unterrichte und daher die "andere Seite" auch ganz gut kenne, möchte ich dazu meine Gedanken einbringen (dies gilt auch für Trainingscenter etc.):

Ich kann nicht beurteilen, wie Fachhochschulen in Deutschland aufgestellt sind. Ich kenne einige in Österreich und weiß daher, dass an zahlreichen Fachhochschulen wichtige Prinzipien zur Erhöhung der Software-Qualität gelehrt werden. Woraus besteht dies in vielen Fällen?

Vermittlung des notwendigen Stoffes
Hervorhebung der sich daraus ergebenden Vorteile
Laufende Verwendung, sofern möglich
Bei Bedarf Diskussion und Gegenüberstellung

Dies bedeutet: Die Lehre vermittelt das notwendige Wissen (Qualitätssicherungsmaßnahmen, Code Metriken, Code Coverage, Versionierung, Test, etc.). Auf dieser Basis werden die Vorteile klar hervorgehoben und versucht, diese in sämtlichen Projekten einzusetzen (Teile werden zwingend vorgegeben).

Was aber jetzt nicht durch die Lehre passieren kann (konträr zu einigen gestrigen Meinungen) ist, dass dieses Muster in jeden hinein geprügelt werden kann. So funktioniert es nicht. Der angehende Entwickler (egal ob durch eine Ausbildung, ein Training, FH, Uni, etc.) muss von sich aus die Vorteile aufnehmen und sich selbst dahin bringen, diese laufend einzusetzen. Der Vortragende kann den Grundstock legen. Genauso wie es der Hersteller von Entwicklungswerkzeugen kann. Aber weder der Vortragende, noch der Hersteller können den Entwickler zwingen.

Aus dieser Sichtweise heraus ist es ebenfalls unwesentlich, ob diverse Praktiken vom Vorgesetzten unterstützt werden oder nicht. Wer um Qualität bemüht ist, wird dies umsetzen. So oder so. Wer um Qualität bemüht ist, wird sich fortbilden bzw. nach entsprechenden Möglichkeiten suchen. Wer gezwungen wird, der lehnt sich dagegen auf. Das ist der natürliche Lauf der Dinge.

Fazit: Es braucht Multiplikatoren (Hersteller, Vortragende, aber VOR ALLEM Entwickler), welche die Vorteile aufzeigen, die unterstützend tätig sind, damit möglichst viele auf diesen Zug aufspringen. Aber niemand kann von einem Absolventen erwarten, dass er es genau so macht und dann der Ausbildungsstätte die Schuld zuweisen, es würde nicht gelehrt werden. Daher mache ich den Softwareentwickler (fast) alleine für (fehlende) Qualität verantwortlich. Schließlich heißt es ja auch Clean Code Developer.

2 Kommentare - 6692 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Perfektion als Maßstab?

05.12.08 - Entwicklung, Diskussionen, Software Testing, Projektmgmt., Qualitätsmgmt.
Beitrag von Norbert Eder

Schön langsam wird es schwierig, alle Themen unter einen Hut zu bekommen. Ich versuche daher hiermit auf einige Punkte aus den unterschiedlichen Themenbereichen einzugehen, um hoffentlich alles ein wenig zu kanalisieren.

Alex hat ja bereits meine Aussagen zum Thema Der perfekte Softwareentwickler kommentiert. Nun hat sich auch noch Sven zu Wort gemeldet und das Thema Perfekte Software ins Spiel gebracht. Plausible und legitime Fragestellungen bzw. Aussagen können daraus erlesen werden.

Wenn ich mir darüber nun so meine Gedanken mache, dann stellt sich für mich die Frage, ob Perfektion überhaupt der Maßstab sein kann?

Qualität als Hürde

Software wird bekanntlich von sehr vielen nicht als qualitativ hochwertig angesehen, unabhängig der Bereiche, in denen seit jeher getestet wird, was das Zeug hält. In Business-Anwendungen und im Individual-Bereich zählen oft andere Anforderungen: schnelle Umsetzungszeit, möglichst hohe Funktionsdichte, möglichst hoher Gewinn. Legitime und nachvollziehbare Punkte, die sich offensichtlich mit erhöhtem Zeitaufwand durch Qualitätssicherung, Einführung neuer Methoden und Praktiken oft nicht vereinbaren lassen. Oder doch?

Aus Sicht der Nicht-Entwickler, fallen zum Zeitpunkt der Einführung derartiger Prozesse höhere Aufwände (zeitlich, monitär, etc.) an. Diese wollen oder können nicht getragen werden.

Der springende Punkte daran (und hier können sich weder Kunde, noch der Vorgesetzte, noch die Entwickler ausnehmen) ist, dass jeder seinen Teil dazu beitragen muss. Eine Gruppe alleine kann den großen Umschwung nicht bringen. Prozesse müssen optimiert, Methoden eingesetzt und beides gelebt werden. Nur dann kann es funktionieren.

Im Zuge dessen fällt immer wieder der Return on Investment (ROI). Ich gehe nicht so weit zu sagen, dass ihn niemand erkennt. Vielmehr wird oft nur der vermeintlich steinige Weg gesehen, den es zu gehen gilt. Dass dieser Weg gar nicht so steinig ist und mit kleinen, eingestreuten, Änderungen sehr schnell gegangen werden kann, wird oft nicht korrekt vermittelt (vom Entwickler, von Magazinen, von Online-Artikeln, etc.) oder vom Vorgesetzten dem Kunden gegenüber. Letztlich ist es dem Kunden egal, er will ein funktionierendes Produkt haben. Wie dies erreicht wird, Sache des Herstellers.

(Bewusst aussen vor lasse ich hierbei die Themen wie mit Features etc. umgegangen wird.)

Verantwortung übernehmen

Wohl einer der wichtigsten Punkte: Wer Verantwortung übernimmt, kann Veränderung bringen. Ein qualitätsbewußter Entwickler wird Verantwortung übernehmen, indem er einfach mal eben eine Build-Umgebung einrichtet, oder unabhängig der Unterstützung von oben seine Tests schreibt. Er wird eine geeignete Möglichkeit finden, seine Aufgaben zu analysieren, zu planen, umzusetzen und zu testen. Mit ein wenig Glück kann er diesen Gedanken auf Kollegen und Vorgesetzte transportieren.

Der Vorgesetzte muss Verantwortung üernehmen, indem dieser Entwickler gefördert wird. Natürlich muss nicht nur der qualitative Output passend sein, auch der quantitive. Ganz klar. Er muss einsehen, dass eine qualitative Verbesserung natürlich eine Auswirkung auf den gesamten Output des Unternehmens und somit auch auf das Branding des Unternehmens hat. Der Kunde wird es danken und eventuell weitere Kunden heranschaffen.

Ziel soll es sein, dass sich alle Bereiche (Entwickler, Vorgesetzer, Kunde) gegenseitig unterstützen und sich gegenseitig motivieren sich zu verbessern. Das muss nicht in Einklang mit Verzögerung, weniger Gewinn etc. gehen. Wohl aber geht es in die positive Richtung - mit dieser Einstellung.

Suchen, Sehen, Lernen, Verstehen, Vermitteln

Was Sven festgestellt hat, kann ich nur unterstreichen. Niemand weiß alles. Perfektion kann es also in diesem Sinne nicht geben. Was es aber geben kann und sollte, ist eine permanente Annäherung. Die Entwicklung von Software geht heute kaum schneller voran, als dies vor einigen Jahrzehnten der Fall war. Lediglich die Mittel, Werkzeuge haben sich geändert. Aus einem einfachen Programmierer ist ein Entwickler geworfen. Mit höheren Anforderungen, höhrerer Eigenständigkeit und mehr Verantwortung.

In diesem Zusammenhang fällt mir spontan der Begriff des Paradigmenwechsels ein. Ein Paradigmenwechsel wird notwendig, wenn Anomalien zunehmen und erkannt wird, dass ein anderer Weg doch der bessere wäre. Bis das Spiel wieder von vorne beginnt. In unserer schnelllebigen Branche verändert sich zwar vieles, Paradigmenwechsel halten sich - aus meiner Sicht - jedoch in Grenzen. Es gibt zwar hier Neues, dort Neues, aber wirklich wichtige Praktiken werden nur sehr sehr langsam angenommen.

Woran scheitert das?

Nicht weil wir so schlecht sind, es ist die Fülle an Information, an Werkzeugen, an Methoden. Haben sich darüber früher eine Handvoll Personen Gedanken gemacht, ist in der heutigen Zeit an allen Ecken und Enden ein neuer Aspekt zu lesen. Schwierig, alles unter einen Hut zu bekommen.

Wie war das? Sprich mit fünf Leuten und du erhältst 6 Meinungen. Der einzig wahre Weg ist nicht zu finden. Aber führen nicht alle Wege nach Rom? Die impliziert, das Rom das Ziel aller Ziele wäre. Dies bedeutet, dass auch alle Wege an Ziel führen. Ist das so?

Wie viele (Software)Projekte werden nicht abgeschlossen? Wieviele werden nicht mit vollständiger Funktionalität rechtzeitig ausgeliefert? Die Antwort kann sich jeder selbst geben.

Der Punkt ist, dass eben nicht alle Wege ans Ziel führen. Unterschiedliche Zeiten erfordern unterschiedliche Aktionen.

Gibt es eine Lösung?

Wohl nicht. Man kann wohl niemanden bekehren den richtigen Weg zu gehen, weil es ihn einfach nicht gibt. Aber man kann durchaus einen richtigeren Weg vorschlagen und versuchen zu unterstützen. Eigeninitiative und Verantwortung sind sie Schlagwörter von Wichtigkeit.

Es ist schön perfekt zu sein. Niemand wird jemals perfekt sein. Weder der Mensch, noch seine erschaffenen Produkte. In ist, wer nicht perfekt sein will, sich und seine Umgebung jedoch beständig zu verbessern versucht.

In diesem Sinne:
Keine Perfektion, aber kontinuierliche Verbesserung!

Kommentar hinzufügen | 1 Trackbacks | Permalink | Trackback-URL

Gedanken zum perfekten Softwareentwickler

04.12.08 - Entwicklung, Diskussionen, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder

Nach meiner Antwort zu Peter, hat sich nun auch Alex zu Wort gemeldet. Dem kann ich mich inhaltlich auch voll und ganz anschließen (ein Hoch auf mein Notizbuch).

Was ich jedoch aussagen wollte, war etwas anderes. Wir sprechen hier von Themenbereichen, die für manche täglich Brot sind und worüber oft nicht mehr nachgedacht werden muss. Bei vielen Entwicklern verhält sich das anders.

So erlebe ich fast täglich, das Begriffe wie Test-Driven-Development (TDD) oder Domain-Driven-Design (DDD) nicht allgemein hin bekannt sind. Teilweise noch nicht einmal im Ansatz.

Verweigerung: Nein! Doch!

In der Praxis wird Software oft nicht entsprechend dieser Methoden entwickelt. Dies hat unterschiedlichste Gründe:

Unzureichende Motivation, sich weiter zu bilden
Probleme mit dem Programmier-Werkzeug
Ausrede: Zeitdruck
Verweigerung dem Testing gegenüber
Lieber diskutieren anstatt es zu tun
Faulheit
Nicht wissen, wo beginnen

Diese Liste könnte wohl noch um zahlreiche Punkte verlängert werden.

Es gibt Entwickler, die als Leitkuh fungieren und versuchen, andere mit auf diesen Zug zu bringen. Das ist teilweise nicht so einfach. Wie bewegt man jemanden dazu, sich diesen Methoden anzuschließen, wenn jegliche Motivation, dies zu tun, fehlt?

Vorschriften. Schön und gut. Aber kann ein Softwareentwickler zu Qualität gezwungen werden? Wohl nicht. Daher ist es angesagt, Best Practices aufzuzeigen und der Einfachheit halber den Weg langsam zu beschreiten. Nicht jeder kann und will seinen über Jahre antrainierten Wasserfall-Stil von Heute auf Morgen aufgeben und sich um 180° wenden.

Streben nach Perfektion

Der Entwickler ist faul - wird immer behauptet. Daraus ließe sich ableiten, dass er von Haus aus versucht den idealen Weg zu finden, seine Arbeit zu lösen. Lieber einmal kurz und knackig implementieren, als ständig Fehler beheben zu müssen. Lieber mit Testing arbeiten und sich so absichern. Lieber Tools verwenden, die sich aktuelle Paradigmen zu Nutze machen und die Arbeit erleichtern. Alles logische und nachvollziehbare Punkte. Was aber, wenn die Faulheit in die andere Richtung ausschlägt?

Verbesserungsmöglichkeiten?

Eine fehlende Grund-Motivation kann man keinem Entwickler einpflanzen. Aber dem Gewillten kann man den Weg ebnen. Vielleicht wäre es also ganz gut, sich darüber Gedanken zu machen, wie man denn unbedarfte Software-Entwickler erfolgreich, ohne allzu große Hürden auf diesen Weg bringt. Der von Alex aufgezeigte Weg ist sicherlich einer, den doch einige von uns gegangen sind. Aber ist er nicht zu steinig?

Daher meine abschließende Frage: Gibt es überhaupt einen einfachen Weg, das Verständnis und die Bereitschaft zu agilem Denken zu schaffen, oder kann dieser Weg nur vom Entwickler selbst eingeschlagen werden?

2 Kommentare - 889 mal angesehen | 2 Trackbacks | Permalink | Trackback-URL

Gedanken zum perfekten Software-Design

03.12.08 - Entwicklung, Diskussionen, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder

Peter Bucher hat in seiner Blogpost Es gibt kein perfektes Design, oder doch über die Qualität des Sourcecodes in Projekten geschrieben. Einige der Punkte möchte ich so aber nicht stehen lassen.

Entwickler und Wunschdenken

Im Gegensatz zum zugrunde liegenden Artikel bin ich nicht der Meinung, dass das Wunschdenken bei vielen Entwicklern in Richtung "Perfektes Design" geht. Vielmehr ist es den meisten Entwicklern wichtig, dass die umzusetzenden Punkte in der veranschlagten Zeit umgesetzt werden. Die Qualität wird daher oft außen vor gelassen. Dies resultiert darin, dass sich viele Entwickler kaum Zeit nehmen zu prüfen, wie ein Algorithmus etc. entwickelt werden kann, so dass er performant und zukunftssicher ist.

Das heißt, das Wunschdenken vieler Entwickler geht meist in Richtung "Hoffentlich bin ich bald fertig mit meinem Task". Natürlich gibt es auch Ausnahmen. Keine Frage. Aber sie sind nicht in der Mehrheit.

Debugging-based Development

Ein wichtiger Punkt hierbei ist - und diesen habe ich schon sehr sehr oft erlebt - das Entwickeln per Debugging. Was bedeutet das? Es werden ein paar Codezeilen geschrieben, dann wird gleich der Debugger angeworfen um zu sehen ob es funktioniert. Wenn nicht, dann gibt der Debugger ohnehin Bescheid an welcher Stelle es knackt. Dort wird eine Änderung durchgeführt und der nächste Debug-Durchlauf startet.

Vielmehr sollte sich der Entwickler zuvor Gedanken darüber machen, was denn da wirklich gefordert wird. Daraus ergeben sich Anforderungen an den zu schreibenden Code. Hier ist es oft sinnvoll, sich vielleicht doch ein paar Minuten mit dem MSDN auseinander zu setzen. Eventuell gibt es dann doch einen Hinweis, der mich das Problem wesentlich eleganter lösen lässt. Zusätzlich ist es immer von Vorteil, sich den Ablauf des Problems aufzumalen. Ob dies nun via UML-Tool passiert, per Visio (ja, kann auch UML) oder einfach am Blatt Papier hängt von der Komplexität und der Anzahl der notwendigen Klassen ab. Aber es fängt schon bei Methoden an, die drauflos entwickelt werden.

Das Hauptproblem bei Machen wir einfach mal schnell ist, dass irgendwann der Punkt kommt, der eine Änderung erfordert. Es funktioniert nicht so, wie man sich das gedacht hat. Und hier fängt es an: Der Code wird mit Gewalt so zurechtgerückt, dass er schlussendlich funktioniert. Im Schönwetter-Fall.

Streben nach Perfektion

Der eine hat's, der andere nicht. Es wäre eine Verallgemeinerung zu behaupten, dass jeder Entwickler nach Perfektion strebt. Viele wollen das Produkt fertig stellen, damit Geld herein kommt. Andere reden sich auf den Zeitdruck aus. Andere wollen wieder eine vergoldete Glaskuppel bauen und können ihr Projekt nie abschließen. Es muss also ein Mittelweg gefunden werden. Dieser sollte sowohl in sauberen Code (wie sieht sauberer Code aus?), Einfachheit und Zukunftssicherheit resultieren. Ebenso wenig sollte die Testbarkeit vergessen werden.

Fazit

Es gibt zwar kein perfektes Design, es gibt auch keinen perfekten Sourcecode. Aber jeder Entwickler sollte sich zumindest Mühe geben, Coding-Standards einzuhalten, sich mit seiner Programmiersprache als Werkzeug zu beschäftigen und diese auch entsprechend einzusetzen wissen. Ebenso gehört dazu, auch einmal die eine oder andere Minute mit dem Lesen der Dokumentation zu verbringen und grundsätzlich analytischer an die Problemstellung heran zu gehen.

Sehr gut funktioniert es, sich zuvor zu überlegen, wie denn der neue Code verwendet werden soll. Ein Zeilen wie die neuen Klassen und/oder Methoden verwendet werden sollen und schon erkennt man frühzeitig Probleme und kann diese noch vor dem Start der Implementierung bereinigen. So kleine Dinge können so viel verbessern.

4 Kommentare - 1210 mal angesehen | 1 Trackbacks | Permalink | Trackback-URL

Mit Unit Tests zur einfacheren und intuitiveren Verwendung

15.09.08 - Entwicklung, Diskussionen, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder

Unit Tests sind ein Thema bei dem es Entwickler wie Ärzte halten: Gehe zu vier Ärzten und erhalte fünf Meinungen. Bei Unit Tests läuft es auf dieselbe Art. Also wie jetzt wirklich?

Mit den in Visual Studio integrierten Test-Möglichkeiten sollte man meinen, dass der Entwickler nun wirklich keine Ausrede mehr parat hat, Unit Tests nicht zu schreiben. Weit gefehlt. In vielen Projekten werden derartige Tests noch immer vernachlässigt bzw. im schlimmsten Fall nicht angedacht. Einen der Hintergründe - das Thema Aufwand - hatte ich schon einmal versucht, aus dem Weg zu räumen. Oft erscheinen Tests jedoch auch zu kompliziert, oder es wird diese großartige Unterstützung schlicht einfach nicht bedacht.

Für Unit Tests spricht aber nicht nur, dass damit die Fehlerfreiheit von Teilen der Software verbessert und laufend überprüft werden kann. Der Entwickler kann damit sich selbst, dem Team und neuen, zukünftigen Mitgliedern die Arbeit ebenfalls wesentlich erleichtern. Wie denn das?

Der Eckpfeiler daran ist, sich vor der tatsächlichen Implementierung eines Arbeitspaketes Gedanken zu machen, wie die resultierenden Klassen getestet werden können. Idealerweise werden die Tests vor der Entwicklung dieser Teile geschrieben, muss aber nicht zwingend passieren. Da sich der Entwickler nun im Vorfeld schon Gedanken über die Verwendung macht, wird daran gefeilt, bis eine leichte, intuitive Verwendung möglich ist. Schließlich möchte niemand 10 Zeilen Sourcecode schreiben, nur um eine einfache Berechnung auszuführen. Das Ergebnis ist also ein klares, einfach verständliches Design, welches sowohl die gestellte Aufgabe erfüllt und zudem nach der Implementierung voll funktionsfähig ist. Fehlen Gedanken zur Anwendung, kann letzterer Punkt nicht immer sichergestellt werden. Änderungen am Design sind daher im Nachhinein nötig und führen mitunter sehr schnell zu einer Verwässerung des ursprünglichen Designs.

Der Nachteil daran ist einfach erklärt: Neben der Notwendigkeit, sämtliche Dokumentationen zu ändern (Design Dokument etc.) hat sich durch die spätere Änderung das Design eventuell so stark verändert (meist durch Work-Arounds), dass die Code-Teile nicht mehr intuitiv zu verwenden sind. Team-Kollegen, neue Mitstreiter oder eventuelle Kunden, die programmiertechnisch damit in Berührung kommen, müssen sich lange durch die Dokumentation quälen anstatt durch einen ersten schnellen Tests die Funktionsweise zu verstehen. Eine einfache Sache kann also schnell zu einer Katastrophe ausarten.

Der weitere Ablauf liegt ebenso auf der Hand: Irgendwann wird ein anderer findiger Entwickler diesen Sourcecode zur Überarbeitung markieren. Es entsteht ein Arbeitspaket mit der Prioritätsstufe niedrig - wenn sich einmal Zeit findet. Bis dieser Tag angebrochen ist (in der Regel nie) werden an diesen Stellen vermutlich zahlreiche Funktionserweiterungen implementiert. Ein einfaches Austauschen ist somit auch nicht mehr möglich. Treten zu einem späteren Zeitpunkt gerade hier vermehrt Fehler auf, wird ein alter Spruch missbraucht: Das ist im Laufe der Zeit so gewachsen..

Als Tipp kann ich daher nur jedem Entwickler mitgeben: Bereits im Vorfeld sind Gedanken über die spätere Verwendung von Code-Teilen notwendig. Sinnvoll kann es natürlich sein, nach einem ersten Grob-Design mit einem Testfall zu beginnen. Anhand dessen kann abgeleitet werden, ob die angedachte Verwendungsweise tatsächlich gut ist, oder ob Nacharbeit notwendig ist. Nach zwei bis drei Iterationen über diese Punkte hat sich ein Verständnis für dieses Arbeitspaket entwickelt und auch die Verwendung sollte weitaus klarer und intuitiver sein, als dies vermutlich beim ersten Ansatz der Fall war.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

.NET BlogBook Ausgabe 6

14.04.08 - Entwicklung, Diskussionen, Patterns, Software Testing, Projektmgmt., Qualitätsmgmt., .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, Microsoft Office, SQL Server
Beitrag von Norbert Eder

Ab sofort steht die 6. Ausgabe des .NET BlogBooks zur Verfügung. Insgesamt stehen nun fast 330 Seiten an puren Informationen und Praxiswissen zur Verfügung.

Noch dazu wurden einige Anregungen aufgegriffen. Es gibt ein neues Cover (ein herzliches Dankeschön an 69° media solutions). Ebenfalls wurden unnötige dunkle Stellen entfernt, die beim Ausdrucken maximal Toner verbrauchen, sonst jedoch keinerlei Wirkung erzielen.

Hauptsächlich wurde das BlogBook um Wissen rund um die Windows Presentation Foundation erweitert, aber auch andere Punkte kamen hinzu. Ein Blick lohnt sich allemal.

Weitere Informationen sind auf der Homepage unter http://www.dotnet-blogbook.com zu finden.

Für Anregungen, Wünsche und (konstruktive) Kritik haben wir natürlich weiterhin ein offenes Ohr.

6 Kommentare - 1363 mal angesehen | 1 Trackbacks | Permalink | Trackback-URL

NAnt: Solution aus Visual SourceSafe aktualisieren

27.09.07 - Entwicklung, Software Testing, Qualitätsmgmt., .NET, Allerlei
Beitrag von Norbert Eder

Zu NAnt gibt es ja das Zusatzpaket NAntContrib welches den Task vssget zur Verfügung stellt. Dadurch kann die letzte Version aus dem SourceSafe geladen werden.

Blöderweise funktioniert dies nur bei Visual SourceSafe 6.0d, jedoch nicht mehr mit SourceSafe 2005. Der Grund hierfür liegt darin, dass nicht doe Commandline-Funktionalität verwendet wird, sondern die Visual Studio Integrations-Schnittstelle.

Grundsätzlich wäre das nicht weiter schlimm, würde eine Side-by-Side-Installation der Versionen 6.0d und 2005 möglich sein. Ist es aber nicht. Die zuletzt installierte Version setzt den verwendeten Provider. Ergo auch keine wirkliche Lösung.

Abhilfe schafft hier:

1. NAntContrib selbst anpassen und die notwendigen Änderungen durchführen (denn das Projekt scheint auch nicht mehr wirklich aktiv zu sein)

2. Visual SourceSave 6.0d installieren und nicht 2005 verwenden

3. Einen alternativen Weg finden, beispielsweise diesen Vorgang über einen MSBuild-Task abzubilden, wobei hier dann insgesamt zwei Build-Werkzeuge ins Spiel kommen - auch nicht optimal.

Wird der komplette Prozess auf einem eigenen Server ausgeführt kann dieser ja entsprechend konfiguriert werden. Darin liegt nicht das Problem. Vielmehr ist es nervig, wenn auf der lokalen Maschine Tests durchgeführt werden müssen (Debugging etc.). Klar kann hier eine VM verwendet werden, ist aber vielleicht auch wie mit Bomben auf Tauben schießen.

Hat hier jemand vielleicht einen entsprechenden Tipp parat um NAntContrib auch mit SourceSafe 2005 zum Laufen zu bewegen, speziell den vssget-Task?

Zusätzlich gehe ich einmal davon aus, dass NAntContrib in Verbindung mit dem Team System wohl auch eher ein Problem sein wird.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Kostenlose Code Coverage Tools

27.01.07 - Entwicklung, Diskussionen, Software Testing
Beitrag von Norbert Eder

Was ist Code Coverage?

Die Code Coverage Analyse wird zusammen mit Unit Tests eingesetzt. Durch sie wird überprüft, welcher Anteil des Sourcecodes durch Tests abgedeckt wird. Dadurch kann weiters festgestellt werden, welche Bereiche nicht abgedeckt sind und hat so die Möglichkeit, dafür entsprechende Unit Tests zu bilden. Insgesamt wird durch den Einsatz der Code Coverage Analyse die Qualität der Unit Tests verbessert.

Kostenlose Code Coverage Tools für .NET?

Kommerzielle Produkte zu diesem Thema gibt es einige, jedoch auch kostenlose Tools sind verfügbar.

NCover ist eines dieser kostenlosen Tools und steht aktuell in der Version 1.5.5 beta zur Verfügung, welche jedoch nur mit dem .NET Framework 2.0 zusammenarbeitet und nicht abwärtskompatibel ist. Dazu muss zu einer älteren Version gegriffen werden. Für eine komfortablere Auswertung der Berichte bietet sich der kostenlose NCoverExplorer an.

Eine weitere Variante stellt PartCover dar. PartCover unterscheidet sich in einigen Bereichen von NCover, leistet jedoch auch gute Dienste.

Lohnt sich der Einsatz?

Egal ob nun ein kostenloses Code Coverage Tool oder ein kommerzielles eingesetzt wird, insgesamt wird die Qualität der Unit Tests und somit der gesamten Software erhöht. Daher: Sehr empfehlenswert.

1 Kommentar - 240 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

ReSharper UnitRun: kostenloser Testdriven.NET Gegenspieler

12.12.06 - .NET, Base Framework, Software Testing, Software Testing
Beitrag von Norbert Eder

	Von JetBrains gibt es ein kostenloses Visual Studio Add-In mit dem Unit Tests ausgeführt werden können: ReSharper TestRun [1]. Unterstützt werden folgende Testing-Frameworks: - NUnit - csUnit Ein näherer Blick auf dieses Tool lohnt sich auf jeden Fall. [1] UnitRun Homepage via Thomas.
	2 Kommentare - 1263 mal angesehen \| 0 Trackbacks \| Permalink \| Trackback-URL

Das Übel Software-Testing

20.10.06 - Entwicklung, Software Testing
Beitrag von Norbert Eder

Gestern hatte ich ein längeres Gespräch mit einem befreundeten Entwickler. Basis der Diskussion war das Thema Software-Testing in allen Formen, Varianten und warum die Akzeptanz so gering ausfällt.

Fakt ist (zumindest laut meiner persönlichen Erfahrung), dass nur sehr wenige Firmen Software wirklich testen. Damit meine ich nun weniger, das rein zufällige Finden von offensichtlichen Bugs durch unkontrolliertes - an Zuckungen erinnerndes - Herumklicken auf der GUI, sondern vielmehr der Einsatz von einschlägigen Hilfsmitteln á Unit-Tests und Co.

Wenn ich nun kommuniziere, dass es am zusätzlichen Aufwand liegt, dann wiederhole ich mich, denn dieser dürfte es anscheinend nicht sein. Vielmehr daran, dass viele Entwickler nur dann Spass am Programmieren haben, wenn Neues geschaffen werden kann. Beim Schreiben von Tests muss jedoch bereits entwickeltes geprüft werden (in vielen Fällen), was einer Wiederholung gleich kommt. Um es auf den Punkt zu bringen: es ist einfach fad. Daher wird dieser wichtige Schritt einfach nicht durchgeführt.

Das Resultat? Nun, wer würde sich ein Auto kaufen, welches jedes Mal auf der Autobahn abstirbt, weil der Motor aufgrund der andauernden Belastung überhitzt, also quasi einen Überlauf verursacht. Oder man stelle sich vor, dass das Aufblendlicht nicht funktioniert, weil der Kontakt zur Birne fehlt, was vergleichbar mit einer Null-Reference-Exception wäre. Viele viele Beispiele gäbe es an dieser Stelle. Grundsätzlich möchte jeder ein voll funktionstüchtiges Auto. Genauso verhält es sich mit Software. Wenn andere Branchen so fehlerbestückte Produkte ausliefern würden, wie es Software-Branche tut, könnten wir vermutlich mit keinem Gerät bzw. keinem Produkt tatsächlich etwas anfangen. Das stimmt sehr nachdenklich.

In diesem Sinne wünsche ich einen guten Start ins Wochenende und auf dass es in Zukunft nicht auch notwendig ist, die Software zum Service zu bringen oder gar jährlich ein Pickerl (TÜV) machen zu lassen ...

5 Kommentare - 1118 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Weiter