Wie gehen Sie mit hässlichem Code um, den Sie geschrieben haben? [geschlossen]

Ihr Client fordert Sie daher auf, Code zu schreiben. Er ändert dann wie erwartet die Spezifikationen für Sie und Sie implementieren seine neuen Funktionen gewissenhaft wie ein guter kleiner Junge. Außer ... die neuen Funktionen stehen in Konflikt mit den alten Funktionen, sodass Ihr Code jetzt ein Chaos ist. Du willst es wirklich wieder in Ordnung bringen, aber er fordert immer wieder neue Dinge an und jedes Mal, wenn du mit dem Putzen fertig bist, wird es wieder schlimm.

Wie geht's? Hör auf, ein OCD-Wahnsinniger zu sein und akzeptiere einfach, dass dein Code ein Chaos aufwirbelt, egal was du tust. Speichern Sie die Reinigung für Version 2?

Holen Sie sich einen anderen Job und lassen Sie andere Leute damit umgehen. Muahahahhahahaa.

.....

Ich mache nur Spaß. :)

Aber im Ernst: Die Schätzung der Polsterung ist dein Freund. Ich mache im Allgemeinen eine anständige realistische Schätzung und verdopple sie dann. Das klingt vielleicht übertrieben und ist es manchmal auch, aber es ist besser, ein bisschen zu überschätzen und manchmal sogar ein bisschen zu langsam auszusehen - als schlechte Eindrücke zu hinterlassen, indem man fehlerhaften Code herausstellt und immer Ihre Schätzungen überträgt. Und natürlich entstehen Ihnen technische Schulden, indem Sie die Codebasis hacken lassen.

Ein weiterer (verwandter) Tipp: Schätzen Sie immer scheinbar winzig kleine Aufgaben auf einen anständigen Block. Nehmen wir zum Beispiel an, ein Artikel, von dem Sie fast sicher sind, dass er nur eine Zeile und 30 Sekunden lang geändert wird, beträgt 1 Stunde (oder was auch immer der niedrigste Zeitblock in Ihrer Arbeitszeittabelle oder Ihrem CR-System ist, z. B. 15 Minuten / 0,25 Stunden). . Und geben Sie halbtägige oder eintägige Blöcke für die etwas größeren, aber dennoch relativ unbedeutenden Gegenstände.

Der Grund dafür ist vor allem psychologischer Natur: Wenn Sie es sich zur Gewohnheit machen, kleine Änderungen schnell zu hacken, fühlt sich die Arbeit überstürzt an, und Sie werden sich nie zurücklehnen, eine Bestandsaufnahme machen und Dinge überarbeiten, die überarbeitet werden müssen. Auf praktischer Ebene: Kleine, aber nicht triviale Änderungen gehen manchmal verloren, und Sie möchten nicht ständig das Gefühl haben, hinter dem Zeitplan zurückzubleiben und Fehler zu löschen. Es ist ein wesentlicher Grund, warum Codebasen im Laufe der Zeit hacky werden.

Denken Sie zum Schluss immer daran, dass die Leute nicht wissen müssen , dass Sie Ihre Schätzungen etwas auffüllen. Solange Sie ein kompetenter Entwickler sind und die Arbeit in einem angemessenen Tempo ausführen, ist diese Polsterung nicht spürbar. Sagen Sie dem PHB also nicht "Meine erste Schätzung ist, dass es zwei Stunden dauern wird, aber geben Sie mir einen halben Tag". Sag ihm einfach "Ich denke, es wird ungefähr einen halben Tag dauern." und lass es dort.

Überschätzen Sie absichtlich die Zeit, die für Ihre nächsten Funktionen benötigt wird. Verwenden Sie diese zusätzliche Zeit zum Aufräumen.

Sie werden niemals in der Lage sein, die Wartung zu rechtfertigen, und der Kunde benötigt sie trotzdem. Geben Sie ihm das bittere Medikament (leicht erhöhte Kosten für die nächsten Funktionen), damit es besser wird.

