Wann ist es akzeptabel, kaputte Fenster NICHT zu reparieren?

Gibt es in Bezug auf zerbrochene Fenster Zeiten, in denen Refactoring für eine zukünftige Aktivität am besten geeignet ist?

Wenn beispielsweise ein Projekt zum Hinzufügen einiger neuer Funktionen zu einem vorhandenen internen System einem Team zugewiesen wird, das bisher noch nicht mit dem System gearbeitet hat, und eine kurze Zeitleiste für die Arbeit erhalten hat - kann dies jemals gerechtfertigt sein? Verschieben Sie größere Überarbeitungen des vorhandenen Codes, um die Frist in diesem Szenario zu verkürzen.

Refactoring ist und sollte ein fortlaufender Prozess sein. Es reicht nicht aus, nur die Anforderungen mit einer funktionierenden und getesteten Implementierung zu erfüllen, die noch ein wenig unvollständig ist.

"Lass es funktionieren, dann lass es besser funktionieren" .

Ich kann mich nicht erinnern, wo ich dieses Zitat gelesen habe, aber dies ist der Schlüssel, um Refactoring gut anzuwenden, und ich halte es für unprofessionell, etwas anderes zu tun.

Kontinuierliches Refactoring ist wie das Aufwischen von verschüttetem Material während des Kochens und das Reinigen des Geschirrs nach dem Essen. Gezieltes Refactoring ist wie das Auffinden einer schmutzigen Küche, hat aber nur die Zeit, ein oder zwei schmutzige Gläser zu waschen. Möchten Sie lieber mit einer durchgehend schmutzigen Küche leben, oder möchten Sie die Dinge lieber sauber halten?

Sie bringen den Code zum Laufen und überarbeiten ihn dann, um sicherzustellen, dass Sie die bestmögliche Implementierung haben, die Sie möglicherweise verwenden können. Wenn Sie etwas Vertrautes tun, kann es sein, dass Sie den besten Code zum ersten Mal implementieren. Es lohnt sich jedoch, einen Moment zu dauern, um Ihre Arbeit zu überprüfen, um sicherzugehen. Wenn es so aussieht, als könnten Sie Ihren Code verbessern, versuchen Sie eine Umgestaltung, um sicherzustellen, dass Ihr Code mindestens so schlank und sauber ist, wie Sie ihn erstellen können. Dies bedeutet, dass Sie den Betrag der technischen Schulden, die Sie hinterlassen, reduzieren und das Lesen und Umgestalten erleichtern, wenn der Code das nächste Mal bearbeitet werden muss. Dies ist der Kernwert hinter dem TDD-Mantra "Red-Green-Refactor", mit der Ausnahme, dass es sich auszahlt, wenn Sie in TDD in erster Linie die Duplizierung entfernen, auch andere Elemente zu überprüfen, die überarbeitet werden könnten, wie große Klassen, lange Methoden,

Wenn Sie vor einem größeren Umbau stehen, können Sie ihn möglicherweise für eine Weile verschieben, insbesondere wenn Sie in Ihrem Zeitplan zu wenig Zeit haben. Dies setzt jedoch voraus, dass die Funktionalität Ihres Codes nicht beeinträchtigt wird und dass die Implementierung weiterhin den Anforderungen entspricht. Diese Art von Situation sollte selten vorkommen, und Sie können dazu beitragen, dass sie noch seltener auftritt, wenn Sie währenddessen kontinuierlich umgestalten. Noch wichtiger ist jedoch, dass Sie nicht riskieren können, größere Änderungen zu lange aufzubewahren. Andernfalls entsteht später eine noch größere Arbeitslast, deren Behebung entweder viel kostspieliger oder sogar noch kostspieliger sein kann Projektfehler.

