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

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?

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!

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.

• Carl Sagan, Cosmos : http://www.eridanus.info/genesis.html

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.

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.

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ą”.

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.