Versuchen Sie, bei der Integration neuer Funktionen eine ordnungsgemäße Neugestaltung durchzuführen. Es gibt nicht später. Ohne das Redesign erhöhen Sie ständig die Reibung für weitere Änderungen und neue Funktionen.

Irgendwann wirst du fast zum Stillstand kommen, wo alles ewig zu dauern scheint. Die meisten Unternehmen entscheiden sich an dieser Stelle wahrscheinlich für das große Umschreiben, Version 2. Es hat eine ziemlich schlechte Wirtschaftlichkeit und ist ein guter Moment für Ihre Kunden, eine andere Entwicklungspartei zu versuchen, wenn sie sich geneigt fühlen.

Eine ordnungsgemäße Neugestaltung / Umgestaltung kann die Investition Ihrer Kunden schützen und die Nachhaltigkeit gewährleisten. Sie müssen dies einbauen. Für Veränderungen optimieren, Licht reisen.

Mit all den Kommentaren über das Überschätzen denke ich, dass eine bescheidene Menge an Punkten (auch Gelegenheit) verpasst wird.

Es geht nicht darum, die benötigte Zeit für die Änderung zu schätzen (nur) und dann einige hinzuzufügen, sondern darum, die Zeit zu schätzen, die erforderlich ist, um den Code zu ändern (Refactor!), Um ihn an einen Punkt zu bringen, an dem die Änderung sicher vorgenommen werden kann, und um dann die Änderung durchzuführen ändern (wahrscheinlich etwas zusammen geklebt). Ok, das ist das Gleiche ... aber es gibt keine Frage von Fudging oder Stretching oder Over-Estimating, es ist einfach eine Frage der Aussage, dass ich dazu zuerst das tun muss und dies ist, wie lange es dauern wird insgesamt. Entscheidend dabei ist, dass Sie an den Teilen des Systems arbeiten, von denen die Änderung abhängt, und nicht mehr - wenn es anderswo schrecklichen Code gibt ... hart, fangen Sie ihn auf, wenn Sie dort sind.

Um noch einmal auf die ursprüngliche Frage zurückzukommen: Nach vielen Jahren kommt es für mich darauf an, wenn Sie etwas implementieren, es sei denn, Sie wissen (nicht glauben, nicht erwarten (vermuten?), Nicht denken, aber wissen ), dass es zusätzliche Dinge gibt Auch erforderlich, dann sollten Sie tun, was Sie brauchen, um diese Anforderung umzusetzen, und nicht mehr so ​​ordentlich und elegant wie möglich.

Wenn Sie die nächste Sache implementieren möchten - einige Zeit später -, müssen Sie die erforderlichen Schritte ausführen, um die Codebasis (und die Datenbank und was auch immer) in den Zustand zu versetzen, der für die Implementierung dieser Funktionalität erforderlich ist. Dieses Refactoring ist der Ort, an dem Sie sich mit dem Chaos befassen, das bei der Entwicklung eines Projekts auf natürliche Weise entsteht - und hoffentlich vermeiden, mehr Chaos zu verursachen (oder zumindest die Ebene konsistent zu halten).

Einer der Diskussionsbereiche hier ist "Technische Schulden" - es ist wie eine Überziehung, Sie müssen sie zurückzahlen und je länger Sie sie lassen, desto mehr Zinsen (in diesem Fall Zeit für die Korrektur) fallen an - was Ihnen einen Nutzen bringt Argument dafür, einen Teil Ihrer Zeit mit der Minimierung der technischen Schulden zu verbringen.

