Produktiv programmieren
Wer seine Brötchen mit Softwareentwicklung verdient, braucht Strategien, um besser, schneller und kostengünstiger zu programmieren. Wir haben mit Jörg Staudemeyer, dem Übersetzer des Buches "Produktiv programmieren" über Strategien und Mechanismen produktiver zu programmieren gesprochen.
Mit der Geschichte vom Untergang der "Vasa" macht Neal Ford deutlich, warum es nicht immer ratsam ist, so viele Features wie möglich in ein Programm einzubauen.
Erfahren Sie, wie Sie
* den Lebenszyklus Ihrer Objekte präzise planen
* sich auf die Implementierung der aktuellen Anforderungen beschränken
* antike Philosophie auf die Software-Entwicklung übertragen
* Autoritäten infrage stellen und nicht blind Standards folgen
* durch Metaprogrammierung schwierige Dinge einfacher und unmögliche Dinge möglich machen
* auf ein einheitliches Abstraktionsniveau innerhalb von Methoden achten
* den richtigen Editor und die besten Hilfsmittel für Ihre Arbeit auswählen
* erst die Tests und dann den zugehörigen Code schreiben.
Ausführliche Informationen zum Buch finden Sie hier.
Das Kapitel 11: Autoritäten infrage stellen können Sie hier als PDF probelesen!
Neal Ford ist als Softwarearchitekt und "Meme Wrangler" bei ThoughtWorks tätig, einer globalen IT-Consulting-Firma mit dem Schwerpunkt auf Softwareentwicklung und -lieferung. Als Autor hat er die Bücher Developing with Delphi: Object-Oriented Techniques (Prentice-Hall), JBuilder 3 Unleashed (Sams) sowie Art of Java Web Development (Manning) verfasst. Er war Herausgeber und Mitwirkender bei den Ausgaben 2006 und 2007 der No Fluff, Just Stuff Anthology (Pragmatic Bookshelf).
Wenn Ihre Neugier bezüglich Neal jetzt noch nicht gestillt ist, können Sie
seine Webseite unter
nealford.com
besuchen. Er freut sich über Feedback
und ist unter nford@thoughtworks.com
zu erreichen.
Gehören Sie auch schon zu den Neal Ford-Fans? Nach dem Lesen dieses Buches bestimmt. Und wenn Sie dann noch sein Blog lesen, dann erst recht. Sie finden es unter: http://memeagora.blogspot.com/
"Mit einfachen Mitteln zu höherer Leistung"
Im Gespräch mit Jörg Staudemeyer, Senior Consultant in einer großen IT-Unternehmensberatung und Autor und Übersetzer mehrerer Bücher für O'Reilly Sie haben das Buch "Produktiv programmieren" von Neal Ford für O'Reilly übersetzt. Was hat Produktivität mit Programmieren zu tun und welchen Einfluss hat es darauf?
Programmieren ist — wenn es nicht als reines Hobby betrieben wird - eine produktive Tätigkeit: es wird etwas produziert, das für jemand anderen von Nutzen ist und wofür dieser Jemand bereit ist, etwas zu bezahlen. Produktivität ist das Verhältnis zwischen dem Resultat der Arbeit und den eingesetzten Mitteln, wobei bei der Software-Entwicklung das entscheidende Mittel die Zeit des Programmierers ist.
Wer es schafft, seine Arbeit in kürzerer Zeit zu erledigen, kann mehr verdienen, früher Feierabend machen, hat weniger Stress — und wird seine Arbeit befriedigender finden. Und dabei will das Buch von Neal Ford helfen.
Im Buch erläutert Neal Ford mehrere Mechanismen, die sich direkt auf die Produktivität eines Programmierers auswirken. Dazu gehört unter anderem "Kanonität". Was versteht man darunter und welche Bedeutung haben diese Mechanismen für die Praxis?
Neal versucht, die verschiedenen Grundmechanismen der Produktivität zu gruppieren, und ist dabei auf die Kategorien "Beschleunigung", "Fokus", "Automatisierung" und "Kanonität" gekommen. Der letzte dieser vier Begriffe ist vielleicht der ungewöhnlichste. Gemeint ist hier letztendlich die Vermeidung der mehrfachen Verwaltung derselben Informationen im Entwicklungsprozess. Das Prinzip, das auch unter dem Kürzel DRY (don't repeat yourself) bekannt ist, wird im Buch anhand verschiedener, teilweise überraschender Beispiele illustriert. Sie zeigen, wie eine geschickte Organisation des Produktionsprozesses Fehler, Verwirrung und Doppelarbeit vermeiden hilft und dadurch die Produktivität erhöht.
Im Buch bekommen Programmierer viele hilfreiche Tipps um ihre Tätigkeit produktiver werden zu lassen. Welche Tipps finden Sie besonders hilfreich und welche haben es in Ihren eigenen Arbeitsalltag geschafft?
Den größten Aha-Effekt hatten für mich die vielen kleinen Ideen zur Befehlszeilenprogrammierung, mit denen man sich das tägliche Leben erleichtern kann. Aber die zahllosen Tipps und Tricks sind — obwohl sie einen auf Ideen bringen — eigentlich nicht die Hauptsache an dem Buch.
Leser sollten sich auf jeden Fall eingehend mit dem zweiten Teil beschäftigen, der unter dem Titel "Praxis" eine tiefere Auseinandersetzung mit verschiedenen Aspekten der Produktivität im Entwickleralltag enthält (wobei es auch hier nicht an nützlichen Ideen mangelt). Dabei scheut sich der Autor nicht, Anregungen bei alten Philosophen einzuholen und zu prüfen, welche Hinweise uns deren Lehrsätze für die Verbesserung unserer Produktionsprozesse geben können.
Ein schönes Beispiel dafür ist "Ockhams Skalpell", demzufolge von mehreren Hypothesen die einfachste im Allgemeinen die wahrscheinlichste ist (und das beispielsweise auch William of Baskerville in Umberto Ecos Der Name der Rose erfolgreich anwendet).
Neal Fords Buch verleitet einfach dazu, Produktivität in der Programmierung neu zu denken, und das hat sicher die nachhaltigste Wirkung.
Wer sollte Ihrer Meinung nach dieses Buch unbedingt lesen? Ist produktives Programmieren für jeden Programmierer wichtig?
Typische Adressaten für das Buch sind sicher Entwickler von Business-Anwendungen, die auf Basis von Java, Ruby oder dem .NET-Framework arbeiten, denn auf deren Arbeitspraxis sind die vielen konkreten Beispiele am ehesten gemünzt.
Gerade im zweiten Teil findet man viele Überlegungen, die für fast jeden Entwickler nützlich sein könnten. Besonders ans Herz legen würde ich das Buch aber auch technischen Projekt- und Teamleitern, die häufig einen großen Teil des Drucks in zeit- und ressourcenkritischen Entwicklungsprozessen abbekommen und in diesem Buch wertvolle Anregungen erhalten, wie sie ihre Mitarbeiter mit einfachen Mitteln zu höherer Leistung und besseren Lösungen (oder auch weniger Überstunden) verhelfen können.
Die Fragen stellte Nathalie Pelz.Auszug aus dem Buch Produktiv programmieren von Neal Ford:
DER UNTERGANG DER VASA
Im Jahr 1625 gab König Gustav II Adolf von Schweden das stolzeste Kriegsschiff in Auftrag, das die Welt jemals gesehen hatte. Er heuerte den besten Schiffbauer an, ließ extra einen Wald mit den mächtigsten Eichen hochziehen und begann mit der Arbeit an der »Vasa«. Immer wieder stellte der König neue Anforderungen auf, die das Schiff noch großartigermachen sollten, über und über prunkvoll dekoriert. Irgendwann entschied er, dass das Schiff – anders als jedes bisher auf der Welt gebaute Schiff – mit zwei Kanonendecks bestückt sein sollte, auf dass es das stärkste Kriegsschiff auf den Weltmeeren werde. Und wegen eines gerade aufbrechenden diplomatischen Konflikts brauchte er es so schnell wie möglich. Natürlich hatte der Schiffbauer beim Entwurf des Schiffs nur ein Kanonendeck vorgesehen, aber da der König es so wollte, bekam er auch sein zweites Kanonendeck.
Da es schnell gehen musste, hatte man keine Zeit für üblichen »Lurch-Tests«, bei denen eine Gruppe von Matrosen von einer Seite des Schiffs zur anderen läuft, um sicherzugehen, dass das Schiff nicht zu stark ins Schaukeln gerät (mit anderen Worten: dass es nicht zu kopflastig ist).
Auf ihrer Jungfernfahrt sank die Vasa binnen weniger Stunden. Dadurch, dass dem Schiff all die »Features« hinzugefügt worden waren, hatte es seine Seetüchtigkeit verloren. Bis in das frühe 20. Jahrhundert lag die Vasa auf dem Grund der Nordsee, dann wurde das gut erhaltene Schiff gehoben und in ein Museum gebracht.
Und hier kommt die interessante Frage: Wer war schuld daran, dass die Vasa sank? Der König, weil er ständig neue Features verlangt hatte? Oder die Schiffbauer, die das Gewünschte bauten, ohne ihre Bedenken laut genug zu äußern? Sehen Sie sich in dem Projekt um, an dem Sie gerade arbeiten: Sind Sie vielleicht gerade wieder dabei, eine Vasa zu bauen?
