Produktiv programmieren - Startseite...Einen SQL-Splitter mit Ruby bauen 84 Warum Automatisierung wichtig ist 86 Rasieren Sie keine Grunzochsen 89 Zusammenfassung 90 5 KANONITÄT 91

Neal FordDeutsche Übersetzung von Jörg Staudemeyer

Produktiv programmieren

00___ProductiveProgrammer.book Seite II Donnerstag, 27. November 2008 11:51 11

Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo

Produktiv programmieren

Neal FordDeutsche Übersetzung von

Jörg Staudemeyer

00___ProductiveProgrammer.book Seite III Donnerstag, 27. November 2008 11:51 11

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen.Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Der Verlag richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Kommentare und Fragen können Sie gerne an uns richten:O’Reilly VerlagBalthasarstr. 8150670 KölnTel.: 0221/9731600Fax: 0221/9731608E-Mail: [email protected]

Copyright der deutschen Ausgabe:© 2009 by O’Reilly Verlag GmbH & Co. KG1. Auflage 2009

Die Originalausgabe erschien 2008 unter dem Titel The Productive Programmer bei O’Reilly Media, Inc.

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Übersetzung und deutsche Bearbeitung: Jörg Staudemeyer, BerlinLektorat: Alexandra Follenius, KölnKorrektorat: Sybille Feldmann, DüsseldorfSatz: III-satz, Husby, www.drei-satz.deUmschlaggestaltung: Mark Paglietti, Sebastopol & Michael Oreal, KölnProduktion: Andrea Miß, KölnBelichtung, Druck und buchbinderische Verarbeitung: Druckerei Kösel, Krugzell; www.koeselbuch.de

ISBN 978-3-89721-886-4

Dieses Buch ist auf 100% chlorfrei gebleichtem Papier gedruckt.

00___ProductiveProgrammer.book Seite IV Donnerstag, 27. November 2008 11:51 11

I N H A L T S V E R Z E I C H N I S V

I N H A L T S V E R Z E I C H N I S C H A P T E R 0

ZUM GELEIT IX

VORWORT XI

1 EINFÜHRUNG 1

Warum ein Buch über Produktivität? 2

Worum es in diesem Buch geht 4

Und wie geht es weiter? 7

Teil 1 MECHANISMEN 9

2 BESCHLEUNIGUNG 11

Launcher 12

Beschleuniger 24

Makros 44

Zusammenfassung 47

3 FOKUS 49

Ablenkungen beseitigen 50

Suche übertrumpft Navigation 53

Dinge suchen, die schwer zu finden sind 56

Verwenden Sie Rooted Views 59

Verwenden Sie dauerhafte Attribute 61

Verwenden Sie projektbezogene Verknüpfungen 62

Multiplizieren Sie Ihre Monitore 63

Teilen Sie Ihren Arbeitsbereich virtuell auf 63

Zusammenfassung 66

4 AUTOMATISIERUNG 67

Erfinden Sie das Rad nicht neu 69

Speichern Sie Dinge lokal 70

Automatisieren Sie die Interaktion mit Websites 71

Interagieren Sie mit RSS-Feeds 72

Mit Ant nicht nur Build-Prozesse steuern 73

00___ProductiveProgrammer.book Seite V Donnerstag, 27. November 2008 11:51 11

VI I N H A L T S V E R Z E I C H N I S

Rake für allgemeine Aufgaben verwenden 75

Mit Selenium Webseiten auslesen 77

Mit Bash Exceptions zählen 79

Ersetze BAT durch PowerShell 80

Mit Mac OS X Automator alte Downloads löschen 81

Die Subversion-Befehlszeile zähmen 83

Einen SQL-Splitter mit Ruby bauen 84

Warum Automatisierung wichtig ist 86

Rasieren Sie keine Grunzochsen 89

Zusammenfassung 90

5 KANONITÄT 91

DRY in der Versionskontrolle 93

Verwenden Sie einen kanonischen Build-Server 95

Indirektion 97

Nutzen Sie die Virtualisierung 106

DRY und der Impedance-Mismatch 107

DRY in der Dokumentation 116

Zusammenfassung 124

Teil 2 PRAXIS 125

6 TESTGETRIEBENES DESIGN 127

Tests entstehen lassen 129

Testabdeckung 137

7 STATISCHE ANALYSE 141

Bytecode-Analyse 142

Quellcode-Analyse 145

Metriken generieren mit Panopticode 147

Analyse dynamischer Sprachen 150

8 GUTE MITBÜRGER 153

Die Kapselung durchbrechen 154

Konstruktoren 156

Statische Methoden 156

Kriminelles Verhalten 162

9 YAGNI 165

00___ProductiveProgrammer.book Seite VI Donnerstag, 27. November 2008 11:51 11

I N H A L T S V E R Z E I C H N I S VII

10 ALTE PHILOSOPHEN 173

Aristoteles’ essenzielle und akzidenzielle Eigenschaften 174

Ockhams Skalpell 176

Das Gesetz der Demeter 181

Softwareüberlieferungen 182

11 AUTORITÄTEN INFRAGE STELLEN 185

Böse Affen 186

Fluent-Interfaces 188

Antiobjekte 190

12 META-PROGRAMMIERUNG 193

Java und Reflection 194

Java mit Groovy testen 196

Fluent-Interfaces schreiben 198

Wohin führt uns Meta-Programmierung? 200

13 COMPOSED-METHOD UND SLAP 201

Composed-Method im Einsatz 202

SLAP 208