Ich habe den Eindruck, dass viele Leute dazu neigen, die Definitionen für Refactoring und Re-Engineering zu verwechseln . Die beiden Begriffe beschreiben Strategien zum Umgang mit sehr unterschiedlichen Situationen. Wenn Sie eine Neuentwicklung durchführen möchten, verpflichten Sie sich zu einer drastischen Änderung, die das Verhalten eines Systems verändert. Dies macht einige Tests ungültig und erfordert auch neue Tests. Mit dem Refactor stellen Sie sicher, dass sich Ihr System weiterhin genau verhältWie vor der Änderung stellen Sie jedoch auch sicher, dass Ihr Code eine lange Lebensdauer hat und sich im Laufe der Zeit einfacher warten lässt. Sie "pimpen" Ihren Code nicht für die Hölle, sondern verpflichten sich zu einem professionellen Standard für sauberen Code, der das Risiko von Fehlern verringert und sicherstellt, dass die Arbeit mit Ihrem Code ein Vergnügen bleibt und einen professionellen Standard aufweist .

Zurück zu der Analogie der zerbrochenen Fenster. Wenn Sie das Fenster zerbrechen, sollten Sie es sofort reparieren. Wenn Sie nicht bemerkt haben, dass ein Fenster zerbrochen ist, müssen Sie die Kosten selbst bestimmen, wenn Sie das Fenster zerbrochen lassen. Nun wiederholen Sie die letzten beiden Sätze, aber Ersatz Bug für Fenster. Sie brauchen am Ende eine andere Strategie. Wenn Sie beim Codieren einen Fehler verursacht haben, können Sie diesen sofort beheben oder feststellen, ob die Änderungen einen erneuten Engineering-Aufwand erfordern, und Sie treffen eine kommerzielle Entscheidung, wann das Problem am besten behoben werden kann. Damit Sie ein Problem nicht umgestalten, sondern umgestalten, um sicherzustellen, dass es einfacher ist, Probleme zu finden und zu beheben. Es ist mir egal, wie erstaunlich Sie Ihren Code finden, komplexe Systeme werden immer Probleme haben, die im Laufe der Zeit behoben werden müssen. Das ist es, worum es bei technischen Schulden geht und warum das Refactoring ein fortlaufender Prozess sein muss, während Sie Ihren Code implementieren , und nicht für eine willkürliche zukünftige Zeit.

Kurz gesagt, die Antwort, dass es in seltenen Fällen akzeptabel ist, größere Änderungen am Code aufzuschieben, um eine Frist zu setzen, sollte jedoch nicht als übliche Praxis angesehen werden, Refactoring als eine Übung zu behandeln, die von Ihrer täglichen Implementierungsarbeit unabhängig ist, und mit Sicherheit Niemals als Ausrede von Teams verwendet, die mit der Codebasis nicht vertraut sind, um zu vermeiden, dass ihre Implementierung so schlank und sauber ist, wie sie es unter den gegebenen Umständen möglicherweise schaffen können.

Einige Entwickler sagen, dass sie "kaputte Fenster reparieren", wenn sie wirklich "die Liegestühle auf der Titanic neu ordnen". Das Refactoring von Code, der funktioniert, aber Ihren Geruchssinn beleidigt, ist relativ einfach. Wenn Sie feststellen, dass Sie immer wieder auf diese Art von Aufgaben zurückkommen, anstatt neue Funktionen für Ihre Benutzer hinzuzufügen oder die App für diese besser nutzbar zu machen (Optimierung bedeutet, dass die App schneller ausgeführt wird, Optimierung bedeutet, dass der Code besser lesbar ist) anders) dann räumst du vielleicht zu viel auf. Nicht weil Aufräumen schlecht ist, sondern weil das Unternehmen für Entwicklung zahlt, um etwas zu entwickeln. Sie wollen zwar keine spröde, schwer lesbare, schlecht strukturierte Lösung, aber sie wollen auch keine polierte und schöne halbe Lösung.

Räumen Sie auf, wenn Sie etwas Einfaches tun müssen, um loszulegen, oder wenn Sie darauf warten, dass ein anderes Team Ihnen mitteilt, ob Ihr Problem tatsächlich seine Schuld ist, oder wenn Sie auf eine Entscheidung warten. Es wird viele Möglichkeiten geben. Wenn Sie die Möglichkeit haben, die gesamte App voranzutreiben, nehmen Sie sie, es sei denn, Sie spüren, dass das Ganze brüchig geworden ist. Es hat wahrscheinlich nicht. Sie haben die Möglichkeit, eine Umgestaltung vorzunehmen - darüber brauchen Sie sich keine Sorgen zu machen.

