Letzte Änderung am 17. November 2021 by Christoph Jüngling
Weil heute ja Karneval ist, mal zu was ganz anderem. Und natürlich zünftig um 11:11 h, hoffentlich geht die Server-Uhr richtig :-)
Nachdem ich so viel über Quellcodeverwaltung geschrieben habe, wird es euch sicher wundern, wenn ich nun Gegenargumente anführe. Ich tue das nicht, um euch vom Gegenteil dessen, was ich bisher gepredigt habe, zu überzeugen, sondern um aufzuzeigen, dass diese Gegenargumente eigentlich nichts mit Quellcodeverwaltung zu tun haben, sondern meines Erachtens eher der menschlichen Natur entspringen.
In diesem Artikel
Vergangenheit
Um es ganz klar zu sagen: Ich verwende SCC (Source Code Control, das englische Wort dafür) nun schon seit so vielen Jahren, dass ich mich kaum noch daran erinnern kann, wann es eigentlich begonnen hat. Ich weiß nur, dass es zunächst Visual Source Safe war, dann Subversion, dann Mercurial und nun Git.
Mein Versuch mit CVS ganz zu Beginn scheiterte glorreich, weil ich absolut nicht verstanden habe, wozu das eigentlich da ist, was da in den zahlreichen Texten so wortreich erklärt wurde. Denn es wurde nur erklärt, wie man das macht, aber nicht wozu. Das kann durchaus ein Grund sein, weshalb auch heute noch einige Kollegen der Ansicht sind, Verzeichnisse mit Versionsnummern würden vollkommen ausreichen. Damals habe ich das auch so gemacht (und fand es toll und übersichtlich). Heute bin ich froh, dass ich “dran geblieben” bin. Ich möchte ohne ein SCC kein Projekt mehr durchführen. Oder noch deutlicher: Ich werde ohne ein SCC kein Projekt mehr durchführen! Dank verteilter Systeme wie Hg und Git würde das sogar dann funktionieren, wenn ein Kunde sich nicht zu einer Installation auf einem Server durchringen kann. Aber eigentlich gehört ein SCC inzwischen zum Standard-Arbeitsmittel einer Softwareentwicklers.
Gründe
Keine Ahnung
Wie gesagt, ein Grund mag sein, dass derjenige nicht verstanden hat, wozu das gut ist. Da kann man verstehen, dass er nicht die Zeit erübrigen will, sich mit scheinbar unsinnigem zu beschäftigen. Könnte man es ihm erklären, würde die Sache vielleicht schon anders aussehen. Es wäre auf jeden Fall einen Versuch wert.
Der Zeitfaktor
Auch das Argument “das kostet zu viel Zeit” habe ich oft gehört. Ich persönlich sehe das nicht so. Mal nebenher einen Commit zu machen ist nun wirklich kaum aufwändig, ob nun mit der Konsole oder einer schönen GUI (siehe Screenshots).
Nachdem ich mir irgendwann angewöhnt hatte, dies immer dann zu tun, wenn ich glaubte, mit einem kleinen Teilbereich fertig zu sein, geht es eigentlich recht flott. Hinzu kommen wenigstens noch drei Vorteile:
- Ich dokumentiere den Fortschritt meiner Arbeit.
- Ich teile meine Arbeit in kleine, überschaubare Schritte auf.
- Ich plane meine Arbeit manchmal sogar bereits in kleinen Schritten, um mir die nachfolgenden Commits zu erleichtern.
Spätestens dann, wenn ich mal einen Fehler in meinem Programm suchen muss, kommt noch ein weiterer Vorteil hinzu: Die kleinschrittigen Commits sind extrem übersichtlich. Wenn ich zum Beispiel mittels Bisect, hier für Mercurial demonstriert, einen Commit identifiziert habe, der einen Fehler eingeführt hat, fällt es mir durch die geringe Größe des Commits oft sehr leicht, ihn auszumerzen.
Verrückt, nun habe ich doch wieder die Vorteile erwähnt :-)
Angst
Darüber haben zwar meine Kollegen bislang nur selten mit mir gesprochen, aber das Thema kam schon gelegentlich mal vor: Jemand hatte Angst davor, dass die Kollegen oder der Chef damit viel leichter herausfinden könnten, wer den Bug verursacht hat. Das ist natürlich technisch nicht nur möglich, sondern sogar gewünscht. Schließlich haben zumindest SVN, Hg und Git eine Funktion namens “blame”, der interessanterweise bei SVN das funktionsgleiche “praise” gegenüber steht. Diese gibt an, wer für welche Änderung in einer Datei verantwortlich war. Ich bin jedoch sicher, dass der Hintergrund dafür in erster Linie die Information ist. Wenn ein Entwickler von einem Fehler, den er gemacht hat, erfährt, kann er daraus lernen und ihn hoffentlich in Zukunft vermeiden.
Fazit
Wie schon anfänglich angedeutet, glaube ich, dass die Abneigungen gegen Quellcodeverwaltung primär menschlich sind, sei es nun die fehlende Kenntnis, der empfundene große Zeitbedarf (wahrscheinlich nur eine Variante der fehlenden Kenntnis) oder die Angst, einen Fehler eingestehen zu müssen.
Ich kann nur jedem Einzelnen raten, sich insbesondere von der Angst freizumachen, falls sie der Grund sein sollte. Ich habe in inzwischen bald 3 Jahrzehnten Berufstätigkeit fast nie Diskussionen über Schuld führen müssen. Fehler in Software akzeptiert fast jeder Kunde, solange sie eine Ausnahme bleiben und nicht zur Regel werden. Ich habe sogar den Eindruck gewonnen, dass freimütig zugegebene Fehler problemlos akzeptiert werden. Versucht man jedoch, den Fehler kleinzureden, kommt das deutlich schlechter an.
Würde es heute dennoch zu solchen Schuldzuweisungen kommen, würde ich diese eher mit massiven Fehlern im Führungsstil erklären, als selbst ein schlechtes Gewissen zu empfinden. Denn wir sind alle Menschen, und wer noch nie einen Fehler gemacht hat, der werfe den ersten Stein!
Und die fehlenden Kenntnisse? Na, die kann man doch ausbügeln. Bei Bedarf helfe ich gern dabei.
Neueste Kommentare