Hallo habr
Ich mache Sie auf eine Übersetzung des Artikels "
Simple Hickey " von Robert C. Martin (Onkel Bob) aufmerksam.
Rich Hickey hielt einen exzellenten Vortrag über Strange Loop mit dem Titel Simple, Easy. Ich empfehle Ihnen dringend, eine Stunde lang zuzuhören. Diese Leistung ist jede Sekunde wert.
In diesem Vortrag wird es einige Dinge geben, mit denen Sie nicht einverstanden sind. Wenn dies passiert, hören Sie auf und denken Sie - denken Sie ernsthaft - sind Sie nicht einverstanden. Vielleicht solltest du nicht denken, dass das so ist.
Zum Beispiel sagt Rich einige scheinbar abweisende Dinge über TDD und Agile and Refactoring, die heiligen Kühe der Agile Community. Wenn Sie sich für diese Community engagieren, können Sie negativ reagieren. Nicht nötig. Rich vernachlässigt die Praxis nicht. Er vernachlässigt Religion - Rücksichtslosigkeit - Frivolität.
Rich vergleicht Unit-Tests mit Sicherheitsgeländern. Dann macht er einen sehr guten Punkt. Er sagt, wenn Sie einen Fehler haben, dann hat dieser Fehler Ihre Tests bestanden. Und was jetzt? Sie sollten jetzt den Fehler finden. Und wenn das System nicht einfach ist, wird es auch nicht einfach sein. (Bitte beachten Sie, dass ich die Wörter hier einfach und leicht verwendet habe. Der Anfang von Richs Rede ist mit unterschiedlichen Definitionen verbunden, die diese Wörter haben. Ich schlage vor, dass Sie an dieser Stelle anhalten und die ersten zehn Minuten seiner Rede anhören und dann wieder zu diesem Absatz zurückkehren.)
Rich betont, dass Sprinter schnell laufen, aber nicht lange. Er sagt dann, dass Agile dieses Problem "gelöst" habe, indem er einfach die Startpistole immer wieder kurz hintereinander abgefeuert habe. Er grinst und das Publikum lacht. Er führt dann aus, dass ein kontinuierlicher Sprint Systeme nicht unbedingt einfach macht, und Einfachheit ist der Schlüssel zur Geschwindigkeit.
Natürlich hat er recht. Martin Fowler sprach darüber in seinem Artikel „Flaccid Scrum“. Und das haben viele von uns in der Agile Community zum Ausdruck gebracht. Solche kurzen Iterationen ohne gute technische Praxis führen nicht zu einer raschen Entwicklung. Vielmehr führt es zu einem Durcheinander.
Rich lacht über die Idee, dass Sie mit einer Testsuite den Code ändern können. Er sagt, dass Tests ein Sicherheitsnetz sind, nichts weiter. Wir TDDer wissen, dass eine Testsuite erforderlich ist, wenn wir Code furchtlos ändern möchten. Aber Rich hat Recht mit dem Sicherheitsnetz. Ein Sicherheitssystem kann Ihnen helfen, Ihr System zu vereinfachen, wenn es bereits einfach ist. Aber ein Sicherheitssystem unter einem großen Drecksack wird wenig dazu beitragen, das Chaos zu entwirren. Oh, versteh mich nicht falsch. Ich brauche diese Tests! Aber die Arbeit wird nicht einfach sein. (Wieder dieses Wort).
Hier ist ein weiterer Vortrag von Rich: Hammock Driven Development, in dem er uns zum Nachdenken anregt und nicht nur Teile und Teile von Code schreibt.
Also hier ist es. Rich ist zu Recht besorgt, dass wir eine komplexe Kultur haben. Wenn eine Aufgabe für Programmierer festgelegt wird, laufen sie vorwärts und schreiben mit "einfachen" Frameworks und Tools viel verwirrenden Code, ohne dem Problem die richtige Bedeutung zu verleihen. Was wir Leichtigkeit mit Einfachheit verwechseln. (Rails ist zum Beispiel einfach, aber nicht einfach.) Seine Beschwerde über Tests ist, dass wir sie verwendet haben, um Gedanken zu ersetzen. Das ist gut für uns, weil wir die Tests geschrieben haben, aber tatsächlich haben wir nicht genug Zeit für das Problem aufgewendet, das es verdient. Wir haben das Problem nicht vereinfacht. Wir haben einfach getan, was einfach war.
In Wahrheit sind die Agile-Community und die gesamte Software-Community mit dieser Krankheit infiziert. Zu oft machen wir das, was einfach ist, weil es einfach ist. Und so machen wir ein Chaos. Aber das ist nicht der Wert von Beweglichkeit und wird es niemals sein. Und das ist natürlich nicht der Wert der Beherrschung der Software! In der Tat ist das, was einfach ist, im Gegensatz zu dem, was einfach ist, eines der bestimmenden Merkmale eines Software-Assistenten.
Letztendlich denke ich, dass Richs TDD-Wahrnehmung durch das, was er in der Branche sieht, verzerrt ist. Ehrlich gesagt, ich glaube, er hat einige Details übersehen. Und ich denke, er würde verstehen, dass diese Praxis für ihn genauso nützlich sein würde wie für mich. Nicht um zu vermeiden, dass du nachdenkst und dich selbst in Unordnung bringst, sondern um diszipliniert detailliert, vorsichtig und nachdenklich zu sein.
Fragen Sie sich nun, was TDD für Sie bedeutet. Ist TDD die Disziplin, die Sie anwenden, um die Dinge zu vereinfachen? Oder ist es eine Disziplin, die Sie verwenden, um nachdenklich, vorsichtig und nicht kompliziert zu sein?