Um auf die zweite Hälfte Ihrer Frage zurückzukommen, einen Sprint, bei dem Features hinzugefügt werden, die sich auf eine kurze Zeitleiste beziehen, wäre es falsch zu sagen: "Und wir werden kein Refactoring durchführen, wir haben keine Zeit." Es wäre auch falsch zu sagen: "Ich weiß, es sind 6 Wochen vergangen und es sieht für die Benutzer genauso aus, aber diese zerbrochenen Fenster mussten wirklich repariert werden." Passen Sie das Refactoring in die Lücken ein, die in einem Projekt auftreten. Nehmen Sie keine Zuflucht zum Aufräumen auf Kosten des Projektziels.

Aus betriebswirtschaftlicher Sicht ist Refactoring eine spekulative Investition. Sie investiert jetzt Zeit und Mühe (Geld) in der Hoffnung, dass sie irgendwann in Zukunft mehr Zeit und Mühe (Geld) spart.

Ohne in die Debatte darüber einzutreten, wie viel Aufwand beim Refactor in der Zukunft gespart wird (dies hängt von zu vielen Variablen ab, um hier eine bedeutungsvolle Diskussion zu führen), ist es klar, wann der "Kapitalwert" refactor ist. von den Kosten, die sie hinterlassen, übersteigen sie die Kosten, die jetzt anfallen.

Das ist einfach, außer Sie haben keine Ahnung, wie viel die Zukunft kosten wird. Sie müssen auch alle normalen Finanzplanungsideen berücksichtigen, wie z. B. Kapitalrendite, Risikomanagement (Markenwert, rechtliche Haftung, versicherbares versus nicht versicherbares Risiko), Oppertunitätskosten usw.

In den meisten Fällen ist es Sache der Verantwortlichen, zu entscheiden, wann eine Umgestaltung durchgeführt werden soll. Trotz der vielen Plakate in dieser Forensprache wissen Manager in der Regel mehr über die Führung eines Unternehmens als Programmierer. Sie haben ein größeres Bild vor Augen, das die Maximierung der Rendite für den Aktionär einschließt. Es ist selten, dass das Reparieren von Dingen, die nicht kaputt sind, dazu beiträgt, Code ist keine Ausnahme.

Bearbeiten: Ich habe einen interessanten Artikel über die Wartung von Zeitplänen für kritische Infrastrukturen gelesen. Das Wesentliche ist, dass die Bewegung nicht routinemäßig gewartet werden muss (Refactor), um bei Bedarf repariert zu werden (Fix Bugs). Der Hauptunterschied besteht in den Überwachungsebenen - zum Beispiel überwacht ein Kernkraftwerk sehr genau und behebt Fehler, wenn sie "kaputt" sind, jedoch lange vor dem Ausfall. Es hat sich gezeigt, dass das Reparieren an einer Wartungs-Scheule nicht nur mehr kostet, sondern aufgrund von Ausfällen, die durch das Wartungs-Programm verursacht werden, weniger zuverlässig ist. Eine ähnliche Idee ist für Software erforderlich - Refaktorieren der Bits, die kurz vor dem Brechen stehen -, die Sie nur durch Messung erkennen können.

Es ist akzeptabel, wenn der Schaden für das Unternehmen durch das Reparieren größer ist als durch das Nicht-Reparieren.

Situationen, in denen dies auftritt, können sein:

• wo ein Termin oder eine Geschäftsmöglichkeit wegen der Zeit verpasst werden könnte, die zur Lösung benötigt wird
• Wenn ein Teil des Codes (wirklich) in sehr kurzer Zeit ausgemustert werden soll, hat die Umgestaltung des Codes fast keinen Nutzen.

