Halten Sie es jetzt einfach oder programmieren Sie mit Blick auf die Zukunft?


21

Ich programmiere derzeit eine neue Anwendung für mein Unternehmen, die eher involviert ist. Um die Frist einzuhalten, wurde die Funktionalität erheblich reduziert, damit wir etwas für den Start bereithalten können.

Ich habe die Aufgabe, Version 1 bis Ende des Monats zum Laufen zu bringen. Ich bin ungefähr zur Hälfte in der Entwicklung und jetzt an dem Punkt angelangt, an dem ein Ende in Sicht ist.

Gestern habe ich einige Zeit damit verbracht, eine sehr schöne und einfache Lösung für eine der Anforderungen zu finden, und bin ziemlich stolz darauf, wie es ausgegangen ist. Heute Morgen wurde das Dokument der Version 2 verschickt, und es gibt eine Anforderung, die erfordert, dass der Code, den ich gestern geschrieben habe, entweder ausgeweidet oder stark geändert wird. Es würde in Zukunft viel Arbeit erfordern, wenn ich es so lasse, wie es ist. Ich kann jetzt einen zusätzlichen Tag in Anspruch nehmen, um meine aktuelle Lösung robuster zu machen, damit die v2-Funktion mit viel weniger Aufwand hinzugefügt werden kann, aber das wird mich ein bisschen in Verzug bringen, was die zusätzliche Codierung angeht, die erforderlich wäre.

Ich weiß nicht, ob ich v2 machen werde. Es könnte ich sein oder es könnte ein Mitarbeiter oder sogar ein Praktikant sein.

Wenn Sie in meinen Schuhen wären, würden Sie jetzt die Zeit verbringen, um es in Zukunft einfacher zu machen, oder würden Sie Ihre Lösung verlassen und sich zu gegebener Zeit damit befassen?



Der folgende Link war nützlich für mich: elegantcode.com/2012/01/16/marines-vs-boy-scouts
QuanhD

Antworten:


18

Wenn die Frist In Stein gemeißelt ist, beenden Sie einfach, was Sie müssen, um es zu erfüllen. Stellen Sie sicher, dass Sie die Schätzungen für Version 2 aufblasen, um den Codeänderungen für die neue Anforderung Rechnung zu tragen. Stellen Sie außerdem sicher, dass Sie kurz dokumentieren, was Ihrer Meinung nach für die neuen v2-Funktionen geändert werden muss, damit ein Mitarbeiter es abholen kann, wenn Sie einer anderen Aufgabe zugewiesen sind.

Wenn die Frist flexibel genug ist (1 Tag, nach dem Klang der Zeit, also eine Verlängerung um 2,5 Tage anstreben), können Sie sicher sein, dass Sie für die bekannte Zukunft programmieren!


1
+1 für den Vorschlag, die robustere Lösung zu dokumentieren. Die Funktion kann genau so implementiert werden oder auch nicht, wie Sie es geplant haben. Es ist jedoch auf jeden Fall eine gute Idee, den zukünftigen Implementierer über Ihre Gedanken zu den Änderungen zu informieren.
Mike Partridge

2
Ich habe heute Morgen nach dem Lesen des Dokuments angefangen, die Methodenstubs für die Antizipation von Version 2 zu schreiben. Ich denke, ich lasse es dabei und einige Kommentare, um zu sagen, wie diese in Zukunft spielen werden. Danke :)
Tyanna

1
Behalte den Ball im Auge ... meiner Erfahrung nach ist es eine schlechte Sache, sich mit irgendetwas zu befassen, was mit V2 zu tun hat, wenn die V1-Frist kurz davor ist, dich zwischen die Augen zu schlagen. Wenn es flexibel ist, ist es keine Frist. Wenn eine Entwicklung eine Deadline verfehlt, ist dies die Schuld des Entwicklers.
Mattnz

13

Vermeiden Sie es, dem zweiten Systemeffekt (früh) zum Opfer zu fallen . Hier sind einige gute Techniken zum Anwenden:

  1. Vermeiden Sie auf jeden Fall das De-Railing von Version 1, nur weil es in Version 2 angezeigt wird. Vorausplanung ist in Ordnung, aber der Ersteller der v2-Spezifikationen sollte für den Ausfall von v2 und nicht von v1 verantwortlich sein.
  2. (Wenn möglich) Prüfen Sie, ob der Ersteller die Anforderungen für Version 2 überarbeiten kann, für die jetzt keine größeren Änderungen erforderlich sind. Planen Sie sie später, möglicherweise für Version 3.
  3. Behalten Sie YAGNI im Hinterkopf, aber versuchen Sie, die Erweiterbarkeit zu berücksichtigen - vermeiden Sie magische Zahlen, hartcodierte Werte, schreiben Sie gute Komponententests oder Codeverträge usw. Wenn Sie frühzeitig gute Techniken anwenden, werden Refactoring und Codeänderungen weniger schmerzhaft.

Die meisten Softwareprojekte, die wie Städte wachsen, sind langfristig erfolgreich. Durch die evolutionäre Planung nur für die begrenzte Zukunft kann Ihre Software pünktlich und mit den bei der Veröffentlichung erforderlichen Funktionen veröffentlicht werden - und nicht mehr. Sehen Sie diesen Auszug aus Carl Sagan:

