Archiv

Archive for September 2009

Code formatieren in Eclipse und Visual Studio

27. September 2009 Kommentare aus

Beim editieren von Source Code kommt die Formatierung schnell durcheinander. Man hat natürlich die Möglichkeit die von Hand wieder herzustellen. Allerdings ist das mühsam und man verschiebt es auf später. Nach weiteren Änderungen und noch mehr Vorsätzen für später hat man dann etwas, was man erst recht nicht mehr anpassen will.

Dies alles kann man sich ersparen, wenn man die in der IDE eingebauten Funktionen nutzt.

 
Eclipse
In Eclipse kann man den Code mit [Ctrl]-[Shift]-[F] sauber formatieren oder mit [Ctrl]-[I] nur die Einrückung korrigieren. Als Grundlage für die Formatierung dient die in den Einstellungen gewählte Formatierungsvorlage. IBM hat dazu eine ausführliche Erklärung.

 
Visual Studio
In Visual Studio gibt es eine vergleichbare Funktion. Mit [Ctrl]-[K] [Ctrl]-[D] wird der Code neu formatiert. Die Formatierung kann auch hier eingestellt werden. Auf MSDN gibt es dazu einen passenden Abschnitt.

 
Eine kleine Funktion die einem viel Ärger ersparen kann. Wenn man die Einstellungen verändert, sollte man diese Exportieren und ebenfalls in die Versionsverwaltung aufnehmen. Bei der Arbeit im Team sollte man nur an einem Ort die Einstellungen verändern. Ansonsten läuft das sehr schnell auseinander. Und wenn nur einer die Änderungen für alle macht spart man erst noch Zeit.

Einige Gedanken zu Performance Tests

21. September 2009 Kommentare aus

Performance ist an sich ja immer ein Thema. Speziell vor einem Release gewinnt dies aber immer an Wichtigkeit. Und wenn man dann etwas messen soll, misst man häufig Mist. Wieso? Man misst entweder nicht das Richtige, man nutz falsche Werkzeuge oder geht von falschen Annahmen aus.

Für mich sind diese Punkte bei der Performance-Messung wichtig:

  • mehrmals Messen
  • Masseinheit muss zur Messung passen
  • Reproduzierbar sein
  • Ausreisser erkennen und entfernen
  • Bezug zur Realität und zum Einsatzgebiet haben
  • Kritisch das Ergebnis betrachten

 
Eine Messung ist keine Messung“ wurde uns an der Berufsschule beigebracht. Das war zwar nicht im Zusammenhang mit Performance, doch stimmt es auch in dem Bereich. Performance-Vergleiche auf der Basis einer einzigen Messung sind Riskant, wenn nicht sogar Gefährlich. Je nach dem was sonst auf dem System läuft ist die Messung komplett falsch. Eine Prüfung durch den Virenschutz zur falschen Zeit und man kann die Messung vergessen.
Mehrmals Messen und das Herausfiltern der Ausreisser kann vor solchen Verfälschungen schützen.
Aber Achtung: Nur weil es einen Wert gibt der massiv ausserhalb der anderen Werte liegt, kann man den nicht einfach entfernen. Kommt der Ausreisser in regelmässigen Abständen vor, muss man abklären was die Ursache ist. Läuft alle 10 Minuten ein Batchjob und alle 10 Minuten gibt es einen Ausreisser, dann ist ein Zusammenhang sehr wahrscheinlich.

Die Masseinheit muss zur Messung passen. Minuten als Einheit für Vorgänge die in Millisekunden ablaufen sind nutzlos. Aber auch das Messen von Sekunden für Tests die mehrere Stunden dauern ist meistens übertrieben. Ist es wirklich Relevant wenn ich auf 5 Stunden 30 Sekunden schneller und beim nächsten Test 10 Minuten langsamer bin? Wohl eher nicht.

Die Messung muss reproduzierbar sein. Wenn man die Messung wiederholt sollte man mindestens etwas Vergleichbares messen. Wenn eine Liste nicht mit exakt den gleichen Daten gefüllt werden kann, so muss mindestens die gleiche Anzahl an Einträgen der gleichen Objekte enthalten sein. Sonst ist man beim Vergleich von Äpfeln mit Birnen.

