Ich studierte noch Softwaretechnik, als ich in Kontakt kam mit dem Theorie des kaputten Fensters. Obwohl ich mich nicht erinnern kann, wann ich zum ersten Mal davon gehört habe, hat es mich nachhaltig beeindruckt. Die Theorie stammt aus einem Experiment, das Ende der 60er Jahre durchgeführt wurde. Alles darüber finden Sie in einem toller Artikel das NPR zusammengestellt.
Kurz gesagt, Forscher platzierten zwei Autos ohne Nummernschilder in zwei verschiedenen Gebieten: das erste in einem problematischen Viertel von New York und das zweite in einem reichen Viertel des Bundesstaates Kalifornien. Das erste Auto wurde innerhalb weniger Minuten nach dem Verlassen verwüstet, während das zweite einige Tage lang alleine gelassen wurde. Die Forscher beschlossen dann, ein Fenster im zweiten Auto einzuschlagen. Wenige Minuten später fing jemand an, die Teile des Autos zu stehlen, und es wurde schnell so zerstört wie das erste.
Kürzlich habe ich diese Geschichte während einer Kaffeepause mit einem Kollegen von mir geteilt. Ein paar Tage später erzählte er mir, dass er diese Philosophie jetzt auf seinen Codierungs- und Code-Review-Stil anwendet. Das war Musik in meinen Ohren, denn ich versuche immer, das an die Teams weiterzugeben, mit denen ich zusammenarbeite.
Schauen wir uns den folgenden Code an, der in einer Codebasis gefunden wurde, die ich aufgenommen habe und mit der ich gerade arbeite.
Das Ziel besteht nicht darin, die Gründe zu untersuchen, wie und warum wir zu einer so überkomplizierten Lösung gekommen sind, sondern uns in die Lage des Entwicklers zu versetzen, der gebeten wurde, etwas daran zu ändern.
Stellen Sie sich nun die folgenden Fragen:
Eine ehrliche Antwort wird darauf hinweisen nein zu beiden Fragen. Wir Entwickler sind es gewohnt, überkomplexen Code zu finden. Wir wissen auswendig, dass es Zeit braucht, den Code zu verstehen und zu ändern.
Schauen wir uns nun eine überarbeitete Version des vorherigen Codes an und stellen dieselben zwei Fragen.
Das Ändern dieses Codeabschnittes ist bei weitem einfacher als das Ändern des vorherigen. Und im Gegensatz zu dem, was einem Entwickler normalerweise durch den Kopf geht, hilft es, die Codebasis klein und gut organisiert zu halten, wenn die Fristen knapp sind.
Wir denken oft nicht darüber nach, wie die Aufrechterhaltung des Codes die Messlatte für andere, die an dem Projekt arbeiten, setzt. Aber ein Projekt mit einem gut geschriebenen Code wird alle dazu motivieren, das Verhalten nachzuahmen, die Konventionen zu befolgen und Code mit ähnlicher Qualität zu liefern. Wenn es bei dem Projekt keine zerbrochenen Fenster gibt, werden die Leute weniger versucht sein, eines einzuschlagen.
Das Gute an der Pflege eines ununterbrochenen Fensterverhaltens ist, dass es sich letztendlich durch das gesamte Unternehmen ausbreitet Softwareentwicklungsteamund wirken sich auf alle Projekte im Unternehmen aus. Hoffentlich funktioniert das auch als Zeichen für andere Abteilungen und die Philosophie wird außerhalb der Codebasis des Unternehmens übernommen.
Die Erfahrung mit kaputten Fenstern kommt mir hin und wieder in den Sinn, da sie veranschaulicht, wie wichtig geringfügige Verhaltensweisen sind, um zu verhindern, dass Skalierungsprobleme auftreten und Systeme letztendlich ins Chaos geraten. Das ist eine der Regeln, nach denen es sich zu leben lohnt.
Fanden Sie diesen Artikel interessant? Diese könnten dir auch gefallen!
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