14 POLYGLOTTES PROGRAMMIEREN 215

Wie sind wir hierher gekommen? Und was heißt »hier«? 216

Wo gehen wir hin? Und wie kommen wir dort hin? 220

Olas Pyramide 226

15 PERFEKTE WERKZEUGE 229

Das Streben nach dem perfekten Editor 230

Die Kandidaten 234

Das richtige Werkzeug für meinen Job 236

Die falschen Werkzeuge vermeiden 244

16 SCHLUSSFOLGERUNG: DAS GESPRÄCH FORTFÜHREN 249

ANHANG: BAUSTEINE 253

INDEX 263

00___ProductiveProgrammer.book Seite VII Donnerstag, 27. November 2008 11:51 11

00___ProductiveProgrammer.book Seite VIII Donnerstag, 27. November 2008 11:51 11

IX

Zum Geleit

Die individuelle Produktivität von Programmierern variiert in unserer Branche

erheblich. Was die meisten von uns eine Woche lang beschäftigt, schaffen man-

che an einem Tag. Warum das so ist? Auf diese Frage gibt es eine kurze Antwort,

die davon handelt, wie gut man die verfügbaren Werkzeuge beherrscht. In der

langen Antwort geht es aber darum, inwieweit man sich der durch die Werkzeuge

gebotenen Möglichkeiten bewusst ist und wie man den zu ihrer Nutzung erforder-

lichen Denkprozess beherrscht. Die Wahrheit liegt irgendwo dazwischen; sie hat

mit Methodik und Philosophie zu tun, und genau damit beschäftigt sich Neal in

diesem Buch.

Die Idee zu diesem Buch wurde im Herbst 2005 auf einer gemeinsamen Rückfahrt

zum Flughafen geboren. Neal fragte mich: »Glaubst du, dass die Welt noch ein

weiteres Buch über reguläre Ausdrücke braucht?« Im Anschluss daran kamen wir

auf verschiedene Themen zu sprechen, zu denen wir uns Bücher gewünscht hät-

ten. Dabei musste ich an einen Moment in meiner beruflichen Entwicklung den-

ken, von dem in glaube, dass ich dort den Sprung von einem leidlich guten zu

einem sehr produktiven Programmierer getan hatte, und wie es dazu kam. Ich

sagte: »Ich weiß zwar nicht, wie der Titel des Buchs lauten sollte, aber sein Unter-

titel müsste in etwa ›Die Befehlszeile als integrierte Entwicklungsumgebung‹ lau-

ten.« Damals schrieb ich meine erhöhte Produktivität noch allein der Beschleuni-

gung zu, die ich durch die Verwendung der bash-Shell erfahren hatte. Es war aber

mehr als dies: Das Entscheidende war meine wachsende Vertrautheit mit diesem

Werkzeug, die dadurch entstand, dass ich nicht mehr mit ihm kämpfen musste,

00___ProductiveProgrammer.book Seite IX Donnerstag, 27. November 2008 11:51 11

X Z U M G E L E I T

um irgendetwas zu erreichen, sondern es einfach benutzen konnte. Wir verbrach-

ten einige Zeit damit, über diese Art der Hyperproduktivität, und wie man sie ver-

mitteln könnte, zu diskutieren. Es dauerte noch einige Jahre, unzählige Gesprä-

che und eine Reihe von Vorträgen, aber nun hat Neal das maßgebliche Werk zu

diesem Thema geschrieben.

Larry Wall benennt in seinem Buch Programmieren mit Perl (O’Reilly Verlag) die

drei Tugenden der Programmierer: Faulheit, Ungeduld und Hybris. Faulheit, weil

Sie Anstrengungen aufbieten, um die Menge der insgesamt erforderlichen Arbeit

zu vermindern. Ungeduld, weil es Sie ärgert, wenn Sie Ihre Zeit mit Dingen

verschwenden, die der Computer schneller erledigen könnte. Und Hybris, weil

übermäßiger Stolz Sie dazu bringt, Programme zu schreiben, über die niemand

etwas Negatives sagen kann. Keines der drei Worte kommt in diesem Buch vor

(das habe ich mit grep überprüft), aber wenn Sie weiterlesen, werden Sie diese

Einstellung in vielfachen Variationen und in erweiterter Form wiederfinden.

Es gibt eine paar Bücher, die großen Einfluss auf meine berufliche Entwicklung

hatten. Sie veränderten die Art und Weise, wie ich die Welt betrachte. Ich

wünschte, ich hätte dieses Buch schon vor zehn Jahren in Händen gehabt, und

ich bin sicher, dass es einen tief greifenden Einfluss auf jene ausüben wird, die es

jetzt lesen.

David Bock Principal Consultant

CodeSherpas

00___ProductiveProgrammer.book Seite X Donnerstag, 27. November 2008 11:51 11

Chapter

Vorwort

00___ProductiveProgrammer.book Seite XI Donnerstag, 27. November 2008 11:51 11

XII V O R W O R T

Vor einigen Jahren führte ich Schulungskurse für erfahrene Entwickler durch, die

neue Technologien (wie etwa Java) lernen sollten. Dabei fiel mir immer wieder auf,

wie unterschiedlich die Produktivität der Kursteilnehmer war: Manche arbeiteten

tatsächlich um Größenordnungen effektiver als andere. Dabei meine ich nicht die

Werkzeuge, die sie verwendeten, sondern ihren generellen Umgang mit dem

Computer. Einigen Kollegen gegenüber pflegte ich den Witz zu machen, dass

