Czy jest to teraz proste, czy programować z myślą o przyszłości?

21

Obecnie koduję nową aplikację dla mojej firmy, która jest raczej zaangażowana. Aby dotrzymać terminu, funkcjonalność została nieco stonowana, dzięki czemu możemy mieć coś gotowego do uruchomienia.

Zadanie polegające na uruchomieniu wersji 1 do końca miesiąca. Jestem w połowie rozwoju i doszedłem do tego, że nadciąga koniec.

Wczoraj spędziłem trochę czasu na wymyśleniu bardzo fajnego, łatwego rozwiązania dla jednego z wymagań i jestem dość dumny z tego, jak się okazało. Dziś rano wysłano dokument w wersji 2 i istnieje tam wymóg, który wymaga, aby kod, który napisałem wczoraj, był wypatroszony lub poważnie zmieniony. Wymagałoby to dużo pracy w przyszłości, jeśli zostawię to tak, jak jest. Mogę poświęcić dodatkowy dzień, aby moje obecne rozwiązanie było bardziej niezawodne, dzięki czemu funkcja v2 będzie mogła zostać dodana przy znacznie mniejszym wysiłku, ale to trochę mnie opóźni w kwestii dodatkowego kodowania, którego wymagałoby.

Nie wiem czy będę robił v2. Może to być ja, współpracownik lub stażysta.

Gdybyś był w moich butach, czy spędziłbyś teraz czas, aby ułatwić to w przyszłości, czy zostawiłbyś swoje rozwiązanie i zajął się nim, gdy nadejdzie czas?

Tyanna
źródło
Poniższy link był dla mnie przydatny: elegantcode.com/2012/01/16/marines-vs-boy-scouts
QuanhD

Odpowiedzi:

18

Jeśli termin jest wyrzeźbiony w kamieniu, po prostu dokończ to, co musisz, aby go dotrzymać. Upewnij się, że zawyżasz prognozy dla wersji 2, aby dostosować się do zmian kodu dla nowego wymagania. Pamiętaj też, aby krótko udokumentować, co Twoim zdaniem będzie wymagało zmiany w nowych funkcjach v2, aby współpracownik mógł je odebrać, jeśli zostaniesz przeniesiony do czegoś innego.

Jeśli termin jest wystarczająco elastyczny (1 dzień, na podstawie jego brzmienia, więc staraj się przedłużyć go o 2,5 dnia), to śmiało i napisz kod dla znanej przyszłości!

FrustratedWithFormsDesigner
źródło
1
+1 za sugestię udokumentowania bardziej niezawodnego rozwiązania. Ta funkcja może, ale nie musi zostać zaimplementowana dokładnie tak, jak zaplanowałeś, ale zdecydowanie dobrym pomysłem jest poinformowanie przyszłego implementatora o swoich przemyśleniach na temat zmian.
Mike Partridge
2
Dzisiaj po przeczytaniu dokumentu zacząłem pisać kody pośredniczące dla oczekiwań v2. Myślę, że zostawię to przy tym i kilka komentarzy, aby powiedzieć, jak będą grać w przyszłości. Dzięki :)
Tyanna,
1
Miej oko na piłkę ... moje doświadczenie jest złe, że martwisz się czymkolwiek związanym z V2, gdy masz termin V1, który uderzy cię między oczy. Jeśli jest elastyczny, to nie jest Termin. Jeśli program nie dotrzyma terminu, jest to wina programistów.
mattnz
13

Unikaj padania ofiarą (wcześnie) na efekt drugiego systemu . Oto kilka dobrych technik do zastosowania:

  1. Zdecydowanie unikaj usuwania szyn w wersji 1 tylko z powodu tego, co zobaczysz w wersji 2. Planowanie jest w porządku, ale twórca specyfikacji v2 powinien być odpowiedzialny za awarię v2, a nie v1.
  2. (Jeśli to możliwe) sprawdź, czy możesz sprawić, by twórca przerobił wymagania dla wersji 2, która nie będzie wymagać teraz większych zmian - a następnie zaplanuj je później, być może dla wersji 3.
  3. Pamiętaj o YAGNI , ale staraj się kodować w celu rozszerzenia - unikaj magicznych liczb, wartości zakodowanych na stałe , pisz dobre testy jednostkowe lub umowy kodu itp. Wcześniejsze zastosowanie dobrych technik sprawi, że refaktoryzacja i zmiany kodu będą mniej bolesne po drodze.

Większość projektów oprogramowania, które rosną jak miasta, odnosi sukces na dłuższą metę. Ewolucyjne planowanie tylko w ograniczonej przyszłości pozwala na wydanie oprogramowania na czas oraz z funkcjami wymaganymi w momencie wydania - i nie więcej. Zobacz ten fragment Carl Sagan:

