Toyota ist als die effizienteste Organisation auf dem Planeten außerhalb des menschlichen Körpers bekannt, und eine ihrer Philosophien besteht darin, Dokumentation zu vermeiden. Anstatt einen "Prozess" zu machen, wenn jemand am Fließband mehr Schrauben benötigt, haben sie einfach 5 Behälter auf ihrem Regal und wenn man leer ist, bewegen sie es vom Regal und jemand kommt jede Stunde vorbei und füllt alle Regale auf von der Rückseite. Sie müssen nichts dokumentieren, der Prozess erledigt das für Sie.
Da war ein neuer Artikel über Quartz die über Apples Aufmerksamkeit für Checklisten sprachen.
Es stellt sich heraus, dass der Schlüssel zu Apples Kreativität, Geschwindigkeit und Anpassungsfähigkeit auf seiner Oberfläche das genaue Gegenteil der freizügigen Kreativität ist, die man erwarten könnte. Es ist eine Checkliste ... eine wirklich lange.
Was mich dazu gebracht hat darüber nachzudenken, was meine Philosophie über Checklisten ist. Es ist viel falsch mit Checklisten. Sie sind veraltet. Sie können lang und langweilig und sich wiederholend sein. Wie alle Metriken können sie sich auf die falschen Dinge konzentrieren. Aber all das gilt auch für das Überspringen von Checklisten, oder? Ich meine, das dritte Mal, dass Sie den gleichen Fehler gemacht haben, ist es wahrscheinlich an der Zeit zuzugeben, dass Ihnen die Einhaltung einer Checkliste Zeit gespart haben könnte .
Aber Checklisten sind nur dann gut, wenn sie angewendet werden, und sie werden oft aktualisiert, und Sie sind immer noch in der Laune eines Menschen, der, um ehrlich zu sein, nicht perfekt gebaut ist.
Wir haben einen Standard Drupal Installieren beginnen wir mit den meisten Kunden, die auf Drupal sind. Dazu gehören Module, Einstellungen, Standardbenutzer und unsere Standardtestdaten. Es war eine Checkliste, aber es war immer veraltet. Dann ging jemand hinein und machte es so spezifisch, dass jeder, der nur über begrenzte Kenntnisse von Drupal verfügte, es tun konnte, also hassten all die eingefleischten Drupal-Leute im Laden es, also nahmen wir das heraus, und dann konnten wir niemanden neu trainieren darauf und nur ältere Drupal-Entwickler konnten ihm folgen, also begannen wir hart zu programmieren Drusch.
Drush bedeutet, dass jeder, der Erfahrung mit Drupal hat, ein paar Codezeilen ausführen kann und alles "magisch passieren" würde. Kein "menschlicher Fehler" mehr, es ist eine Checkliste, aber anstelle eines unordentlichen Menschen, der einer Checkliste folgen wollte, folgte ihm ein Computer.
Das Problem dabei war, dass selbst die einfachste Änderung einen Entwickler benötigte und jede Änderung getestet werden musste und so ziemlich schnell auseinander fiel.
Schließlich stießen wir auf die naheliegende Lösung, die in Drush fest programmiert war und die es schwierig machte, sie zu ändern.
Jetzt haben wir einfach eine Seite namens "Klon mich" oder so ähnlich und wenn wir einen neuen Client haben, kopieren wir ihn einfach. Das Ändern hat früher einen Programmierer und viele andere Aufgaben mit sich gebracht, jetzt kann jeder mit dem Passwort in unserem Team etwas ändern. Wenn ein Designer andere Testdaten wünscht, ändern sie diese und es wird automatisch in unserem nächsten Projekt sein. Wenn ein PM entscheidet, dass wir einen anderen Standardbenutzer für Trainingszwecke benötigen, erstellen sie einen und es wird in unserem nächsten Projekt sein.
"Wenn du das erste Mal tust, tu es einfach. Das zweite Mal, mach es und mache dir Notizen. Das dritte Mal, hör auf und schau, ob es wirklich dasselbe ist. Wenn es einen Prozess daraus macht, weil es wahrscheinlich einen 4., 5. und so weiter geben wird. "- Gavin Andresen, CTO Bitcoin
Wir hatten das Glück, Gavin für ein paar Jahre hier bei Gravity Switch zu haben. Er hat einiges zu unserer Kultur und unserem Code beigetragen, aber seine Weisheit darüber, wann man Dinge "hacken" soll und wann man sie prozedurieren kann, ist etwas, das sich wirklich verändert, wenn ich an die Dokumentation herangehe.
Gavin hat uns gelehrt, dass guter Code selbstdokumentierend ist.