Dies ist auch der Punkt, an dem Unit-Tests und andere automatisierte Tests (wenn ich das so gut kann, wie ich es mit ziemlicher Sicherheit behaupten kann) in Kombination mit einem geeigneten Build-Server (der zumindest einige ausführen kann) eingeführt werden Ihrer Tests). Kombiniert mit diesen - aber von Wert für sich selbst - sind Muster wie Abhängigkeitsinjektion und Umkehrung der Kontrolle (nie ganz sicher, wie sehr diese beiden "gleich" sind), weil sie das Wechseln der Leitungen und damit den Umgang mit Veränderungen in der Leitung erleichtern Isolierung.

Schließlich - denken Sie daran, wenn es nicht kaputt ist, reparieren Sie es nicht. Reines Aufräumen des Codes zum Zweck des Aufräumens mag zufriedenstellend sein, aber es ist auch eine Gelegenheit, Fehler einzuführen. Es kann zwar schmerzhaft sein, wenn Sie es nicht ändern müssen und nicht darauf aufbauen, aber es ist möglicherweise besser, einige Klumpen zu hinterlassen Alleine - die Gelegenheit zum Reparieren oder Ersetzen wird sich irgendwann ändern!

1) Richtige Änderungskontrolle ist dein Freund

Wenn der Kunde die Spezifikation ändert, die in Ordnung ist, ist dies sein Recht. Es handelt sich jedoch um eine Änderung, die in Rechnung gestellt werden muss (oder in einer Weise berechnet wird, die für die Projektstruktur / -beziehung angemessen ist).

Die Schätzung für diese Änderung sollte die Kosten für das notwendige Refactoring enthalten. Der Client mag sich über die hohen Kosten lustig machen, aber an diesem Punkt müssen Sie ihm erklären, dass es Elemente gibt, die umgeschrieben werden müssen, um sicherzustellen, dass der Code in Zukunft robust und unterstützbar ist Wenn dies nicht getan wird, hat er wahrscheinlich Probleme mit zukünftigem Support oder Änderungen, die noch teurer werden.

2) Refactoring sollte so durchgeführt werden, dass der Kunde einen echten langfristigen Nutzen daraus ziehen kann

Wenn Sie über ein Refactoring nachdenken, müssen Sie immer berücksichtigen, was tatsächlich benötigt wird und was wichtig ist, und sicherstellen, dass die Refactoring-Arbeiten ein echtes langfristiges Preis-Leistungs-Verhältnis bieten.

Schließlich sollten wir diese Dinge tun, damit der Code mittel- und langfristig erweiterbar und unterstützbar bleibt, um sicherzustellen, dass die Investition des Kunden gültig bleibt und nicht aus dem Drang nach theoretischer Perfektion heraus. Refactoring-Arbeiten (und die entsprechenden Schätzungen) sollten in diesem Umfang durchgeführt werden, und nicht nur, weil Sie jetzt der Meinung sind, dass es einen etwas besseren Weg gibt, dies zu tun.

Einige Programmierer schlagen vor, dass ein Weg, dieses Problem mit Clients zu steuern, darin besteht, dass der Client die anfängliche Spezifikation signiert und autorisiert. DANN teilen Sie ihnen mit, wenn sie eine Anforderungsänderung fordern, die nicht in der ursprünglichen Spezifikation enthalten ist, dass Sie den Vertrag und den Projektzeitplan durchgehen müssen, um zusätzliche Kosten und Zeitverzögerungen zu berechnen, und fügen Sie dem Vertrag dann einen Anhang bei. Anscheinend ist es ein Wunder, Kunden daran zu hindern, auf neuen (unvorhergesehenen) Funktionen zu bestehen.

Ich habe den folgenden Kommentar in einer Codebasis, an der ich gerade arbeite:

/*
 * Every time I see this function, I want to take a shower.
 */

Ich weiß sehr gut, welche Situation Sie beschreiben. Ich versuche (mein Bestes) zu warten, bis sich die Dinge beruhigt haben und jede Art von "Kriechen" alles "geschlichen" hat, was es tun wird. Bis dahin haben Sie wahrscheinlich etwas Nutzbares veröffentlicht, und Sie können sich etwas Zeit nehmen, um die Dinge zu bereinigen und etwas anderes zu implementieren.