Die Anordnung einer Stadt könnte effizienter sein, wenn alle bürgerschaftlichen Systeme parallel aufgebaut und regelmäßig ausgetauscht würden (weshalb katastrophale Brände - zum Beispiel die großen Großbrände von London und Chicago - manchmal eine Hilfe bei der Stadtplanung darstellen). Das langsame Anwachsen neuer Funktionen ermöglicht es der Stadt jedoch, im Laufe der Jahrhunderte mehr oder weniger kontinuierlich zu arbeiten.


Ich mag die Idee, mit dem Designer und dem Management zu sprechen, um zu sehen, ob sie mit diesem Feature verheiratet sind. Ich sehe es eher als nutzlose Glocke, die mehr Arbeit verursacht als es wert ist ... aber dann bin ich ein gestresster Entwickler. :)
Tyanna

2
+1: Versuchen Sie nicht, die Zukunft vorherzusagen. Wenn es ankommt, wird es überraschen.
S.Lott

7

Fügen Sie heute keinen Code für die Anforderungen des nächsten Monats hinzu. Heute sollten Sie den saubersten Code für Ihre Anforderungen schreiben. Ich bin skeptisch, dass ein Tag Arbeit mehrere Tage später sparen wird. Ich habe solche Behauptungen gehört und kann mich an keinen einzigen Fall erinnern, in dem dies der Fall war. Sie können mich vielleicht überzeugen, indem Sie Code anzeigen, aber meiner Erfahrung nach ist dies unwahrscheinlich.


Es ist wahr, aber es ist nur wahr, wenn Sie die Zeit haben, es im Voraus sehr gründlich zu planen, und Sie über die erforderlichen Geschäftskenntnisse verfügen, um die Art der verschiedenen Änderungen zu antizipieren. In Anbetracht der meisten Geschäftssituationen (jetzt billiger, kleiner) stimme ich Ihren Aussagen vollkommen zu. Ich habe jedoch einige Beispiele, wenn Sie ein wahrer Ungläubiger sind :)
Joel Etherton

@JoelEtherton: Selbst wenn Sie über geschäftliche Kenntnisse verfügen, ist es sehr schwierig, Änderungen zu antizipieren, bis zu dem Punkt, dass es sich oftmals nicht lohnt, sie auszuprobieren ... nur meine Erfahrung.
sleske

@sleske: Manchmal vielleicht, aber meine Erfahrung war in beide Richtungen. Gute Planung und Weitsicht haben mir bei meiner jetzigen Arbeit eine Menge zusätzlicher Kopfschmerzen erspart.
Joel Etherton

6

Lass es so wie es ist.

Entwickler schätzen tatsächlich ein Legacy-Projekt, das tut, was es tun soll und nicht mehr.

Was heute als eine gute Idee für die "Inszenierung" der Codebasis zur Erfüllung einer "zukünftigen" Anforderung erscheinen mag, wird höchstwahrscheinlich ein Hindernis für das Verständnis des Codes in der Zukunft sein. Niemand befasst sich gerne mit teilweise implementierten Funktionen und Spuren vergessener Phantomanforderungen. Ich sage nicht, dass das der Fall sein wird, aber die Dinge laufen trotz der besten Absichten oft so.


+1 für "keine halb implementierte Funktionalität". Ich wünschte, ich könnte mehr dafür stimmen.
sleske

1

Gute Antworten. Ich würde nur hinzufügen - was ich in einem Fall wie diesem tue, ist, ein gutes Diff zu nehmen, damit ich erfassen kann, was ich getan habe, und es an einem sicheren Ort wegschneiden kann. Wenn sich die Gelegenheit bietet, es in der nächsten Version erneut zu tun, wird es einfach.

Im Allgemeinen nimmt ein guter Entwickler zukünftige Anforderungen vorweg, aber wenn sich eine Frist abzeichnet, ist es an der Zeit, auf Fehler in dem zu reagieren, was Sie bereits haben, und das Boot nicht zu "rocken".


Gute Idee, Änderungen getrennt zu halten. Anstelle eines Diffs ist eine Verzweigung wahrscheinlich eine bessere Idee (sichtbar, einfacher zusammenzuführen usw.). Sie können es später jederzeit löschen.
sleske

1

Es hängt davon ab, ob. Es gibt eine gute altmodische Regel: Behandle andere Menschen so, wie du selbst behandelt werden möchtest. Was würden Sie tun, wenn es Ihr eigenes Projekt wäre und Sie alle Prioritäten kennen würden?

Wenn v2 definitiv benötigt wird und die Frist nur ein Wunsch und keine Notwendigkeit ist, dann schulden Sie sich keine technischen Schulden und flicken Sie Ihre Segel, wenn das Wetter gut ist. Selbst wenn jemand anderes v2 macht, wird er die Weitsicht zu schätzen wissen.

Wenn Zweifel an der Notwendigkeit von v2 bestehen, bleiben Sie bei YAGNI. Auch wenn Sie sich auf der anderen Seite des Spektrums befinden und einen dieser Kunden haben, der Sie ständig mit seinen Ideen spamt, bevor sie sich formieren, dann überprüfen Sie Ihre E-Mails nur zwei- oder dreimal täglich und stürzen sich nicht in Eile. Sie werden überrascht sein Wie viele "Probleme" und Anfragen werden irrelevant, bevor Sie sie überhaupt lesen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.