Will man aus seinen Messungen am Ende eine Aussage treffen können, muss der Test einen Bezug zur Realität haben. Das System für den Test muss vergleichbar mit der Produktion sein. Ein Test auf Windows für einen produktiven Einsatz auf Linux ist da wenig Aussagekräftig.

Nachdem man mehrmals auf vergleichbaren Systemen getestet hat, kann man immer noch daneben liegen. Wenn man das Falsche testet, nützt einem der ganze Aufwand nichts. Daher unbedingt überprüfen, ob das was man Testet auch wirklich das erwartete macht.

Zu guter Letzt sollte das Ergebnis immer kritisch betrachtet werden. Kann eine Abweichung bei 2 Funktionen wirklich so gross sein? Kann diese kleine Änderung wirklich so viel Einfluss auf die Geschwindigkeit haben? Hat man Zweifel sollte man lieber nochmals alles kontrollieren und seine Tests überprüfen lassen, bevor man seine Entscheidung trifft.

Soweit meine Meinung. Was ist für euch wichtig? Worauf legt ihr besonders wert? Freue mich auf euren Input.

Schlagworte:

Buch-Rezension zu “Test Driven”

15. September 2009 3 Kommentare

Test Driven

Test Driven


“Test Driven – Practical TDD and Acceptance TDD for Java Developers” von Lasse Koskela ist Ende 2007 bei Manning erschienen. Bei Test Driven geht es um die testgetriebene Software-Entwicklung in Java.

 
Teil 1: Grundlagen von TDD
Im ersten Kapitel werden die Ideen hinter Test Driven Development (TDD) vorgestellt und erklärt, wieso man als Entwickler davon profitiert. Der Initialaufwand für TDD ist höher als bei der Entwicklung ohne Tests. Doch soll der Code irgendwann in Produktion, muss dieser getestet werden. Und wenn man Tests eh braucht, kann man die auch zu einer Zeit schreiben, von der man selber noch etwas davon hat.
Koskela zeigt dabei auch die Wichtigkeit von Refactoring auf. Ohne Tests wird darauf zu oft verzichtet. Der Code läuft, wieso durch eine Änderung neue Probleme riskieren? Hat man die TDD Tests, passen diese auf das beibehalten der Funktionalität auf. Und Refactoring ist bei TDD zentral: Hält man sich an die Vorschläge im Buch und versucht immer die einfachste Lösung zum bestehen der Tests zu schreiben, hat man meistens eine fragwürdige Qualität. Erst das Refactoring macht aus dem funktionierenden auch guten Code – dies gilt auch für die Tests. Kapitel 3 widmet sich daher vollständig dem Refactoring.

Die konkrete Umsetzung von TDD wird in den restlichen Kapiteln des 1. Teils mit der Entwicklung einer Template Engine vorgestellt.

 
Teil 2: TDD für spezifische Technologien
Im zweiten Teil geht es um die Anwendung von TDD bei spezifischen Technologien. Dies reicht von Webkomponenten über Datenzugriff bis zu Swing. Ansätze zum Testen von Multi-Thread Programmen und Zeitfunktionen werden ebenfalls anschaulich erklärt. Eine kurze Vorstellung der dafür benutzten Technologien (wie JSP, JDBC, Hibernate, DbUnit, usw.) sowie deren Verwendung zum Testen runden diesen Teil ab.

 
Teil 3: Acceptance TDD
Im letzten Teil werden die Akzeptanz-Tests behandelt. Es wird mit einer Erklärung der Grundbegriffe und Möglichkeiten fürs Vorgehen begonnen und geht dann zur Umsetzung mittels Fit. Der Kunde kann mit der Hilfe von Fit seine Anwendungsfälle in Tabellenform erfassen. Diese dienen dann als Input für Tests und ermöglichen so die Verifizierung der Funktionalität. Damit dies funktioniert muss der Entwickler die Verbindung zwischen Fit und den Unit-Tests erstellen.

 
Fazit:
Test Driven erklärt auf verständliche Art was die testgetriebene Entwicklung ausmacht und wieso man diese anwenden soll. Kapitel 1 und 3 behandeln Grundlagen die auch ausserhalb von Java gelten.
Ich finde das Buch ist sehr gut geschrieben und ich konnte beim lesen nicht genug bekommen. Der dritte Teil kommt nicht ganz an die 2 ersten Teile heran. Da wäre mehr zur Verknüpfung von Fit um den Tests sowie Beispiele mit anderen Frameworks hilfreich gewesen. Dennoch kann ich das Buch ohne Einschränkung weiterempfehlen.