manche meiner Kursteilnehmer den Computer nicht zum Laufen, sondern zum

Kriechen brächten. Als Folge eines logischen Schlusses fing ich schließlich an, meine

eigene Produktivität infrage zu stellen: Hole ich denn selbst den größtmöglichen

Nutzen aus meinem Computer, lass ich ihn wirklich laufen oder nur kriechen?

Einige vorgespulte Jahre später geriet ich mit David Bock in ein Gespräch zu genau

demselben Thema. Viele unserer jüngeren Mitarbeiter benutzten niemals Befehls-

zeilenwerkzeuge und verstanden gar nicht, dass diese eine viel höhere Produkti-

vität bieten können als die heutigen elaborierten IDEs. Wie David in seinem Geleit-

wort zu diesem Buch berichtet, unterhielten wir uns darüber und entschlossen uns

schließlich, ein Buch darüber zu schreiben, wie man mithilfe der Befehlszeile zu

höherer Effektivität kommen kann. Wie setzten uns mit einem Verlag in Verbin-

dung und begannen damit, alle möglichen Befehlszeilenraffinessen zu sammeln,

deren wir bei Freunden und Mitarbeitern habhaft werden konnten.

Dann passierten mehrere Dinge. David eröffnete seine eigene Consulting-Firma,

und er bekam mit seiner Frau die ersten Kinder – Drillinge! Klar, dass David nun

mehr um die Ohren hatte, als er schaffen konnte. Gleichzeitig kam ich zu dem

Schluss, dass ein Buch, in dem es ausschließlich um Befehlszeilentricks geht,

vermutlich das langweiligste Buch aller Zeiten sein würde. Zu dieser Zeit arbeitete

ich an einem Projekt in Bangalore, und Mujir, mein Partner beim Pair-Program-

ming, sprach über Codemuster und wie man sie erkennen kann. Dies traf mich wie

eine Ladung Ziegelsteine. Was ich in all den bis dahin gesammelten Rezepten

gesehen hatte, waren Muster. Anstelle einer massiven Sammlung von Befehlszei-

lentricks sollte es lieber darum gehen, wie man die Dinge identifiziert, die Entwickler

produktiver machen. Und das ist es, was Sie jetzt in den Händen halten.

Für wen dieses Buch geschrieben istDies ist kein Buch für Endanwender, die ihren Computer effektiver benutzen

wollen. Es ist ein Buch über die Produktivität von Programmierern, und das

bedeutet, dass ich eine Menge von Annahmen über die Leserschaft treffen darf.

Entwickler sind ultimative Power-User, also muss ich mich nicht lange mit

00___ProductiveProgrammer.book Seite XII Donnerstag, 27. November 2008 11:51 11

V O R W O R T XIII

elementaren Dingen aufhalten. Ein technikbegeisterter Benutzer kann sicher

einiges lernen (insbesondere in Teil 1), aber die Hauptzielgruppe sind und bleiben

Programmierer.

Es gibt in diesem Buch keine spezielle Reihenfolge, Sie können also nach Belieben

darin herumblättern oder es auch von vorne bis hinten durchlesen. Die einzigen

Verbindungen zwischen den Themen erscheinen in etwas unerwarteter Weise,

daher könnte es möglicherweise vorteilhaft sein, sie der Reihe nach zu lesen;

dieser Vorteil ist aber nicht so groß, als dass man sagen könnte, dies sei die einzig

sinnvolle Art und Weise, das Buch zu lesen.

In diesem Buch verwendete KonventionenDieses Buch verwendet die folgenden typografischen Konventionen:

Kursivschrift

Bezeichnet neue Ausdrücke, URLs, E-Mail-Adressen, Dateinamen und

Dateierweiterungen.

Nichtproportionalschrift

Wird für Programm-Listings verwendet sowie innerhalb von Absätzen für

Programmelemente wie Variablen- und Funktionsnamen, Datenbanken,

Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter.

Nichtproportionalschrift fett

Zeigt Befehle oder anderen Text, der vom Benutzer wörtlich einzugeben

ist.

Nichtproportionalschrift kursiv

Kennzeichnet Text, der durch Werte zu ersetzen ist, die vom Benutzer

vorzugeben oder durch den Kontext bestimmt sind.

Verwendung von CodebeispielenDieses Buch soll Ihnen bei Ihrer Arbeit helfen. Generell können Sie den im Buch

abgedruckten Programmcode in Ihren Programmen und und Dokumentationen

verwenden. Es ist nicht notwendig, sich mit uns wegen einer Erlaubnis in Verbin-

dung zu setzen, sofern Sie nicht erhebliche Teile des Codes reproduzieren. Wenn

Sie beispielsweise ein Programm schreiben, in das Sie einzelne Codepassagen aus

diesem Buch übernehmen, benötigen Sie dazu keine besondere Erlaubnis. Für

den Vertrieb einer CD-ROM mit Beispielen aus O’Reilly-Büchern ist hingegen

00___ProductiveProgrammer.book Seite XIII Donnerstag, 27. November 2008 11:51 11

XIV V O R W O R T

eine Erlaubnis erforderlich. Das Beantworten einer Frage mithilfe eines Zitats aus

diesem Buch oder durch Anführen von Beispielcode ist ohne Erlaubnis möglich.

Die Übernahme von Beispielcode in erheblichem Umfang aus diesem Buch in die

Dokumentation Ihres Produkts setzt jedoch eine Erlaubnis voraus.

Wir begrüßen die Kennzeichnung von Zitaten, machen sie aber nicht zur Bedin-