Układ [miasta] mógłby być bardziej wydajny, gdyby wszystkie systemy obywatelskie były budowane równolegle i okresowo wymieniane (dlatego właśnie katastrofalne pożary - na przykład wielkie pożary Londynu i Chicago - czasem pomagają w planowaniu miasta). Ale powolny rozwój nowych funkcji pozwala miastu na mniej więcej ciągłą pracę przez stulecia.

Kevin McCormick
źródło
Podoba mi się pomysł rozmowy z projektantem i kierownictwem, aby sprawdzić, czy są związani z tą funkcją. Widzę to bardziej jako bezużyteczny dzwonek, który spowoduje więcej pracy niż jest wart ... ale wtedy jestem zestresowanym bankomatem. :)
Tyanna,
2
+1: Unikaj prób przewidywania przyszłości. Kiedy nadejdzie, będzie zaskakujące.
S.Lott,
7

Nie dodawaj dzisiaj kodu do wymagań na następny miesiąc. Dzisiaj powinieneś napisać najczystszy kod, jaki możesz, dla swoich wymagań. Jestem sceptyczny, że dzień pracy pozwoli zaoszczędzić wiele dni później. Słyszałem takie twierdzenia i nie mogę sobie przypomnieć ani jednego przypadku, w którym było to prawdą. Możesz mnie przekonać, pokazując kod, ale z mojego doświadczenia wynika, że ​​jest to mało prawdopodobne.

Kevin Cline
źródło
To prawda, ale jest to prawdą tylko wtedy, gdy masz czas z wyprzedzeniem, aby bardzo dokładnie ją zaplanować i masz niezbędną wiedzę biznesową, aby przewidzieć naturę różnych zmian. Biorąc jednak pod uwagę większość sytuacji biznesowych (teraz taniej, mniej) zgadzam się całkowicie z twoimi stwierdzeniami. Mam jednak kilka przykładów, jeśli jesteś prawdziwym niewierzącym :)
Joel Etherton
@JeelEtherton: Nawet jeśli masz wiedzę biznesową, przewidywanie zmian jest bardzo trudne, do tego stopnia, że ​​często nie warto próbować ... tylko moje doświadczenie.
śleske,
@sleske: Czasami być może, ale moje doświadczenie było w obu kierunkach. W mojej obecnej pracy dobre planowanie i przewidywanie pozwoliły mi zaoszczędzić mnóstwo dodatkowych bólów głowy.
Joel Etherton,
6

Pozostaw tak, jak jest.

Programiści faktycznie doceniają starszy projekt, który robi to, co powinien, i nie więcej.

To, co dziś może wydawać się dobrym pomysłem na „umieszczenie” bazy kodu w celu spełnienia wymogu „przyszłego”, najprawdopodobniej będzie przeszkodą w zrozumieniu kodu w przyszłości. Nikt nie lubi zajmować się częściowo wdrożoną funkcjonalnością i śladami zapomnianych wymagań fantomowych. Nie twierdzę, że tak się stanie, ale rzeczy często okazują się takie, pomimo najlepszych intencji.

Angelo
źródło
+1 za „brak funkcjonalności zaimplementowanej w połowie”. Chciałbym móc głosować więcej.
śleske,
1

Dobre odpowiedzi Chciałbym tylko dodać - to, co robię w takim przypadku, to zrobienie dobrego porównania, dzięki czemu mogę uchwycić to, co zrobiłem, i schować to w bezpiecznym miejscu. Jeśli nadarzy się okazja, aby zrobić to ponownie w następnej wersji, będzie to łatwe.

Ogólnie rzecz biorąc, dobry programista przewiduje przyszłe wymagania, ale gdy zbliża się termin, nadszedł czas, aby odpowiedzieć na błędy w tym, co już masz, a nie „wstrząsnąć łodzią”.

Mike Dunlavey
źródło
Dobry pomysł na oddzielne wprowadzanie zmian. Zamiast różnicy gałąź jest prawdopodobnie lepszym pomysłem (widocznym, łatwiejszym do scalenia itp.). Zawsze możesz go później usunąć.
sleske,
1

To zależy. Istnieje dobra, staromodna zasada: traktuj innych ludzi tak, jak sam chcesz być traktowany. Co byś zrobił, gdyby to był twój własny projekt i znasz wszystkie priorytety?

Jeśli wersja 2 jest zdecydowanie wymagana, a termin jest tylko życzeniem, a nie trudną koniecznością, to nie twórz technicznych długów i nie naprawiaj swoich żagli, gdy pogoda jest ładna. Nawet jeśli ktoś zrobi v2, doceni foresight.

Jeśli są wątpliwości co do konieczności v2, trzymaj się YAGNI. Również jeśli jesteś po drugiej stronie spektrum i masz jednego z tych klientów, którzy stale spamują Cię swoimi pomysłami przed ich utworzeniem, sprawdzaj swoje wiadomości e-mail tylko 2-3 razy dziennie i nie spiesz się z akcją, będziesz zaskoczony ile „problemów” i próśb staje się nieistotnych, zanim je przeczytasz.

KolA
źródło