Zum Buch
Test Driven – Practical TDD and Acceptance TDD for Java Developers von Lasse Koskela, 2007 Manning, ISBN 978-1-932394-85-6, 544 Seiten

Schlagworte: , ,

Leichter debuggen mit DebuggerDisplay

10. September 2009 Kommentare aus

Der Debugger von VisualStudio zeigt einem einen Tooltip an, sobald man mit der Maus über eine Variable oder eine Klasse fährt. Je nach dem ist dieser Text mehr oder weniger hilfreich. Man hat zwar immer die Möglichkeit, die einzelnen Felder und verschachtelten Werte durchzuklicken, bis man die gewünschten Werte angezeigt bekommt. Je grösser die Klasse und je mehr Felder diese beinhaltet, desto unübersichtlicher und mühsamer wird es.

Als kleines Beispiel dient mir eine Klasse Person. Dieses repräsentiert einen Menschen und der Vor- und Nachname sind die Informationen, über die ich das Objekt zuordnen kann. Beim debuggen wäre es für mich hilfreich, genau diese Informationen im Tooltip angezeigt zu bekommen (und eine Id, sollten mehrere Personen den gleichen Namen haben). Eine ganz einfache Personenklasse kann so aussehen:

using System;

namespace DebuggerInfo
{
    class PersonBasic
    {
        public String FirstName { get; set; }
        public String LastName { get; set; }
        public int Id { get; set; }

        public PersonBasic(String firstName, String lastName, int id)
        {
            FirstName = firstName;
            LastName = lastName;
            Id = id;
        }
    }
}

Als Tooltip wird nur der Namespace und Klassenname gezeigt:

Tooltip mit Klassennamen

Wie kann ich nun eine bessere Beschreibung bekommen?

 
Option 1: ToString() überschreiben

Die einfachste Möglichkeit um die gewünschte Anzeige zu erhalten ist das überschreiben der ToString-Methode. Dazu genügt dieses kleine zusätzliche Stück Code:

public override string ToString()
{
    return String.Format("{0} {1} {2}", FirstName, LastName, Id);
}

Der Debugger nutzt nun die ToString-Methode und liefert mir eine hilfreiche Anzeige zurück:
Tooltip mit ToString

 
Option 2: Attribut DebuggerDisplay

Ist die ToString-Methode schon überschrieben und liefert nicht die gewünschten Informationen, kann mit dem Attribut DebuggerDisplay auf Ebene der Klasse die Anzeige im Debugger geändert werden. Dies befindet sich im Namespace System.Diagnostics. Der dazugehörende Code sieht so aus:

namespace DebuggerInfo
{
    [DebuggerDisplay("Person: {LastName} {FirstName}")]
    class PersonDebug
    {
        // Klassendefinition
    }
}

Im Debugger gibt es das gewünschte Ergebnis:

Tooltip mit DebuggDisplay

 

Fazit:
DebuggerDisplay kann einem helfen, gewünschte Informationen nur für den Debugger aufzubereiten. Eine sinnvolle ToString-Methode sollte aber zu erst erstellt werden.

Schlagworte: , ,

Buch-Rezension zu “Produktiv programmieren”

6. September 2009 Kommentare aus

Produktiv programmieren

Produktiv programmieren

„Produktivität ist das Verhältnis zwischen einer Menge nützlicher Arbeit und der dafür benötigten Zeit.“

Mit dieser Definition beginnt Neal Ford sein Buch „Produktiver programmieren“. Er beobachtete wie die Produktivität der Programmierer über die Jahre abgenommen hat. Dies obwohl immer mehr Werkzeuge gerade diese steigern sollte. Als erstes Beispiel dient die Adressvervollständigung des Browsers. Jeder nutzt Webbrowser, doch wie viele verwenden die Vervollständigung?

