Ist es eine gute Idee, regelmäßig Zeit für die Bereinigung von Code einzuplanen? [geschlossen]

42

Ich leite ein kleines Entwicklerteam. Von Zeit zu Zeit beschließen wir, ein oder zwei Tage für die Bereinigung unseres Codes aufzuwenden.

Wäre es eine gute Idee, eine reguläre Zeit einzuplanen, z. B. 1 Woche alle 2 Monate, um nur unsere Codebasis zu bereinigen?

user84667
quelle
9
Ich würde es vorziehen, zuerst alle Dinge, die eine Bereinigung erfordern, in einem Fehlerverfolgungstool zu registrieren . Die Analyse protokolliert die Probleme in den Tracker könnte man besser (viel besser) Idee geben , was der geeignetste Ansatz für ein bestimmtes Projekt sein würde
gnat
4
Es wäre eine bessere Idee, eine regelmäßige Zeit für einen planen Code - Review
l46kok
1
Was meinst du mit "aufräumen"? Verschönert es den Code oder behandelt es alle FIXME- und TODO-Tags oder erzielt es mehr Leistung aus schnell geschriebenem Code? Oder etwas anderes? Jedes davon könnte als Bereinigung eingestuft werden, aber ich würde jedem von ihnen unterschiedliche Prioritäten zuweisen.
Paul
Ein weiteres "als zu beliebt geschlossen", wie, Jungs?
MGOwen

Antworten:

100

Nein.

Beheben Sie es, während Sie daran arbeiten:

  • Wenn Sie warten, um das Teil, an dem Sie arbeiten, zu überarbeiten, werden Sie viel vergessen und müssen Zeit aufwenden, um sich wieder damit vertraut zu machen.
  • Sie werden keinen Vergoldungscode erhalten, der nie verwendet wird, weil sich die Anforderungen geändert haben
MGOwen
quelle
2
Mein Geld für diese Antwort ..
Soner Gönül
2
+1 für eine ausgezeichnete Antwort. Sie werden am Ende keinen "Vergoldungscode" erhalten, der nie verwendet wird, weil sich die Anforderungen geändert haben
Md Mahbubur Rahman
8
Auf ein perfektes Projekt mit perfektem Management und einem Team von einheitlich großartigen Entwicklern würde diese Antwort stehen. Leider habe ich in meinen zehn Jahren in der Branche noch nie ein solches Projekt gesehen oder gehört.
Ben
3
Versuchen Sie dies, aber wenn Sie dies nicht können (und dies aufgrund von Zeitdruck oder weil Sie einfach noch nicht wissen, wie Sie es richtig machen sollen), erstellen Sie ein Ticket in Ihrem Ticketsystem. Auf diese Weise können Sie hoffentlich darauf zurückkommen, während das Problem noch in Ihrem Kopf ist und nicht nur, wenn es irgendwann Probleme verursacht.
Sarien
1
Ich denke, das ist ein guter Rat, aber er geht nicht auf die gestellte Frage ein. Haivng leitete ein Team mit einer horrenden Codebasis (war horrend, bevor ich dort ankam). Es war eine sehr gute Zeit, um das Refactoring und das Aufräumen bestimmter Funktionen in Angriff zu nehmen. Wir nannten sie Infrastrukturprojekte und arbeiteten sie in jeden Sprint ein, den wir konnten. Oft waren dies Dinge, die nicht Teil einer anderen Änderung waren, die das Team jedoch als Problembereiche identifiziert hatte. Wir haben vierteljährliche Rückblicke durchgeführt und diese Liste regelmäßig aktualisiert.
Bill Leeper
21

Meine persönliche Meinung: Für 90% der Projekte unbedingt erforderlich .

Insbesondere für Projekte, die stark vom Verkauf getrieben werden, gibt es in der Regel große Anstrengungen, neue Funktionen in jede Version aufzunehmen, und Sie müssen zwangsläufig Ihre besseren Instinkte aufs Spiel setzen und hier und da ein paar Kludges / Hacks einführen.

Schließlich haben Sie durch diese kleinen Kompromisse genug „technische Schulden“ gemacht, sodass Sie am Ende eine ganze Menge Zeit damit verbringen, die Fehler in der Codebasis zu beheben, und nicht in der Lage sind, ihr volles Potenzial auszuschöpfen.

