it-swarm-eu.dev

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

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 fleißig wie ein guter kleiner Junge. Außer ... die neuen Funktionen stehen in Konflikt mit den alten Funktionen, sodass Ihr Code jetzt ein Chaos ist. Sie wirklich möchten zurückgehen und es reparieren, aber er fordert immer wieder neue Dinge an und jedes Mal, wenn Sie mit der Reinigung fertig sind, kommt es wieder zu einem Durcheinander.

Wie geht's? Hören Sie auf, ein OCD-Verrückter zu sein, und akzeptieren Sie einfach, dass Ihr Code, egal was Sie tun, ein Chaos verursachen wird, und setzen Sie einfach weiter auf Funktionen für diese Monstrosität? Reinigung für Version 2 speichern?

89
mpen

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

..... .....

Nur ein Scherz. :) :)

Aber im Ernst: Schätzungsauffüllung ist dein Freund. Ich mache im Allgemeinen eine anständige realistische Schätzung und verdopple sie dann. Das mag übertrieben klingen, und manchmal ist es das auch, aber es ist besser, ein bisschen zu überschätzen und manchmal sogar ein bisschen langsam auszusehen - als schlechte Eindrücke zu hinterlassen, indem Sie fehlerhaften Code herausbringen und immer Ihre Schätzungen in die Luft jagen. Und natürlich entstehen Ihnen technische Schulden, indem Sie die Codebasis hackig werden lassen.

Ein weiterer (verwandter) Tipp: Schätzen Sie immer scheinbar winzige, unkomplizierte Aufgaben auf einen Block mit anständiger Größe. Nehmen wir zum Beispiel an - ein Element, von dem Sie fast sicher sind, dass es sich nur um eine einfache 30-Sekunden-Änderung in einer Zeile handelt - geben Sie ihm 1 Stunde (oder was auch immer der niedrigste Zeitblock auf Ihrer Arbeitszeittabelle oder Ihrem CR-System ist, z. B. 15 Minuten/0,25 Stunden). . Und geben Sie Halbtages- oder 1-Tagesblöcke für die etwas größeren, aber immer noch relativ trivialen Gegenstände.

Der Grund dafür ist hauptsächlich psychologischer Natur: Ich finde, wenn Sie sich angewöhnen, kleine Änderungen schnell zu hacken, fühlt sich die Arbeit gehetzt an, und Sie lehnen sich nie zurück, ziehen Bilanz und überarbeiten Dinge, die überarbeitet werden müssen. Auch auf praktischer Ebene: Kleine, aber nicht triviale Änderungen treten manchmal auf, 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 mit der Zeit hackig 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 anständigen Tempo erledigen, wird diese Polsterung nicht spürbar sein. dh Sag dem PHB nicht "Meine anfängliche Schätzung ist, dass es zwei Stunden dauern wird, aber gib mir einen halben Tag". Sagen Sie ihm einfach: "Ich denke, es wird ungefähr einen halben Tag dauern." und lass es dort.

41
Bobby Tables

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

Sie werden die Wartung niemals rechtfertigen können, und der Kunde benötigt sie trotzdem. Geben Sie ihm daher die bittere Medizin (leicht erhöhte Kosten für die nächsten Funktionen), damit er besser wird.

66
Frank Shearar

Versuchen Sie, das richtige Design zu erstellen, während Sie neue Funktionen integrieren. Es gibt kein späteres. Ohne das Redesign fügen Sie immer mehr Reibung für weitere Änderungen und neue Funktionen hinzu.

Irgendwann kommen Sie fast zum Stillstand, wo alles ewig zu dauern scheint. Die meisten Unternehmen entscheiden sich wahrscheinlich zu diesem Zeitpunkt für das große Umschreiben, Version 2. Es hat eine ziemlich schlechte Wirtschaftlichkeit und ist ein guter Moment für Ihren Kunden, eine andere Entwicklungspartei auszuprobieren, wenn er Lust dazu hat.

