Buch-Rezension zu „Produktiv programmieren“

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

SVN: Commits auf Tags?

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.