To squash or not to squash

Als Nutzer von GIT als Versionsverwaltung dürfte einem bewusst sein das die Historie nicht
in Stein gemeißelt ist. Commits können sowohl lokal als auch remote auf dem Server verändert
werden
. Eine recht verbreitete
Variante dieser Veränderung ist der “Squash”.

Tatsächlich kann man vortrefflich darüber streiten ob es sinnvoll oder vielleicht sogar
gefährlich ist die Historie in einem System zu verändern dessen elementare Aufgabe es ist
eben diese zu bewahren. Für mich ist der Squash in erster Linie ein Mittel um einen Feature-Branch
aufzuräumen, bevor dieser zurück in den master-Branch fließt.

Dabei ist es für mich ein absolutes No-Go blind sämtliche Commits zusammenzuführen nur damit die
Zahl der Commits gering gehalten wird. Wohl aber finde ich es sinnvoll über die Commits zu gehen,
eventuell logisch zusammenhängende Commits zusammenzuführen oder neu zu sortieren. Kleine Fehlercommits
ala “tippfehler korrigiert” interessieren im Nachgang auch niemanden.

Zwiespältig sehe ich das entfernen von Commits die einen Fehler produziert haben. Handelt es sich
um einen Flüchtigkeits- oder Tippfehler dann kann der mMn gerne weg. Bei Denkfehlern kann ein zweiter
Commit mit einer Korrektur und einem Hinweis auf diese vielleicht für einen Reviewer oder interessierten
Codeleser weiter helfen dieses Problem selbst zu vermeiden. Muss man also von Fall zu Fall entscheiden.

Was schon aufgrund technischer Gefahren nicht passieren sollte sind Änderungen der Historie auf dem
Master-Branch, oder auch auf Intergrations-Branches. Diese werden typischerweise von mehreren Entwicklern
verwendet, gar kontinuierlich geliefert und was geliefert wurde sollte sich nach der Lieferung auch
nicht mehr verändern.

Code Reviews

Pair-Programming ist allgemein eine ziemlich doofe Zielsetzung. Klar mal für ein Problem, oder ein Experiment mit dem Kollegen am Rechner kuscheln ist ganz nett. Längere Sessions ermüden mich persönlich allerdings doch schnell und es schleicht sich dann auch bald ein Gefühl der Ineffizienz ein. Dabei lernt man gemeinsam neue Technologie kennen, teilt direkt das Wissen und steigert die Qualität des Produktes. Ganz nebenbei lernt man auch den Stil und die Denk- und Arbeitsweise der Kollegen kennen. Gerade letztere können aber stark von der eigenen abweichen und damit sind Konflikte eigentlich vorprogrammiert.

Ich persönlich bin also eher nicht der Pair-Programming Typ. Die oben genannten Vorteile finde ich persönlich in einem eigentlich stärker qualitätsorientieren Verfahren wieder, dem: Code-Review.

Leider kannte ich Code-Reviews bis vor einiger Zeit Code-Reviews primär als zufälliges Ereignis, bei dem dann typischerweise ein Verriss des untersuchten Codes stattfand. Grund für diese Reviews war meist, ein beim Testen aufgetretener Fehler, der einen anderen Entwickler auf den Plan rief. Ergo war das Review unbeliebt und unproduktiv.

Die zweite Variante die ich kannte war das öffentliche Code Review mit Beamer und großem Auditorium. Dabei wurden dann meist komplexe Codes an die Wand geworfen und spätestens nach 10 Minuten wich die Stimme des Präsentierenden dem angenehmen Rauschen des Beamers, das irgendwann wiederum durch ein: “noch Fragen” jäh unterbrochen wurde.

Die Wirklich geile Version des Code-Reviews aber ist die, welche stetig durchgeführt wird. Stetig weil sie Teil einer Definition of Done ist und weil jede Codeänderung, egal ob Bugfix oder Feature, von mindestens einem zweiten Entwickler begutachtet wird.

Wie schon erwähnt funktioniert das nur in einer Umgebung die konstruktiv und objektiv zu arbeiten bereit ist. Nicht jeder Entwickler hat die gleichen Ansprüche und Voraussetzungen, daher muss beim Review klar sein, dass der Code des anderen durchaus in Ordnung sein kann auch wenn man ihn selbst so niemals geschrieben hätte.

Allgemein habe ich Code-Reviews in meinen letzten Projekten als sehr hilfreich erfahren und lieben gelernt. Zum einen lernt man so den Stil- und die Lösungsstrategien der Kollegen kennen, zum anderen lernt man neuen heißen Scheiß kennen. Auf jeden Fall hat man am Ende immer das Gefühl als Team ein besseres Ergebnis geliefert zu haben.

Klar fasst man sich manchmal dabei an den Kopf, wenn man merkt was man da für einen Schmarn geschrieben hat, oder wie umständlich der andere gedacht hat, diese Minuten des WTF-Gemurmels werden aber meines Erachtens durch Lerneffekt und Qualitätsgewinn mehr als aufgewogen.

Ein Allheilmittel ist das Code-Review natürlich nicht. Vor allem zu komplexe und umfangreiche Änderungen sind schlecht für Reviews geeignet, sind aber dann auch Anzeichen für andere Probleme im Entwicklungsprozess.

Gnome 3 - Buttons in der Titelzeile auf die rechte Seite

Weil ich jedesmal beim Rechner-Setup danach suchen muss wie man die Buttons in der Titelzeile nach Rechts bekommt, wo sie mein motorisches Gedächtniss erwartet:

gsettings set org.gnome.desktop.wm.preferences button-layout ':minimize,maximize,close'

Sichere Passwörter mit Firefox und KeePass 2 in Bequem

Ich hab nun schon seit langem für quasi jeden Account ein eigenes Passwort. Weil mein Gehirn nunmal nicht ausreicht um bei der Menge an bekloppten Logins die man so ansammelt alle Passwörter und Benutzernamen zugriffsbereit zu speichern, setze ich auch KeePass 2 als alternative Ablage.

Mit dem Firefox ist das aber irgendwie so eine Sache, ich habe eine ganze Zeit lang den KeePassHttp-Connector verwendet, so richtig fluffig war die Integration aber nicht. Für den Chrome / Chromium gab es da eine deutlich bessere.

Deutlich besser fühlt sich das Plugin Kee das zusammen mit einem Plugin für KeePass 2 entwickelt wird und auf verschiedenen Plattformen läuft.

Haken an der ganzen Installation ist die Abhängigkeit von den fetten Mono Paketen und das Vertrauen in die externen Paketquellen, aber Speicher ist ja zum Glück nie Thema und immerhin ist der ganze Stack Open Source ;)

Pessimismus zum Neujahr

Es ist der 1. Januar, ich hab ein spannendes und anstrengendes Jahr hinter mir und ich hoffe das neue wird noch spannender bei weniger unnötiger Anstrengung.

Der Start ist zumindest schon mal homogen, die Massen der Nacht haben Feinstaub in Massen in die Luft entlassen (natürlich nur bei der Fahrt mit dem TDI auf die Anhöhen vor der Stadt) und im Gegensatz zu irakischen Chemiewaffen (ich weiß der ist alt) kann man die Orte des nächtlichen Treibens auch noch sehr gut sehen. In diesem Sinne auf in ein neues Jahr, vielleicht sogar wieder mit Blog Posts ;)

Happy New Year 2018!