gung. Eine korrekte Zitatkennzeichnung enthält Titel, Autor, Verlag und ISBN.

Beispiel: »Produktiv programmieren von Neal Ford. Copyright 2009 O’Reilly Verlag,

ISBN 978-3-89721-886-4.«

Wenn Sie den Eindruck haben, dass Sie Codebeispiele in größerem Umfang

verwenden als angemessen oder durch die obige Erlaubnis abgedeckt, kontak-

tieren Sie uns bitte unter [email protected].

DanksagungenDies ist wohl der einzige Teil dieses Buchs, den auch die Nicht-Techies unter

meinen Freunden lesen werden, daher muss ich mir hier besonders viel Mühe

geben. Mein gesamtes lebenserhaltendes Umfeld hat mich bei dem langen und

zähen Prozess des Buchschreibens unterstützt. Als Erstes ist da meine Familie,

insbesondere meine Eltern Hazel und Geary, aber auch meine gesamte erwei-

terte Familie, darunter meine Stiefeltern Sherrie und Lloyd. Die Redner und

Zuhörer bei den unter No Fluff, Just Stuff firmierenden Symposien und auch

deren Organisator Jay Zimmerman haben mir über viele Monate hinweg

geholfen, das ganze Material zu prüfen. Insbesondere die Redner auf diesen

Veranstaltungen haben dafür gesorgt, dass sich die geradezu absurde Anzahl

meiner Reisen gelohnt hat. Besonderer Dank geht an meine Kollegen bei

ThoughtWorks, einer Gruppe von Menschen, mit denen zu arbeiten ich als

außerordentliches Privileg empfinde. Niemals zuvor habe ich eine Firma erlebt,

die sich derart dem Revolutionieren der Softwareproduktion verschrieben hat

und in der so hochgradig intelligente, leidenschaftliche und selbstlose Menschen

tätig sind. Zumindest ein Teil dessen muss ich dem außergewöhnlichen Gründer

von ThoughtWorks, Roy Singham, zuschreiben, für den ich wohl ein wenig

Bewunderung empfinde. Dank an alle meine Nachbarn, von denen ich weiß,

dass sie an dem ganzen Technik-Kram nicht besonders interessiert sind, insbe-

sondere Kitty Lee, Diane und Jamie Coll, Betty Smith sowie alle anderen

jetzigen und früheren Nachbarn vom Executive Park (und, ja, das schließt auch

dich ein, Margie). Besonderen Dank auch an meine Freunde, die sich nun über

den Erdball verteilt haben: Masoud Kamali, Frank Stepan, Sebastian Meyen

00___ProductiveProgrammer.book Seite XIV Donnerstag, 27. November 2008 11:51 11

V O R W O R T XV

und die ganze S&S-Crew. Und natürlich diejenigen, die ich überhaupt nur in

anderen Ländern treffe, wie Michael Li und, obwohl sie nur fünf Meilen

entfernt von mir wohnen, Terry Dietzler und seine Frau Stacy, deren Pläne viel

zu selten mit meinen in Einklang zu bringen sind. Dank (obwohl sie dies nicht

lesen können) an Isabella, Winston und Parker, die weniger an Technologie,

aber umso mehr an Zuwendung interessiert sind (zu ihren Bedingungen natür-

lich). Ein Dankeschön an meinen Freund Chuck, der es mit seinen zunehmend

seltenen Besuchen immer noch schafft, meinen Tag zu erleuchten. Und, das

Wichtigste zum Schluss, meine wunderbare Frau Candy. Alle meine Freunde

unter den Rednern behaupten, dass sie eine Heilige ist, indem sie mir erlaubt,

mich in der Welt herumzutreiben, über Software zu sprechen und Software zu

schreiben. Großzügig gönnt sie mir meine allumfassende Tätigkeit, denn sie

weiß, wie wichtig mir diese ist, wenn auch nicht so sehr wie meine Frau selbst.

Sie wartet geduldig, bis ich in den Ruhestand gehe oder von all dem ermüde

und dann meine ganze Zeit mit ihr verbringen kann.

00___ProductiveProgrammer.book Seite XV Donnerstag, 27. November 2008 11:51 11

00___ProductiveProgrammer.book Seite XVI Donnerstag, 27. November 2008 11:51 11

Kapitel 1

K A P I T E L E I N S

Einführung

00___ProductiveProgrammer.book Seite 1 Donnerstag, 27. November 2008 11:51 11

2 K A P I T E L E I N S

P R O D U K T I V I T Ä T I S T D A S V E R H Ä L T N I S Z W I S C H E N E I N E R M E N G E N Ü T Z -L I C H E R A R B E I T und der dafür benötigten Zeit. Wenn jemand produktiver ist,

verrichtet er mehr effektive Arbeit in einem gegebenen Zeitintervall als jemand,

der weniger produktiv ist. Dieses Buch handelt ausschließlich davon, wie man bei

den verschiedenen zum Entwickeln von Software erforderlichen Tätigkeiten

produktiver werden kann. Es ist nicht auf eine Sprache oder ein Betriebssystem

beschränkt: Die präsentierten Tipps betreffen diverse unterschiedliche Sprachen

und drei verbreitete Betriebssysteme, nämlich Windows (in verschiedenen

Versionen), Mac OS X und *-nix (sowohl Unix als auch Linux).

In diesem Buch geht es um die individuelle Produktivität von Programmierern,

nicht um die Produktivität von Gruppen. Daher spreche ich hier auch nicht über