Eine ordnungsgemäße Neugestaltung/Umgestaltung kann die Investition Ihrer Kunden schützen und die Dinge nachhaltig halten. Sie müssen dies einbauen. Optimieren Sie für Änderungen, reisen Sie leicht.

11
Joppe

Bei all den Kommentaren zur Überschätzung denke ich, dass eine bescheidene Menge an Punkten (gute 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 (Refactor!) Zu ändern, um ihn an einen Punkt zu bringen, an dem die Änderung sicher vorgenommen werden kann, und um dann die Änderung vorzunehmen ändern (wahrscheinlich etwas zusammengemischt). Ok, das ist das Gleiche ... aber es gibt keine Frage des Fudgens oder Dehnens oder Überschätzens. Es geht einfach darum zu sagen, dass ich das zuerst tun muss, und so lange wird es dauern insgesamt. Der Schlüssel hier ist, dass Sie an den Teilen des Systems arbeiten, von denen die Änderung abhängig ist, und nicht mehr - wenn es anderswo schrecklichen Code gibt ... hart, fangen Sie ihn, wenn Sie dort sind.

Um ein wenig 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 (verdächtigen?), Nicht denken aber wissen) dass zusätzliche Dinge auch erforderlich sind, dann sollten Sie tun, was Sie brauchen, um diese Anforderung umzusetzen, und nicht mehr so ​​ordentlich und elegant wie möglich.

Wenn Sie das nächste Mal - einige Zeit später - implementieren, führen Sie die erforderlichen Schritte aus, um die Codebasis (und die Datenbank und was auch immer) in den Zustand zu versetzen, der erforderlich ist, um diese Funktionalität so ordentlich und elegant wie möglich zu implementieren. Bei diesem Refactoring beschäftigen Sie sich mit dem Durcheinander, das bei der Entwicklung eines Projekts auf natürliche Weise entsteht - und vermeiden hoffentlich, mehr Durcheinander zu verursachen (oder zumindest das Niveau konsistent zu halten).

Einer der Diskussionsbereiche hier ist "Technische Schulden" - es ist wie ein Überziehungskredit, Sie müssen ihn zurückzahlen und je länger Sie ihn verlassen, desto mehr Zinsen (in diesem Fall zur Korrektur erforderliche Zeit) fallen an - was Ihnen einen Vorteil bringt Argument dafür, einen Teil Ihrer Zeit damit zu verbringen, die technische Verschuldung zu minimieren.

Hier kommen auch Unit-Tests und andere automatisierte Tests ins Spiel (wenn ich es so gut machen könnte, wie ich sage, ich bin mir ziemlich sicher, dass ich eine glücklichere Person wäre!), Kombiniert mit einem geeigneten Build-Server (der zumindest einige ausführen kann 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 es einfacher machen, die Installation zu ändern und damit mit Änderungen in umzugehen Isolation.

Zuletzt - denken Sie daran, wenn es nicht kaputt ist, reparieren Sie es nicht. Das Aufräumen Ihres Codes nur, um ihn aufzuräumen kann ist zufriedenstellend, aber es ist auch eine Gelegenheit, Fehler einzuführen, während es schmerzhaft sein kann, wenn Sie ihn nicht ändern müssen und nicht darauf aufbauen Vielleicht ist es besser, einige Klumpen in Ruhe zu lassen - die Möglichkeit zum Reparieren oder Ersetzen wird sich irgendwann ergeben!

6
Murph

1) Die 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 Kunde kann sich über scheinbar hohe Kosten lustig machen, aber an diesem Punkt müssen Sie ihm erklären, dass, da der Code bereits zur Hälfte geschrieben ist, Elemente neu geschrieben werden müssen, um sicherzustellen, dass er in Zukunft robust und unterstützbar ist Wenn dies nicht getan wird, hat er wahrscheinlich Probleme mit der zukünftigen Unterstützung oder Änderungen, die noch teurer werden.

2) Refactoring sollte so durchgeführt werden, dass dem Kunden ein echter langfristiger Nutzen geboten wird

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

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 Streben nach theoretischer Perfektion. Refactoring-Arbeiten (und die entsprechenden Schätzungen) sollten mit diesem Umfang durchgeführt werden, und zwar nicht nur, weil Sie jetzt glauben, dass es einen etwas besseren Weg gibt, dies zu tun.