Und diese Situationen treten auf - kommerzielle Situationen werden oft künstliche Fristen einführen, die eingehalten werden müssen, wenn die Gelegenheit zur Aushandlung verstrichen ist, und Anforderungen, die eine zeitliche Komponente haben - zum Beispiel eine Änderung der Gesetzgebung oder der Steuervorschriften, die in Kraft treten von ein bestimmtes Datum - existieren.

Der Trick besteht darin, diese Situationen zu identifizieren und richtig einzuschätzen. Code, der voraussichtlich in den Ruhestand geht, bleibt oft jahrelang bestehen. Künstliche Fristen müssen möglicherweise eingehalten werden, sie können jedoch häufig auf unterschiedliche Weise eingehalten werden (z. B. kann Software zu einem bestimmten Zeitpunkt präsentiert, vorgeführt und "gestartet" werden, ohne dass die endgültige Release-Version erst später fertiggestellt werden muss).

Wenn Sie mit so etwas konfrontiert werden, müssen Sie offen darauf zugehen, aber immer fragen, ob es das ist, was es aussieht? Sind die Annahmen realistisch? Gibt es eine andere Möglichkeit, das Ziel zu erreichen, ohne minderwertigen Code zu versenden? Wenn nicht, wie nutze ich die verfügbare Zeit am besten?

Und wenn es keine Alternative gibt, immer gut, aber wann werden wir das beheben?

Denn es sollte fast, fast immer wann sein , nicht wenn .

Wenn Manager beschließen, technische Schulden aufzubauen . Dies ist eine faire Entscheidung, wenn man zum Beispiel nur einen frühen Prototypen an einige Erstkunden ausliefern möchte, um ein frühes Feedback zu erhalten.

Sie können sich das genauso vorstellen, als würden Sie um Gutschrift bitten. Ist es in Ordnung, kurzfristig Geld für eine Investition in X zu leihen und langfristig zu bezahlen? Es gibt keine definitive Antwort, es kann im besten Interesse der Organisation sein (z. B. um die aktuellen Kundenerwartungen zu erfüllen) oder es kann eine Katastrophe sein, wenn dies verantwortungslos geschieht.

Alles hängt von Prioritäten ab, und das Management sollte sich darüber im Klaren sein, dass jedes Mal, wenn Sie zerbrochene Fenster verlassen, die Priorität Nummer eins verlangsamt wird, obwohl die Priorität Nummer eins darin besteht, dass "Code funktioniert", neue Funktionen implementiert werden und die Kundenerwartungen erfüllt werden schwieriger und erfordern mehr Ressourceninvestitionen. Außerdem ist es in 99% der Fälle nicht möglich, die Entwicklung neuer Funktionen einzustellen und alle Anstrengungen auf die "Korrektur der Codebasis" zu konzentrieren.

Fazit: Ja, es ist akzeptabel, manchmal zerbrochene Fenster zu lassen, genauso wie es akzeptabel ist, um einen Kredit zu bitten. Denken Sie daran, dass Sie in Zukunft wirklich, wirklich dafür bezahlen müssen. Und in Zukunft wird die Zeit dafür höchstwahrscheinlich nicht viel länger sein als die Zeit, die Sie jetzt haben.

Normalerweise sollten Sie das Problem beheben, wenn Sie dazu in der Lage sind. Dadurch wird potenzieller Zeitaufwand für die Wartung vermieden. Einige barbarische, nicht agile Praktiken neigen jedoch dazu, den Status quo so lange aufrechtzuerhalten, wie er funktioniert. Einige Manager haben Angst vor den "unvorhergesehenen Auswirkungen" der Änderung.

Ich nehme an, es nur zu lassen, wenn es so funktioniert, wie es sollte (nur durch Optimierung, aber nicht durch Funktionalität unterbrochen), und Sie haben keine Zeit, es zu testen, wenn Sie einige Umgestaltungen vornehmen. Sie sollten jedoch beachten, dass dies später so bald wie möglich behoben werden sollte.

Wenn die Funktionalität nicht mehr funktioniert und Sie neue Funktionen benötigen, ist es am besten, sie so schnell wie möglich zu beheben.