Methodik (höchstens einmal hier und dort, aber stets nur am Rande). Außerdem

gehe ich nicht auf Produktivitätssteigerungen ein, die das ganze Team betreffen.

Ich sehe meine Mission darin, einzelnen Programmierern Werkzeuge und Philo-

sophien an die Hand zu geben, mit denen sie mehr nützliche Arbeit pro Zeitein-

heit schaffen können.

Warum ein Buch über Produktivität?Ich arbeite für ThoughtWorks, eine international tätige Consulting-Firma mit

etwa 1.000 Beschäftigten in sechs Ländern. Da wir (insbesondere in den USA)

reisende Berater sind, handelt es sich um eine im demografischen Sinn sehr

junge Firma. Auf einem unserer Firmenausflüge (bei dem Getränke serviert

wurden) kam ich einmal zufällig mit einer Journalistin der Zeitschrift People ins

Gespräch. Sie fragte mich, wie alt ich sei, und ich sagte es ihr. Darauf bedachte

sie mich mit einem spontanen Kompliment (?): »Wow, Sie sind alt genug, diese

Firma um einiges an Vielfalt zu bereichern.« Dies löste in mir einige Gedanken

aus. Ich entwickle schon seit vielen Jahren Software (erkennbar an nostalgi-

schen Äußerungen wie: »Zu meinen Zeiten gab es noch dampfbetriebene

Computer ...«). In dieser ganzen Zeit habe ich ein interessantes Phänomen

beobachet: Die Effizienz der Entwickler nimmt nicht zu, sondern sie nimmt ab.

In jenen uralten Zeiten (im Computerzeitalter heißt dies: vor einigen Jahr-

zehnten) war es schwieriger, einen Computer zu betreiben, als das Ding zu

programmieren. Man musste ein wirklich cleverer Entwickler sein, um das Biest

dazu zu bekommen, etwas Nützliches zu tun. Diese Feuerprobe formte Really

Smart Guys, die alle möglichen effektiven Wege entwickelten, um mit den stör-

rischen Computern ihrer Zeit umzugehen.


E I N F Ü H R U N G 3

Dank harter Programmiererarbeit wurden die Computer allmählich leichter

benutzbar. Innovationen sollten die Anwender dazu bringen, sich nicht mehr so

viel zu beklagen. Die Really Smart Guys gratulierten sich selbst (wie es alle

Programmierer tun, wenn sie einen Benutzer zum Schweigen bringen). Dann

geschah aber etwas Merkwürdiges: Eine ganze Generation von Entwicklern

entstand, die jene raffinierten Tricks und abwegige Intelligenz nicht mehr benö-

tigten, um die Computer dazu zu bringen, das zu tun, was sie sollten. Genau wie

die Endanwender begannen auch sie, sich der viel höheren Benutzbarkeit der

Rechner zu erfreuen. Dagegen kann man eigentlich nichts sagen, denn Produk-

tivität ist schließlich eine gute Sache, oder?

Es kommt darauf an. Was für Benutzer produktiv ist (nette grafische Benutzer-

oberflächen, Mäuse, Pull-down-Menüs usw.), kann für jemanden, der die

größte Performance aus seinem Rechner herausholen möchte, ein Hindernis

sein. »Leicht zu benutzen« und »effizient« sind nur selten in Einklang zu

bringen. Entwickler, die mit grafischen Benutzeroberflächen groß geworden

sind (okay, ich sag es ganz offen: Windows), kennen viele der coolen, effzienten

Kniffe der Gilde der Really Smart Guys von gestern nicht mehr. Entwickler von

heute lassen ihre Computer nicht laufen, sondern kriechen. Und daran würde

ich gern etwas ändern.

Adressvervollständigung im Browser

Hier ist ein einfaches Beispiel: Wie viele Webseiten besuchen Sie am Tag? Die

meisten ihrer Adressen beginnen mit »www.« und enden mit ».com«. Alle mo-

dernen Browser besitzen eine kaum bekannte Abkürzung namens Adressvervoll-

ständigung. Mithilfe einer Tastenkombination können Sie automatisch »www.«

am Anfang und ».com« am Ende des in die Adressleiste des Browsers geschriebe-

nen Texts anfügen. Die verschiedenen Browser verwenden dazu jeweils eine

leicht veränderte Syntax. Beachten Sie aber, dass dies etwas anderes ist als das

automatische Hinzufügen des Präfixes und des Suffixes durch den Browser, das

ebenfalls durch alle modernen Browser unterstützt wird. Der Unterschied besteht

in der Effizienz. Um Präfix und Suffix automatisch hinzuzufügen, geht der

Browser hinaus ins Netzwerk und sucht nach einer Website mit dem »nackten«

Namen. Erst wenn er keine solche findet, versucht er es mit dem Präfix und dem

Suffix, was jeweils eine weitere Reise in das Netzwerk erfordert. Mit einer schnel-

len Internetanbindung werden Sie die Verzögerung nicht einmal bemerken, aber

alle diese falschen Zugriffe verlangsamen das ganze Internet!



Internet Explorer

Der Internet Explorer (IE) macht es sehr einfach, Adressen einzugeben die ein

standardmäßiges Präfix und Suffix haben. Verwenden Sie die Tastenkombination

Strg-Enter, um »www.« vorne und ».com« hinten an die Adresse anzufügen.

Firefox

Dasselbe Tastaturkürzel wie beim Internet Explorer funktioniert auch in der

Windows-Version des Firefox. Auf dem Macintosh tut Apfel-Enter das Gleiche.