Normalerweise werden auf diese Weise zwei Arten von Problemen generiert:

  • Kleine, die leicht repariert werden können, aber systemrelevant sein können, z. B. falsch benannte Parameter, unvollständige Fehlerbehandlung usw. Sie haben normalerweise außerhalb des Codeblocks, in dem sie auftreten, nur geringe Auswirkungen. Der beste Weg, um damit umzugehen, ist die Codeüberprüfung und die Überprüfung des Codes beim Schreiben / Ändern. Wie bereits erwähnt, ist es nicht erforderlich, einen speziellen Refactor-Zyklus zur Behebung dieser Fehler vorzusehen.
  • Große Probleme, die möglicherweise auf unvollständige Spezifikationen oder schlechte Entwurfsentscheidungen zurückzuführen sind, oder zwei Entwickler / Teams, die zwei verschiedene Lösungen für dasselbe Problem entwickeln. Diese sind in der Regel viel schwieriger zu beheben und erfordern einen konzertierten Aufwand. Infolgedessen werden sie normalerweise aufgeschoben, bis sie ein ständiges Ärgernis werden. Für die Behebung solcher Probleme ist eine bestimmte Zeit erforderlich.

Im Allgemeinen versuche ich, alle 3 bis 4 Zyklen Zeit für einen reinen Refactorring- / Bugfixing-Zyklus zu reservieren. Ich fordere meine Entwickler immer auf, mir mitzuteilen, wenn sie mit der Codebasis ebenfalls frustriert sind. Nicht jeder Entwickler muss an den Aufräumarbeiten arbeiten - normalerweise (aber nicht immer) können Sie die Teams ein wenig verschieben, sodass immer nur ein Team an den Aufräumarbeiten arbeitet.

pswg
quelle
1
Ich verstehe die erhöhte Anzahl von großen Schüben nicht als ein agiles Problem.
JeffO
2
@ Jeffo Nein, es ist kein agiles Problem. Es ist ein Managementproblem. Wie ich jedoch gesehen habe, tendieren Unternehmen, die stark vom Umsatz beeinflusst sind, zu aggressiven Veröffentlichungszyklen und großen Funktionssätzen. Agile Strategien sprechen diese Unternehmen an (unabhängig davon, ob sie den Strategien wirklich folgen oder nicht). Ich mag zwar die agile Entwicklung, aber meine Erfahrung hat gezeigt, dass ein Unternehmen, das sich selbst als "agil" bezeichnet, in der Regel eine erhebliche technische Verschuldung in der Codebasis erwarten kann.
pswg
Ich denke, wenn sie überhaupt keine Methodik haben, können sie sich selbst nennen, wie sie wollen. Da agil, ist das aktuelle Schlagwort, es ist das attraktivste. Es ist schon eine Weile her, dass ich an einem Wasserfallprojekt teilgenommen habe. Es war auf so viele andere Arten eine Katastrophe, dass ich sie nie als Argument gegen die Methodik verwende.
JeffO
In jedem Projekt, ob agil oder nicht, müssen Sie Code umgestalten und bereinigen, um die technische Verschuldung auf ein Minimum zu beschränken. Wenn Sie dies in Ihren Schätzungen nicht berücksichtigen, müssen Sie damit beginnen. Sie können nicht zulassen, dass technische Schulden anfallen, bis Sie alles stoppen müssen, um sie zu beheben. Befolgen Sie stattdessen die Scout-Regel: "Lassen Sie den Code immer sauberer, als Sie ihn gefunden haben."
Christoffer Hammarström
Nach meiner Erfahrung können unerfahrene Teams, die mit Scrum beginnen, ohne gute Codierungsprinzipien (wie XP) zu beachten, manchmal zu sehr auf Funktionalität (Geschichten) fokussiert sein. Stattdessen sollten sie sagen, dass eine Story erst dann fertig ist, wenn der Code "gut" genug ist, aber nicht jeder genug Backbone hat, um dies unter einer sich abzeichnenden Frist zu tun. Und mit Agile haben Sie in der Regel in kürzerer Zeit mehr Fristen. Deshalb verbinde ich das auch mit agilen Methoden, obwohl ich mir durchaus bewusst bin, dass sie nicht die Ursache sind.
Markijbema
11

Ich habe meine Entwickler ihren Code vor dem Einchecken (Subversion) oder Zusammenführen mit dem Hauptentwicklungszweig (Git) aufräumen.

Ich habe sie das folgende tun:

  • Entfernen Sie irrelevante Kommentare
  • Stellen Sie sicher, dass ihre Methoden, Argumente und Variablen den richtigen Namen haben
  • Stellen Sie sicher, dass die Klassen strukturiert sind und die Elemente so eingekapselt sind, wie sie sein sollten
  • Refactor zur Verbesserung der Lesbarkeit und zur Reduzierung von Code-Gerüchen

Bei größeren Projekten wird der Code vor dem Zusammenführen vom Entwicklungszweig zum Hauptzweig formal überprüft.

Ich denke, dass "Zeit widmen" bedeutet, dass es etwas ist, das aufgrund des Arbeitsaufwands verschoben oder verschoben werden könnte. Wenn Entwickler dies per Check-in durchführen (was einer Änderungsanforderung / einem Problem in JIRA entspricht), ist dies viel einfacher zu handhaben.