Die meisten Programmierer haben es sich zur Aufgabe gemacht, Geld für ihren Arbeitgeber zu verdienen. Also, wann sollte Refactoring stattfinden: Wenn es Ihr festes Geld verdient. Refactoring ist Zeit, die nicht für andere Projekte aufgewendet wurde, und Zeit, die in Zukunft für dieses Projekt gespart wurde.

Ob es sich lohnt, liegt meistens bei Ihrem Vorgesetzten.

Die Programmierer sollten die Geschäftsseite über das Ausmaß der technischen Verschuldung informieren, damit sie eine fundierte Entscheidung treffen können. Wenn die Notwendigkeit, früher auf den Markt zu kommen, das Risiko Ihres Codes überwiegt, haben Sie nicht viel Auswahl. Mangelnder Cashflow wird viele technische Entscheidungen übersteigen.

Um einige der Probleme in eine nichttechnische Perspektive zu rücken, weisen Sie auf die längere Zeit hin, die erforderlich ist, um Fehler zu beheben und neue Funktionen hinzuzufügen. Wenn das Management einen Vertriebs- und Marketing-Hintergrund hat, kann es dies verstehen. Sie hassen es, Kunden sagen zu müssen, dass diese Dinge länger dauern werden.

Wenn Sie überlegen, Ihr Team zu erweitern, ist dies möglicherweise ein guter Zeitpunkt, um einen Junior-Entwickler einzustellen. Testberichterstattung wird in diesem Fall ein großer Retter sein. Sie lernen mehr, indem sie die Dokumentation lesen.

Kann es jemals gerechtfertigt sein, größere Umgestaltungen des vorhandenen Codes aufzuschieben, um die Frist in diesem Szenario einzuhalten?

• Wenn etwas kaputt ist, dann höchstwahrscheinlich nicht. Sie werden kein Auto mit teilweise funktionierenden Bremsen fahren, oder? (Es sei denn, das Risiko, nicht rechtzeitig irgendwohin zu gelangen, ist größer als das Risiko eines Absturzes aufgrund der fehlerhaften Bremsen.) Keine ideale Lösung, aber leider passiert es.

Wenn Sie jedoch über das Re-Factoring von Arbeitscode sprechen, würde ich Folgendes in Betracht ziehen:

• Wenn es nach unseren leitenden Entwicklern oder technischen Direktoren ginge, würden wir niemals Software veröffentlichen. Wir haben immer den Perfektionismus überarbeitet und danach gestrebt.

• Wenn sich das Re-Factoring negativ auf die Rentabilität des Geschäfts auswirkt, sollte es neu geplant werden.

• Wenn Ihr Unternehmen versprochen hat, bestimmte Funktionen bis zu einem bestimmten Datum bereitzustellen, werden Sie später eine Umgestaltung vornehmen. Denken Sie an die Wohltätigkeitsorganisation Red Nose Day - jedes Jahr können Spenden für einen Zeitraum von 24 oder 48 Stunden gesammelt werden. Es gibt keine Möglichkeit, dass sie ihre Codebasis neu faktorisieren, wenn sie glauben, dies könnte sie davon abhalten, in dieser Zeitspanne Spenden zu erhalten. Darüber hinaus ist es sehr wahrscheinlich, dass sie sich dafür entscheiden, nicht neu zu faktorisieren, wenn ein Fenster zerbrochen ist, dies jedoch keine Auswirkungen auf ihre Fähigkeit zur Entgegennahme von Spenden hat.

• Sie werden immer einen besseren Weg finden, um etwas zu tun. Es ist ein natürlicher Prozess und es ist sehr wichtig, eine Grenze ziehen zu können.

Als Antwort auf Ihre Frage zum Refactoring würde ich "Ja" sagen. Wie jemand anderes in den Antworten oben ausgeführt hat, ist das Refactoring ein fortlaufender Prozess, und manchmal gibt es taktische und geschäftliche Entscheidungen, die die Notwendigkeit überflüssig machen, bereits funktionierenden Code umzuschreiben (wenn auch vielleicht auf kluge Weise).