Firefox hat aber noch mehr zu bieten: Auf allen unterstützten Plattformen hängt

Shift-Enter ein ».net« und Strg-Shift-Enter (bzw. Apfel-Shift-Enter) ein ».org«

ans Ende.

Firefox kennt noch weitere Tastaturkürzel, die niemand zu benutzen scheint.

Beispielsweise können Sie, um direkt zu einem Tab (bzw. zu einer Registerkarte)

zu gehen, unter Windows die Tastenkombination Strg-<Tab-Nummer> und unter

OS X die Kombination Apfel-<Tab-Nummer> benutzen.

Na gut, diese Abkürzung ist nur dürftige acht Tastenanschläge pro Webseite wert.

Aber denken Sie an die Anzahl der Webseiten, die Sie jeden Tag besuchen, und

wie sich diese acht Zeichen pro Seite aufaddieren. Dies ist ein Beispiel für das

Prinzip der Beschleunigung, das wir in Kapitel 2 definieren.

Die Ersparnis von acht Tastaturanschlägen ist es aber nicht, worauf es bei diesem

Beispiel wirklich ankommt. Ich habe eine informelle Umfrage bei allen mir

bekannten Programmierern durchgeführt und dabei festgestellt, dass weniger als

20 Prozent von ihnen diese Abkürzung kannten. Alle Befragten sind Hardcore-

Computerexperten, und trotzdem nutzen sie nicht einmal die einfachsten

Produktivitätsverbesserungen. Meine Mission sehe ich darin, diesen Zustand zu

verbessern.

Worum es in diesem Buch gehtProduktiv programmieren besteht aus zwei Teilen. Der erste behandelt die Mecha-

nismen der Produktivität sowie die Benutzung der Werkzeuge, mit deren Hilfe Sie

produktiver werden können, wenn Sie sich durch die verschiedenen physischen

Aktivitäten der Softwareentwicklung arbeiten. Der zweite Teil behandelt die

Praxis der Produktivität: wie Sie Ihr Wissen und das Wissen anderer nutzen

können, um schneller und besser Software zu entwickeln. In beiden Teilen wird



Ihnen nicht alles neu sein, aber Sie werden auch auf Dinge stoßen, an die Sie

noch nie zuvor gedacht haben.

Teil I: Mechanismen (Die Prinzipien der Produktivität)

Sie können dieses Buch als eine Art Kochbuch für Befehlszeilen- und sonstige

Produktivitätsrezepte ansehen und durchaus Nutzen daraus ziehen. Aber erst

wenn Sie verstehen, warum etwas Ihre Produktivität erhöht, werden Sie dies

überall in Ihrer Umgebung wiederfinden. Indem Sie Muster finden, um etwas zu

beschreiben, erzeugen Sie eine Nomenklatur: Dadurch, dass Sie einer Sache einen

Namen geben, können Sie es leichter wiedererkennen, wenn Sie es an anderer

Stelle sehen. Eines der Ziele dieses Buchs besteht darin, eine Reihe von Produkti-

vitätsprinzipien zu definieren, die Ihnen helfen, eigene Produktivitätstechniken

zu definieren. Wie alle Muster können Sie auch diese leichter identifizieren, wenn

sie benannt sind. Das Wissen darum, wie etwas Ihre Arbeit beschleunigt, ermög-

licht Ihnen eher, andere Dinge zu identifizieren, die Ihnen beim schnelleren Erle-

digen Ihrer Aufgaben helfen können.

Dies ist kein Buch über die effiziente Benutzung von Computern (wenngleich

dies ein Nebeneffekt ist). Es hat die Produktivität von Programmierern im Blick.

Aus diesem Grund gehe ich auf vieles nicht ein, was für gelegentliche Nutzer oder

sogar Power-User offensichtlich ist (obwohl der obige Abschnitt »Adressvervoll-

ständigung im Browser« gerade einen solchen offensichtlichen Tipp beschreibt).

Wir Programmierer stellen eine einzigartige Teilmenge von Computeranwendern

dar. Besser als jeder andere sollten wir in der Lage sein, Computer effektiv für

unsere Zwecke zurechtzubiegen, denn wir wissen am besten, wie sie wirklich

funktionieren. Hauptsächlich geht es in diesem Buch darum, was Sie mit dem und

an dem Computer machen können, um sich die Arbeit leichter, schneller und effi-

zienter zu machen. Aber ich gehe auch auf einige tiefer hängende Früchte ein, die

Sie produktiver machen können.

Teil 1 deckt alle Produktivitätstipps ab, die ich erfinden, ernten, meinen Freunden

aus den Rippen schneiden oder in der Literatur finden konnte. Ursprünglich

wollte ich daraus das bedeutendste Produktivitätskochbuch der Welt machen. Ich

weiß nicht, ob mir dies gelungen ist, aber in jedem Fall finden Sie hier eine eini-

germaßen eindrucksvolle Sammlung an Rezepten.

Als ich begann, all diese Produktivitätstipps zu sammeln, fiel mir auf, dass dabei

Muster entstehen. Beim Inspizieren all der Techniken begann ich, Kategorien für

die Produktivität von Programmierern zu formulieren. Irgendwann nannte ich sie



dann die Prinzipien der Produktivität von Programmierern. Offen gestanden, konnte

ich mir keinen pompöseren Namen vorstellen. Diese Prinzipien sind Beschleuni-

gung, Fokus, Automatisierung und Kanonität. Sie beschreiben die Methoden, mit