4
Jon Hopkins

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

3
Jas

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. Was ich tue, ist (mein Bestes) zu warten, bis sich die Dinge beruhigt haben und jede Art von "Kriechen" alles "eingeschlichen" hat, was es tun wird. Zu diesem Zeitpunkt haben Sie wahrscheinlich etwas brauchbares veröffentlicht, und Sie können sich etwas Zeit nehmen, um Dinge zu bereinigen und Dinge etwas anders zu implementieren.

Sie können nicht herumlaufen und viele kleine Unordnung wiederholt aufräumen. Das verdreifacht nur deine Arbeit und deine Frustration. Warten Sie, bis es ein größeres, aber kaum bewegendes Durcheinander wird, und dann können Sie etwas dagegen tun.

3
Tim Post

Ich bevorzuge es, diese Situation überhaupt zu vermeiden.

Es hängt alles davon ab, wie Sie die Spezifikation lesen. Es ist leicht, sie als Steintafeln zu betrachten, aber in Wirklichkeit ändern sich die meisten Spezifikationen. Sehen Sie sich beim Entwerfen Ihres Codes an, wie wahrscheinlich es ist, dass sich jeder Teil der Spezifikation ändert. Mit der Zeit werden Sie dies ziemlich gut vorhersagen können.

Erfahrung und Urteilsvermögen sind sehr wichtig. Schreiben Sie aufgrund dieses Spaghetti-Codes neue Fehler? dauert die Implementierung länger? diese würden auf einen taktischen Refaktor hinweisen.

für die Zukunft klingt es so, als müssten Sie mit Ihrem Kunden zusammenarbeiten. Wenn Sie zu ihnen sagen: "Schauen Sie, dieses Produkt wird deutlich über die ursprüngliche Spezifikation hinaus erweitert. Während das ursprüngliche Design für dieses Niveau gut war, muss es in Richtung X und Richtung Y erweitert werden." Kunde dafür zu bezahlen.

2
Michael Shaw

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. Das Sparen von Zeit könnte Sie später kosten.

2
Craig

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 und jeden Tag neue Eingaben eingehen), müssen Sie sich keine Gedanken über die Wartbarkeit des Codes und andere Dinge machen - Zeit ist entscheidend und Sie müssen es nur tun Schieben Sie Ihren Code so schnell wie möglich aus der Tür.

Wenn Sie jedoch eine Langzeit-App schreiben, ist es sinnvoll, all dies zu berücksichtigen, da sich dies erheblich darauf auswirkt, wie lange es dauert, neue Funktionen zu erstellen, vorhandene Fehler zu beheben, in andere Anwendungen und andere Dinge zu integrieren - und Dies führt zu geschäftlichen Auswirkungen (aufgrund des späteren Zeitaufwands und der höheren Kosten).

Daher ist es besser, den Entscheidungsträger für die tatsächlichen Kosten zu sensibilisieren, wenn Code nicht überarbeitet wird, wenn dies erforderlich ist. Nach meiner Erfahrung kann die Entscheidung a sein, wenn die Kosten- und Zeitauswirkungen beider Optionen dem Entscheidungsträger messbar erklärt werden Klacks. Erwarten Sie nicht, dass die Leute Ihnen sagen: "Ja, schreiben Sie schönen Code, obwohl er doppelt so lange dauert und mir keinen zusätzlichen Nutzen bringt." Das funktioniert einfach nicht so.

1
Roopesh Shenoy

Machen Sie es zu einem Teil Ihres Prozesses, ich nenne es "extremes Refactoring" und es wird groß! ;) Mach einfach schnell und wenn genug neue Funktionen hinzugefügt wurden, dass Narbengewebe vorhanden ist, überarbeite es. Fragen Sie sich immer wieder: "Wenn ich von vorne angefangen hätte, wie hätte ich das gemacht?"