In Bezug auf "kaputte Fenster": Ich habe diesen Begriff zum ersten Mal vor ungefähr 10 Jahren im Zusammenhang mit der Softwareentwicklung gehört. Zu dieser Zeit wurde es jedoch verwendet, um das Zulassen von Tests mit defekten Einheiten zu beschreiben . Dies beschreibt das Szenario, in dem Benutzer versucht sind, defekte Komponententests nicht zu reparieren, da es zweckmäßiger erscheint, sich nur daran zu erinnern, welche Tests "in Ordnung sind, um fehlzuschlagen", anstatt die defekten Tests zu reparieren (die aufgrund von Schnittstellen oder Anforderungen gültig defekt waren) Änderungen, zum Beispiel).

Ich denke, die Anwendung der Metapher für zerbrochene Fenster auf Komponententests ist passender und beschreibt die Gefahr, "zerbrochene Fenster" in der Nachbarschaft der Software zuzulassen. Wenn Sie von defekten Komponententests (wie zerbrochenen Fenstern) sprechen, ist die Antwort meiner Meinung nach, dass dies niemals in Ordnung ist. (Soweit wir jemals nie sagen können ...)

Wenn es wirklich kaputt ist, sollte es repariert werden.

Aber ist es wirklich kaputt? Sind Sie sicher, dass Sie nicht einfach "nicht hübsch" mit "kaputt" gleichsetzen?

Sie müssen eine Berechnung des "versunkenen Werts" anwenden, bevor Sie den Arbeitscode neu faktorisieren, weil Sie den Stil nicht mögen oder weil Sie glauben, dass er in Zukunft Probleme verursachen wird.

Für das Re-Factoring von Code, den Sie in der letzten Woche geschrieben haben, sind die gesunkenen Kosten die Zeit, die Sie damit verbracht haben, den Code in der letzten Woche zu programmieren.

Re-Factoring-Code, der den Komponententest durchlaufen hat. Jetzt müssen Sie nicht nur neu schreiben, sondern alle bisher durchgeführten Tests neu definieren und erneut ausführen. Dies sieht langsam teuer aus.

Re-Factoring-Code, der in die Produktion gegangen ist. Es müssen noch weitere Tests durchgeführt werden, und die Benutzer werden informiert. Außerdem besteht das Risiko, dass etwas ausgeliefert wird, das nicht so gut funktioniert wie das alte Release. Sie müssen dies begründen und mit dem großen Chef klären, bevor Sie fortfahren.

Re-Factoring-Code, der seit einiger Zeit in der Produktion ist und mehrere Releases und Fehlerbehebungen durchlaufen hat. Wenn Sie nicht wissen, dass die Software nicht mehr funktioniert, gehen Sie nicht einmal dorthin!

Ich habe die Erfahrung gemacht, dass der Abgabetermin das Wichtigste für das Unternehmen ist. Es hängt wirklich davon ab, wer Ihre Anwendung verwenden wird. In meinem Fall handelte es sich um Software für Mobiltelefone. Versäumte Fristen bedeuteten verpasste Verkaufsziele und Kurserfolge.

Beim Betrachten von Code, den wir geerbt haben und der eindeutig geändert werden musste, stießen wir auf eine Reihe von WTF-Momenten. Da dieser Code jedoch "so gut wie" funktionierte (Asynchronität wird nur unzureichend verstanden), gab es für das Management keinen Anreiz, das Refactoring tatsächlich zuzulassen, während noch ausstehende Verpflichtungen zu erfüllen waren. Erst als ein Fehler in der Wildnis entdeckt wurde, durften wir etwas ändern, auch wenn wir es uns durch dunkle Randfälle leicht brechen konnten. Ich habe einmal in meiner Freizeit ca. 10.000 Codezeilen überarbeitet und musste sie schließlich wegwerfen. Der Zeitaufwand für Tests und Überprüfungen usw. konnte nicht gerechtfertigt werden.