deren Hilfe Programmierer produktiver werden können.

Kapitel 2, Beschleunigung, beschreibt die Erhöhung der Produktivität, die dadurch

entsteht, dass man etwas schneller macht. Offensichtlich ist eine Person, die eine

bestimmte Aufgabe schneller erledigt, bezüglich dieser Aufgabe produktiver als

ein anderer, der bei derselben Sache langsamer vorankommt. Schöne Beispiele

für das Beschleunigungs- oder Akzelerationsprinzip sind die zahlreichen Tastatur-

kürzel, die überall im Buch vorkommen. Beschleunigung umfasst Dinge wie das

Starten von Anwendungen, die Arbeit mit der Zwischenablage sowie das Suchen

und Navigieren.

Kapitel 3, Fokus, zeigt, wie man durch Einbeziehung von Werkzeugen und Umge-

bungsfaktoren den Zustand der Superproduktivität erreicht. Es behandelt Mög-

lichkeiten, das (physische und virtuelle) Durcheinander in Ihrer Umgebung zu

reduzieren, effizienter zu suchen und Ablenkungen zur vermeiden.

Wenn Ihnen der Computer mehr von Ihrer Arbeit abnimmt, macht Sie dies offen-

sichtlich produktiver. In Kapitel 4, Automatisierung, erfahren Sie, wie Sie Ihren

Computer dazu bringen können, mehr für Sie zu tun. Viele Ihrer alltäglichen

Aufgaben können (und sollten) automatisiert werden. Dieses Kapitel enthält

Beispiele und Strategien, wie Sie Ihrem Computer zu mehr Arbeit verhelfen

können.

Kanonität ist eigentlich nur ein vornehmeres Wort für das DRY-Prinzip (Don’t

Repeat Yourself – Wiederhole dich nicht selbst), das in dem Buch Der Pragmatische

Programmierer (Hanser) von Andy Hunt und Dave Thomas definiert worden ist.

Das DRY-Prinzip rät Programmierern, Stellen mit duplizierten Informationen zu

finden und diese jeweils durch eine einheitliche Quelle zu ersetzen. In Der Prag-

matische Programmierer ist dieses Prinzip sehr eloquent beschrieben, und in

Kapitel 5, Kanonität, zeige ich konkrete Beispiele für seine Anwendung.

Teil II: Praxis (Philosophie)

In meinen reiferen Jahren als Entwickler war ich überwiegend im Beratungsge-

schäft tätig. Berater sind Entwicklern gegenüber im Vorteil, die Jahr um Jahr an

derselben Codebase arbeiten. Wir haben eine Menge verschiedener Projekte und

diverse unterschiedliche Ansätze kennengelernt. Natürlich sehen wir auch un-



seren Anteil an den Katastrophen (nur selten werden Berater gerufen, um ge-

sunde Projekte »in Ordnung zu bringen«). Wir hatten die Möglichkeit, ein breites

Spektrum an Softwareentwicklung zu sehen: durch die Unterstützung beim

Aufbau neuer Anwendungen, bei der Beratung in der Mitte und bei den Ret-

tungsversuchen, nachdem etwas arg schiefgelaufen ist. Mit der Zeit kann jeder

aufmerksame Mensch ein Gefühl dafür bekommen, was funktioniert und was

nicht.

Teil 2 ist das Destillat aus von mir beobachteten Dingen, die Programmierer

entweder produktiver machen oder sie von ihrer Produktivität ablenken. Diese

habe ich in mehr oder weniger zufälliger Reihenfolge gebündelt (wobei Sie mögli-

cherweise überrascht sein werden, wie oft die gleichen Ideen in unterschiedlicher

Gestalt erscheinen). Es soll kein umfassendes Kompendium aller Tricks zur

Produktivitätssteigerung von Programmierern sein, sondern eine Sammlung aus

meinen Beobachtungen, die nur eine kleine Teilmenge aller Möglichkeiten

umfasst.

Und wie geht es weiter?Beide Teile dieses Buchs sind unabhängig voneinander; Sie können sie also in

beliebiger Reihenfolge lesen. Allerdings ist Teil 2 ein wenig mehr im erzählenden

Stil geschrieben, und gelegentlich können unerwartete Verbindungen auftau-

chen. Aber auch hier ist der größte Teil des Stoffs nicht sequenziell angeordnet:

Lesen Sie ihn in der Reihenfolge, die Ihnen beliebt.

Ein Warnhinweis. Falls Sie sich in der elementaren Welt der Befehlszeilen (Pipes,

Umleitungen usw.) nicht ganz zu Hause fühlen, sollten Sie dem Anhang einen

kurzen Besuch abstatten. Er zeigt, wie man sich eine Umgebung aufsetzen kann,

die für den Gebrauch vieler der in Teil 1 behandelten Tricks und Techniken

geeignet ist. Ich verspreche Ihnen, es tut kaum weh.



This is the Title of the Book, eMatter EditionCopyright © 2008 O’Reilly & Associates, Inc. All rights reserved.

T E I L 1

I. MECHANISMEN

Teil 1, Mechanismen, handelt (Sie ahnen es) von den Mechanismen der Produkti-

vität. Viele dieser Werkzeuge sind nicht unbedingt Entwicklungstools, sondern

eher Hilfsmittel, die jedem anspruchsvollen Power-User von Nutzen sein können.

Natürlich sollten Entwickler die ultimativen Power-User sein, die aus praktisch

allen in diesem Buch aufgeführten Werkzeugkategorien den größten Vorteil

ziehen können.