Menschen, die glauben, sie könnten alles von vornherein entwerfen und darüber nachdenken, täuschen sich meistens selbst. Sie (und Ihr Kunde) lernen immer Dinge, während Sie fortfahren. Verwenden Sie diese Lektionen.

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

Kunden könnten verärgert sein, wenn sie wüssten, dass Sie "Zeit verschwenden", um Dinge zu überarbeiten, so dass es hilft, nicht zu fragen/zu erzählen und wirklich schnell darüber zu sein.

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 vor größeren strukturellen Umgestaltungen ist. Je länger Sie warten, desto schlimmer wird es.

1
Homde

Verlasse dich auf eine höhere Kraft

Ich meine nicht beten. Ich meine, stellen Sie sicher, dass es einen Geschäftsmann gibt (z. B. einen Projektmanager oder einen gleichwertigen Mitarbeiter), den Sie als Polster zwischen Ihnen und dem Kunden platzieren können. Wenn der Kunde zu viel verlangt, lassen Sie den Geschäftsmann den Fuß runter und seien Sie bereit, das "es ist machbar, aber ich bin nicht sicher, ob das in den Geltungsbereich der Spezifikation passt, siehe [Geschäftsmann]".

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

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

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

Es ist nichts Falsches daran, ein bisschen mehr für ein wenig gutes Karma mit dem Klienten zu tun, aber seien Sie bereit, sich einer höheren Macht zu unterwerfen, wenn er außer Kontrolle gerät. 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 codieren. Dies ist ein Zeichen dafür, dass Ihr Projektmanager für das Projekt nicht ausreichend ausgelastet ist (ob es Ihre Schuld, seine Schuld oder beides ist).

Wie andere in vielen Antworten gesagt haben, ist es auch für jedes Projekt erforderlich, einen Zeitpuffer für Eventualverbindlichkeiten hinzuzufügen. Die Entscheidung sollte jedoch hinter verschlossenen Türen getroffen werden, bevor die Spezifikation eingefroren und vom PM an den Kunden geliefert wird.

1
Evan Plaice

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 will.

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.

Verwenden Sie Ihre Erfahrungen, um die Zeit/Kosten der einzelnen Funktionen zu bestimmen, und sagen Sie ihnen dann, wenn sie dies möchten, wird es x Zeit und Geld kosten.

Ihr Umgang mit dem großen Verbrechen des Feature-Scope-Creep, und sie werden endlos Features hinzufügen, bis nichts mehr 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 bevorzugen, sich aber auf die Top 15/20 konzentrieren müssen, die sie jetzt haben müssen.

Sagen Sie ihnen dann basierend auf der Zeit bis zur Fertigstellung, dass Sie nach der Veröffentlichung offen sind, die nächste Version zu diskutieren/Brainstorming zu betreiben.

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 die Ideen endlos bekommt, fordern Sie ihn auf, sie in die Funktionsliste für die nächste Version einzutragen, und Sie können sich darauf konzentrieren, die wichtigsten Funktionen bereitzustellen, die er gerade benötigt.

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 abgeschlossen haben.

Es ist schwer zu tun, aber das Kriechen des Funktionsumfangs zerstört Zeit, Energie, Motivation und klares Denken.

0
crosenblum

Aus Projektperspektive :

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

Aus entwicklungspolitischer Sicht :

Erklären Sie geduldig, warum die Entwicklung gestoppt wurde, und erklären Sie, warum sie erst fortgesetzt werden kann, wenn 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 des Entwicklungspfads zu erhalten. 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. Starten Sie morgen das Projekt.

0
Kevin

Töte es mit Feuer.

Aka-Refactor so schnell wie möglich: Wenn beispielsweise hässlicher Code durch das Anstürmen einer Frist entsteht, würde ich nach Ablauf der Frist eine Umgestaltung vornehmen, da Sie keine weiteren Funktionen hinzufügen können (oder sollten), bis der vorhandene Code andernfalls gewartet werden kann Es wird das Debuggen zukünftiger Codes erheblich erschweren.

0
wildpeaks

Das anfängliche richtige Design kann nicht helfen, 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.

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

0
duros

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

0
chiurox