Sie können nicht immer wieder herumlaufen und viele kleine Drecksäcke beseitigen. Das verdreifacht nur deine Arbeit und deine Frustration. Warten Sie, bis es ein größeres, aber kaum rührendes Chaos wird, und dann können Sie etwas dagegen tun.

Ich bevorzuge es, diese Situation zunächst zu vermeiden.

Es hängt alles davon ab, wie Sie die Spezifikation gelesen haben. Man kann sie sich leicht als Steintafeln vorstellen, aber in Wirklichkeit ändern sich die meisten Spezifikationen. Berücksichtigen Sie beim Entwerfen des Codes, wie wahrscheinlich es ist, dass sich die einzelnen Teile der Spezifikation ändern. Mit der Zeit werden Sie ziemlich gut darin sein, dies vorherzusagen.

Erfahrung und Urteilsvermögen sind sehr wichtig. Schreiben Sie wegen dieses Spaghetti-Codes neue Bugs? dauert die Implementierung länger? diese würden darauf hindeuten, einen taktischen Refaktor durchzuführen.

Für die Zukunft klingt es so, als müssten Sie partnerschaftlich mit Ihrem Kunden zusammenarbeiten. Sie sagen: "Dieses Produkt wächst deutlich über die ursprüngliche Spezifikation hinaus. Obwohl das ursprüngliche Design für dieses Niveau gut war, muss es in Richtung X und in Richtung Y erweitert werden. Das Design muss umstrukturiert werden." Kunden dafür zu bezahlen.

Laden Sie stundenweise auf und wenn er Änderungen wünscht, sagen Sie, dass dies in Ordnung ist, aber berücksichtigen Sie die Zeit, die erforderlich ist, um guten Code in die Gleichung zu schreiben. Denken Sie auch daran, dass sich das Schreiben von sauberem Code langfristig auszahlt, wenn Sie ihn warten müssen. Sparen Sie jetzt Zeit und sparen Sie später.

Ich denke, das Schreiben von Software muss mit den geschäftlichen Anforderungen Hand in Hand gehen. Wenn es sich um ein Wegwerfprojekt handelt (wie ein Prototyp, der in einer Woche erstellt werden muss, wobei jeden Tag neue Eingaben hinzukommen), müssen Sie sich keine Gedanken über die Pflege des Codes und andere Dinge machen - Zeit ist entscheidend und Sie müssen nur Schieben Sie Ihren Code so schnell wie möglich aus der Tür.

Wenn Sie jedoch eine langfristige App schreiben, ist es sinnvoll, all dies in Betracht zu ziehen, da dies erhebliche Auswirkungen darauf hat, wie lange es dauert, neue Funktionen zu erstellen, vorhandene Fehler zu beheben, sich in andere Anwendungen und andere Dinge zu integrieren - und Dies wirkt sich auf das Geschäft aus (aufgrund des späteren Zeitaufwands und der höheren Kosten).

Es ist daher besser, den Entscheidungsträger bei Bedarf für die tatsächlichen Kosten des Nicht-Refactorings von Code zu sensibilisieren. Wenn nach meiner Erfahrung die Kosten und die zeitlichen Auswirkungen beider Optionen dem Entscheidungsträger messbar erklärt werden, kann die Entscheidung eine sein Klacks. Erwarten Sie nicht, dass die Leute Ihnen sagen: "Ja, schreiben Sie schönen Code, obwohl das doppelt so lange dauert und mir keinen zusätzlichen Nutzen bringt." Das funktioniert einfach nicht so.

Machen Sie es Teil Ihres Prozesses, ich nenne es "extreme Umgestaltung" und es wird groß sein! ;) Mach es einfach schnell und wenn genug neue Features hinzugefügt wurden, dass es Narbengewebe gibt, überarbeite es. Fragen Sie sich immer wieder: "Wenn ich jetzt von vorne angefangen hätte, wie hätte ich das gemacht?"