Kapitel 2

K A P I T E L Z W E I

Beschleunigung


12 K A P I T E L Z W E I

D I E A R B E I T A M C O M P U T E R E R F O R D E R T E I N G E W I S S E S M A ß A N R I T U A L E N

und Zeremonien. Sie müssen ihn hochfahren, wissen, wie Sie Anwendungen

starten, und Sie müssen das Interaktionsmodell verstanden haben, das bei jeder

Anwendung anders sein kann. Je weniger Sie mit dem Computer interagieren

müssen, desto schneller kommen Sie vorwärts. Mit anderen Worten: Das Elimi-

nieren von Zeremonien gibt Ihnen mehr Zeit, um sich auf das Wesentliche zu

konzentrieren. Die Zeit, die Sie mit dem Durchwühlen umfangreicher hierarchi-

scher Dateisysteme verbringen, um irgendetwas zu finden, könnten Sie für mehr

Produktivität nutzen. Computer sind Werkzeuge, und je mehr Zeit Sie damit

verbringen, ein Werkzeug zu pflegen und zu versorgen, desto weniger Arbeit

können Sie mit ihm erledigen. Es gibt ein wunderbares Zitat des Science-Fiction-

Autor Douglas Adams: »We are stuck with technology when what we really want

is just stuff that works.«1

M E R K E Konzentriere dich auf das Wesentliche und nicht auf die Zeremonien.

In diesem Kapitel geht es darum, wie wir die Interaktion mit dem Computer

beschleunigen können, indem wir Anwendungen rascher starten, Dateien

schneller finden und weniger die Maus benutzen.

LauncherWerfen Sie einmal einen Blick auf die Liste der Anwendungen auf Ihrem

Computer. Wenn Sie Windows verwenden, klicken Sie dazu auf Start und wählen

Programme aus. Wie viele Spalten erscheinen? Zwei? Drei? Vier!? Nachdem die

Festplatten größer und die mit dem Computer zu erledigenden Aufgaben (und

mit ihnen die benötigten Werkzeuge) komplexer geworden sind, ist die Anzahl

der von uns benutzten Anwendungen explodiert. Nachdem 100-GByte-Fest-

platten selbstverständlich geworden sind, können wir natürlich viel Kram in

unsere Systeme packen. Aber die Menge fordert ihren Preis.

M E R K E Der Nutzen einer Liste von Anwendungen ist umgekehrt proportional zu

ihrer Länge.

1 Sinngemäß: »Wir wollten nur, dass die Dinge funktionieren, und nun haben wir die ganze Technologie am Hals.«, The Salmon of Doubt, 2002, deutsch Lachs im Zweifel, 2003.


B E S C H L E U N I G U N G 13

Je mehr die Liste anwächst, desto weniger nützlich wird sie. Bei drei Spalten

unter Windows oder einem OS X-Dock, das die Elemente auf mikroskopische

Größe komprimiert, wird es immer schwerer, das Gesuchte zu finden. Dies trifft

Entwickler besonders hart, denn wir haben eine Vielzahl von Gelegenheitsanwen-

dungen: Spezialwerkzeuge, die wir vielleicht nur einmal im Monat starten, aber

auf die wir dringend angewiesen sind, wenn dieser Tag kommt.

Launcher

Launcher sind Anwendungen, mit deren Hilfe Sie Anwendungen starten (oder

Dokumente öffnen) können, indem Sie die ersten Buchstaben ihres Namens

eingeben. Meistens ist dies die effektivste Möglichkeit zum Starten einer Anwen-

dung.

M E R K E Ein Augenschmaus sieht gut aus, ist aber nicht nahrhaft.

Wenn Sie den Namen der Sache kennen, hinter der Sie her sind (oder den Namen

der Anwendung), könnten Sie dem Computer doch einfach mitteilen, was Sie

wollen, anstatt in einer umfangreichen Liste zu kramen oder in einem Meer von

Icons danach zu suchen. Launcher bahnen Ihnen einen Weg durch den Augen-

schmaus und führen Sie schnell und präzise zu der Sache, die Sie benötigen.

Zu allen gängigen Betriebssystemen gibt es quelloffene oder kostenlos erhältliche

Launcher, bei denen Sie nur den Namen (oder einen Teil des Namens) der

Anwendung einzugeben brauchen, die Sie starten wollen. Einige von ihnen, die

einen Versuch wert sind, nennen sich Launchy,2 Colibri3 und Enso4. Launchy

und Colibri sind Open Source-Programme und daher kostenlos; bei beiden

können Sie ein kleines Fenster öffnen und damit beginnen, den Namen einer

Anwendung einzugeben, wodurch sich eine Liste möglicher Kandidaten öffnet.

Launchy ist derzeit der populärste der Open Source-Launcher. Colibri versucht,

ein Mac OS X-Hilfsprogramm namens Quicksilver zu imitieren (auf das wir weiter

unten im Abschnitt »Mac OS X« näher eingehen).

Enso ist ein Launcher, der über einige interessante zusätzliche Features verfügt. Er

ist ebenfalls kostenlos (aber nicht Open Source) und stammt von der Firma

2 Download unter http://www.launchy.net.

3 Download unter http://colibri.leetspeak.org.

4 Download unter http://www.humanized.com.


Documents

Produktiv programmieren - Startseite...Einen SQL-Splitter mit Ruby bauen 84 Warum Automatisierung wichtig ist 86 Rasieren Sie keine Grunzochsen 89 Zusammenfassung 90 5 KANONITÄT 91