Viele Kleinigkeiten die einem das Leben erleichtern würden werden nicht genutzt. Hier setzt Ford an und will zeigen, wie man bei der täglichen Arbeit produktiver werden kann. Das Buch besteht aus den zwei Teilen Mechanismen (Die Prinzipien der Produktivität) und Praxis (Philosophie).

Die Mechanismen beinhalten Beschleuniger (Launcher, Makros), die Fokussierung, Automatisierung und das Verhindern von Wiederholungen (DRY).
Der Teil Philosophie reicht von Testgetriebenem Design (TDD), über statische Codeanalyse, Kapselung, YAGNI (You ain’t gonna need it) bis hin zu Meta-Programmierung.

Die Beispiele sind dabei nicht auf ein spezielles Programm oder Betriebssystem limitiert. Ob für Linux, Mac oder Windows, Eclipse oder Visual Studio – für alles gibt es entsprechende Tipps.

Die grosse Anzahl an Themen bei nur 270 Seiten bedeutet leider, dass vieles nur kurz angeschnitten werden kann. Fords Buch liefert eine gute Übersicht und ermöglicht einem die Themen in einem Kontext zu sehen. Wozu testgetriebenes Design dient, wieso DRY wichtig ist und wohin das nicht beachten von YAGNI führt wird verständlich aufgezeigt. Die Tipps zur Produktivitätssteigerung ermutigen einem bei seiner täglichen Arbeit nach Optimierungen zu suchen.

Wer eine detaillierte Einführung in eines der behandelten Themen will, wird mit diesem Buch nicht zufrieden sein. Wer allerdings ein Übersicht und Tipps zur Produktivitätssteigerung sucht, für den kann ich dieses Buch empfehlen.

Zum Buch
Produktiv programmieren von Neil Ford – Deutsche Übersetzung von Jörg Staudenmeyer, O’Reilly 2008, ISBN 978-3-89721-886-4, 270 Seiten

Schlagworte:

SVN: Commits auf Tags?

2. September 2009 1 Kommentar

Letzte Woche kam eine interessante Frage auf: welche Version bekommt man in SVN, wenn man auf ein Tag wechselt, auf dies jemand einen Commit ausführte? Ist es die Version bei der man den Tag erstellte oder die letzte Änderung darin?

Bekommt man in der Situation Revision 2 oder 3?

Bekommt man in der Situation Revision 2 oder 3?

Ein wenig über die Begriffe
SVN ist ein Tool zur Versionierung von Dateien (Sourcecode, Texte, Bilder, usw.).
Mit Hilfe von Tags können in SVN spezifische Versionsstände mit einem eindeutigen Namen markiert werden. Als Beispiel kann die Übergabe der Entwicklung an die Tester mit “v1.0.2_to_test” markiert werden. Dieser Name ist einfacher zu merken als die Revisionsnummer 13478.
Ein Branch ist ein Entwicklungszweig. Dieser läuft getrennt vom Trunk, der Hauptentwicklung. Branches kann man zur Versionswartung nutzen. Hat man seine Version 1 veröffentlicht und findet während der Arbeit an Version 2 einen Bug in v1, kann man den Branch nutzen um auf der Code-Basis von v1 den Fehler zu beheben. Dazu wechselt man vom Trunk in den Branch, macht seine Änderung und committed diese in den Branch. Wikipedia hat dazu noch mehr.

Zurück zur Frage
Was passiert nun, wenn man auf den Tag wechselt und dort eine Änderung committed? Man also ein Tag als Branch benutzt?

Intern macht SVN selber keinen Unterschied zwischen einem Tag und einem Branch. Je nach SVN-Client bekommt man aber vor dem commit eine Warnung:

TortoiseSVN warnt vor commit auf ein Tag

TortoiseSVN warnt vor commit auf ein Tag

Hat man dann aber erst einmal den commit ausgeführt, gibt es keinen Unterschied mehr zwischen Tag und Branch. Diese liegen dann – je nach gewählter Struktur – nur in unterschiedlichen Verzeichnissen.

Ein Update auf den Tag bringt einem somit die letzte Version von diesem „Branch“. Wenn man sich also den Aufwand macht und getrennte Verzeichnisse für Tags und Branches nutzt, sollte man dann auch entsprechend damit arbeiten: Also keine commits auf einen Tag.

Schlagworte:
Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 296 Followern an