Leute, die denken, sie könnten alles von vornherein entwerfen und darüber nachdenken, täuschen sich meistens selbst. Sie (und Ihr Kunde) lernen immer Dinge, wenn Sie mitmachen. Nutzen Sie diese Lektionen.

Da Sie ein guter Programmierer sind, können Sie ziemlich schnell umgestalten, und wenn Sie dies tun, nimmt der Code fortlaufend die "richtige Form" an, was bedeutet, dass er mit weniger Abhängigkeiten flexibler wird.

Kunden wären vielleicht verärgert, wenn sie wüssten, dass Sie "Zeit verschwenden", um Dinge zu überarbeiten, so dass es hilfreich ist, nicht zu fragen / zu erzählen und wirklich schnell damit umzugehen.

Auf diese Weise entwickelter Code spart Ihnen am Ende viel Zeit und erleichtert das Hinzufügen neuer Funktionen zunehmend.

Ich würde auch sagen, dass einer der Hauptgründe für schlechten Code die Angst einiger Programmierer ist, größere strukturelle Umgestaltungen vorzunehmen, und je länger Sie warten, desto schlimmer wird es.

Verlassen Sie sich auf eine höhere Macht

Ich meine nicht beten. Ich meine, stellen Sie sicher, dass es einen Geschäftsmann (dh einen Projektmanager oder ein gleichwertiges Unternehmen) gibt, den Sie zwischen sich und den Kunden stellen können. Wenn der Kunde zu viel verlangt, lassen Sie den Business-Mann den Fuß runter und seien Sie bereit, das zu tun, aber ich bin nicht sicher, ob das in den Rahmen der Spezifikation passt, siehe [Business-Mann].

In einem normalen Projektablauf sollte die allgemeine Spezifikation eingefroren werden, bevor eine ernsthafte Entwicklung stattfindet.

Viele Kunden werden weiterhin nach Änderungen / Verbesserungen / Erweiterungen streben, solange Sie dies zulassen. Viele werden diese Fähigkeit maximal ausnutzen, weil sie das Gefühl haben, für ihr Geld das Beste zu bekommen (auch wenn es Ihr Projekt sabotiert).

Lassen Sie die Spezifikation frühzeitig perfektionieren und einfrieren und später durchsetzen.

Es ist nichts Falsches daran, ein bisschen mehr für ein gutes Karma mit dem Kunden zu tun, aber seien Sie bereit, auf eine höhere Macht zu verzichten, wenn sie außer Kontrolle geraten. Wenn die Spezifikation eine lächerliche Menge an Änderungen erfordert, ist es möglicherweise an der Zeit, die Geschäftsschleife erneut zu durchlaufen und den Vertrag neu zu bewerten und / oder Ergänzungen zum Vertrag hinzuzufügen (mit angemessener Geldentschädigung).

Die Tatsache, dass Sie dieses Problem haben, hat wenig damit zu tun, wie Sie programmieren. Dies ist ein Zeichen dafür, dass Ihr Projektmanager im Projekt nicht voll ausgelastet ist (ob es Ihre Schuld, seine Schuld oder beides ist).

Wie andere in vielen Antworten gesagt haben, ist das Hinzufügen eines Zeitpuffers für Eventualverbindlichkeiten auch für jedes Projekt erforderlich, es muss jedoch festgelegt werden, dass dies hinter verschlossenen Türen entschieden werden muss, bevor die Spezifikation eingefroren und dem Kunden vom PM zugestellt wird.

Das anfängliche ordnungsgemäße Design kann nicht dazu beitragen, das Problem zu vermeiden. Und es ist fast unmöglich (oder sehr, sehr schwer), alle zukünftigen "Vielleicht" -Anforderungen zu berücksichtigen. Nach einiger Zeit wird das Big Re-Factoring eintreffen. Und die beste Lösung ist, alles neu zu schreiben.