Sam
quelle
Nur aus Neugier: Warum benutzt du zwei verschiedene VCS?
Eekhoorn
2
Es gab / gibt eine Migrationsphase. Wir haben jetzt die meisten SVN-Repositorys migriert, ich erwähnte beide für einen bestimmten Kontext.
Sam
Das ist was ich mache. Bereinigen Sie den Code vor dem Einchecken und korrigieren Sie ihn neu, wenn ich zum Code zurückkehre, um die Funktionalität zu verbessern.
Barfieldmv
1
Dies wird nicht auf die quälenden Probleme eingehen, die in Bereichen lauern, die möglicherweise nicht Teil der Funktionsanforderung des Produktteams sind.
Bill Leeper
9

Meiner Meinung nach nicht. Wenn Sie zwischen dem Auftreten einer technischen Verschuldung und dem Beheben zu viel Zeit verstreichen lassen, verlieren Sie den Zusammenhang mit dem Problem. Die Reparatur dauert länger und wird in der Regel schlechter. Am wichtigsten ist, dass die Leute die zerbrochenen Fenster verlassen, weil es keine "Aufräumwoche" ist.

Persönlich verhandele ich für die technische Schuldenbereinigung jeden Sprint, wenn ich weiß, dass wir im Sprint zuvor einige erstellt haben. Es hält die Schulden in den Köpfen der Menschen frisch. Durch die Verwendung des Problemcodes wird die Codemenge begrenzt, sodass das Refactoring einfacher ist. Es verhindert, dass sich technische Schulden häufen. Und es hilft Entwicklern dabei, etwas nicht nur zusammenzuschlagen, sondern es auch gleich beim nächsten Sprint richtig zu machen.

Telastyn
quelle
Dein zweiter Satz widerspricht dem ersten. Sie sagten nein, aber dann sagten Sie, dass Sie diese Art von Dingen in jeden Sprint einarbeiten. Auf eine Art und Weise, die Zeit dafür einplant.
Bill Leeper
2
@BillLeeper - Enh. Wenn ich "reguläre Zeit" höre, bedeutet dies, dass es einige regelmäßige Intervalle gibt, in denen Aufräumarbeiten durchgeführt werden. IMO, das ist falsch - die ganze Zeit ist der richtige Zeitpunkt für Aufräumarbeiten.
Telastyn
1
Guter Punkt, ich stimme zu, dass die reguläre Zeit nicht gut funktioniert. Zu oft führen Prioritäten dazu, dass sie abgebrochen werden usw.
Bill Leeper
4

Ich würde auf jeden Fall mit der Maßgabe Ja sagen: Es sollte oft gemacht werden, vorzugsweise auf wöchentlicher Basis. Ich glaube, dass sich eine geplante regelmäßige Codeüberprüfung in Verbindung mit der tatsächlichen Bearbeitung der aus der Codeüberprüfung resultierenden Elemente sehr schnell auszahlt. Siehe die Antwort von pswg

1 Woche alle 2 Monate ist definitiv nicht oft genug. Dies spricht für die meisten anderen Antworten, die auf Ihre Frage mit "Nein" geantwortet haben. Der Kern der meisten dieser Antworten ist, dass Sie, wenn Sie zu lange warten, nicht mehr mit dem Code in Kontakt sind und das Reparieren / Aufräumen / Refaktorieren in der Regel viel länger dauert.

Mauritz Hansen
quelle
Wir machen dafür einen "Technical Debt Tuesday". Auf halbem Weg war eine israelische Arbeitswoche zu Ende und wir können einen Schritt zurückgehen, um uns mit Problemen zu befassen
Zachary K.
1

Es ist nicht so klar, ob Sie ab und zu eine zusätzliche Übung zur Code-Bereinigung gemeint haben. In diesem Sinne ja. Was immer wir praktizieren, es kommt immer zu einer gewissen Verschlechterung.

Sie sollten dies nicht als Vorwand nehmen, um nicht das Richtige zu tun [Anwenden von SOLID-Grundsätzen, relevanten Komponententests, Inspektionen usw.].

Jayan
quelle
1

Ich denke, dass die derzeit zwei populären "Nein" - "Ja" -Antworten zwei Aspekte derselben Wahrheit sind. Denken Sie daran, dass das OP von einer von ihm verwalteten Gruppe spricht, nicht nur von sich selbst als Einzelperson. Wir können nicht davon ausgehen, dass alle Entwickler in der Gruppe diszipliniert genug sind, um sauberen, leicht lesbaren Code zu schreiben. und es gibt das Problem von externem Druck und agilen Methoden. Auch wenn sich die Leute nach besten Kräften bemühen, werden sie aufgrund ihres unterschiedlichen Stils möglicherweise Code schreiben, der als sauber angesehen wird, wenn er auseinander liegt, aber unsauber, wenn er zusammen mit anderen betrachtet wird (ganz zu schweigen von den knarrenden Oberflächen).