In wenigen Worten: Anstatt einen Turm auf den roten Ferrari zu montieren, überdenken Sie die Anforderungen und bauen Sie einen Panzer.

Töte es mit Feuer.

Aka refactor so schnell wie möglich: Wenn beispielsweise hässlicher Code von der Eile nach einer Frist stammt, würde ich nach Ablauf der Frist refactoren, da Sie nicht mehr Funktionen hinzufügen können (oder sollten), bis der vorhandene Code gewartet werden kann, andernfalls Das Debuggen zukünftiger Codes wird dadurch erheblich erschwert.

Schreiben Sie Komponententests für Ihre Projekte, die den aktuellen Status testen und dann überarbeiten, wenn Sie Zeit haben. Auf diese Weise vermeiden Sie, dass Ihr Projekt beschädigt wird, während Sie versuchen, es zu bereinigen.

Einfachste Antwort. Ich würde jegliche Art von Codierung einstellen, bis er eine endgültige Spezifikation für genau das hat, was er / sie ab sofort möchte.

Dann müssen sie diese Liste von Funktionen usw. priorisieren, um zu bestätigen, welche Elemente gerade vorhanden sein müssen und welche später ausgeführt werden können.

Bestimmen Sie anhand Ihrer Erfahrungen, wie viel Zeit / Kosten für die einzelnen Funktionen anfallen, und teilen Sie ihnen dann mit, ob sie dies möchten. Dies kostet x Zeit und Geld.

Wenn Sie sich mit dem großen Verbrechen des Funktionsumfangs auseinandersetzen, werden Sie endlos neue Funktionen hinzufügen, bis nichts jemals erledigt oder so schlecht erledigt wird.

Sagen Sie ihnen, sobald Sie eine endgültige Liste haben, dass Sie zukünftige Änderungen vornehmen werden, wie sie es vorziehen, sich aber auf die Top 15/20 konzentrieren müssen, die sie gerade haben müssen.

Teilen Sie ihnen dann anhand der Zeit bis zur Fertigstellung mit, dass Sie nach der Veröffentlichung der neuen Version offen für Diskussionen / Brainstorming sind.

Sobald eine endgültige Entscheidung getroffen wurde, was für die aktuelle Version zu tun ist, müssen alle Diskussionen / Ideen / Vorschläge zu 100% gestoppt werden.

Wenn er ständig Ideen hat, schreiben Sie diese in die Featureliste der nächsten Version und konzentrieren Sie sich darauf, die wichtigsten Features bereitzustellen, die er sich gerade wünscht.

Wenn sie weiterhin Ihre Zeit verschwenden, ändern Sie Ihre Meinung. Dann würde ich einfach aufhören, an dem Projekt zu arbeiten und an anderen Projekten arbeiten, bis sie ihre Entscheidungen endgültig getroffen haben.

Es ist schwer zu tun, aber das Schleichen des Funktionsumfangs ist so zerstörerisch für Zeit, Energie, Motivation und klares Denken.

Aus projektbezogener Sicht:

Lernen Sie mit Ihrem Team aus dem Code, sehen Sie, was beim nächsten Mal überarbeitet und wiederverwendet werden kann, und trinken Sie ein Bier.

Aus Sicht der Entwicklung:

Erklären Sie geduldig, warum die Entwicklung gestoppt wurde und warum sie nicht fortgesetzt werden kann, bis alle Spezifikationen vorliegen und verstanden wurden. Dann geh ein Bier trinken.

Aus planerischer Sicht:

Fordern Sie alle Spezifikationen im Voraus an und arbeiten Sie mit allen zusammen, um ein klares Verständnis für den Entwicklungspfad zu erlangen. Beziehen Sie Kunden / Stakeholder so eng wie möglich ein, um sicherzustellen, dass alle auf derselben Seite sind. Holen Sie sich später in dieser Nacht alle Biere. Morgen starten Sie das Projekt.