Andererseits ist das "Reparieren während des Arbeitens" meiner Meinung nach ein Ideal, nach dem man streben kann. Sie können Ihren Code noch "fester" machen, indem Sie

  • sorgfältige Peer-CRing
  • Schreiben von Unit-Tests zusammen mit dem Code selbst
  • Verabschiedung von Kodierungsrichtlinien
  • mit automatischen Formatierern und Lintern (aber YMMV)
  • usw.

Wenn das OP-Team nun das oben Genannte anwendet und seine Untergebenen - z. B. bei Codeüberprüfungen und bei regelmäßigen Code-Bereinigungssitzungen - dazu ermutigt, Fallen zu antizipieren und Hässlichkeiten im Voraus zu vermeiden, wird es im Laufe der Zeit hoffentlich weniger brauchen Putzzeit. (Und dann könnten sie diese Zeit für Dokumentation, tiefgreifendes Refactoring und Wissensaustausch über das, was sie geschrieben und konsolidiert haben, verwenden.)

einpoklum - Monica wieder einsetzen
quelle
1

Ich denke, die Planung der regulären Zeit ist sehr gut, egal ob es sich um eine Aufgabe in einem regulären Wasserfallprojekt oder um Geschichten in einem agilen Projekt handelt. Eine festgelegte Zeit zu haben, ist möglicherweise nicht so wertvoll, als sie nur in Ihren Zeitplan einzuarbeiten. Auf diese Weise können Sie es als Teil des Zeitplans erledigen oder den Bereinigungstag absagen, da Sie mit dem Projekt im Rückstand sind.

Nachdem wir ein Projekt mit einer enormen Code-Verschuldung geleitet hatten, war die regelmäßige Bearbeitung der Projekte der Schlüssel für ein reibungsloses Funktionieren. Einige unserer Sachen waren groß, andere waren klein.

Nach ein paar Monaten dieser Art von Arbeit erzählte mir unser Operations-Teamleiter, wie reibungslos alles lief.

Jeder Gegenstand scheint nicht viel zu sein, aber genau wie alle Schulden wird er hochgeschraubt.

Bill Leeper
quelle
1

Die ideale Antwort lautet "Nein", da Sie die notwendigen Schritte unternehmen, um dies nicht zu einer Notwendigkeit zu machen (bereinigen Sie währenddessen aus mehreren bereits genannten Gründen).

Dies mag am Ende das Ziel sein, aber Sie haben vielleicht ein Team, das weit davon entfernt ist, dies in die Praxis umzusetzen.

Manager müssen Verantwortung übernehmen Es ist nicht immer die Schuld des Entwicklers. Manager können eins sagen, aber sie drängen darauf, dass Projekte abgeschlossen werden und machen Vorschläge, die schlechte Praktiken fördern. Sie können buchstäblich sagen, "wir werden es später aufräumen" oder wenn es funktioniert, ist das gut genug.

Möglicherweise müssen Sie zunächst eine bestimmte Zeit festlegen, um zu zeigen, dass dies wichtig ist. Sobald Sie wissen, dass Ihr Team in der Lage ist, seinen Code zu bereinigen (nicht selbstverständlich), können Sie versuchen, ihn häufiger zu integrieren.

Schließlich sollten Sie keine Zeit festlegen müssen.

Persönlich habe ich Probleme damit, ein neues Problem zu lösen und es zum Laufen zu bringen, während ich versuche, die Dinge in Ordnung zu halten. Ich werde besser darin, mache aber oft eine absichtliche Pause und räume auf. Es ist eine andere Einstellung für mich. Schließlich werden die festen Praktiken zur Gewohnheit.

JeffO
quelle
-1

Nein, Sie sollten dies tun, während Sie programmieren. Dies wird als Refactoring bezeichnet, wenn Sie TDD verwenden. Das Problem, wenn Sie ein oder zwei Monate warten, um den Code zu reparieren und zu bereinigen, besteht darin, dass Sie möglicherweise das Verhalten des Codes ändern, da Sie sich nicht an jeden Teil Ihres Codes erinnern.

Ich schlage Refactoring vor, das darauf basiert, zuerst den notwendigen Code zu codieren, damit etwas funktioniert, und sobald es funktioniert, es neu zu entwerfen, zu optimieren und hübsch zu machen.

Ricardo Mogg
quelle
Dies wird als Refactoring bezeichnet, unabhängig davon, ob Sie TDD verwenden oder nicht. Diese Frage hat nichts mit TDD zu tun ...
Ben Lee