YAGNI - stosujecie?

Bug jest kiepskim przykładem bo YAGNI w oryginale się odnosi do featurów, czyli rzeczy których implementacja trwa jednak trochę dłużej niż naprawa buga. A bugi zwykle chcemy naprawić jak najszybciej, póki w miarę pamiętamy kontekst w którym on występuję.

Pomijając to, temat jest bardzo ciekawy, jak bardzo wybiegać w przyszłość przy programowaniu.

Jeśli chodzi o bugi to ja bym poprawiał prawie wszystko, jeśli chodzi o design/ficzery/abstrakcję to tu jednak wyznaje agilowe podejście, czy unikanie jak to oni ładnie określają speculative design(próbę przewidzenia przyszłości).

Pytanie trochę zbyt ogólne.
To zależy od wielu czynników - przede wszystkim od dostępnego czasu oraz ilości potrzebnej pracy.
Jeśli naprawienie drugiej usterki to drobiazg, raczej bym od razu to wyczyścił.
Ale w sytuacji, kiedy wymaga to wielu godzin pracy (plus inne niespodzianki, które pewnie wyskoczą w trakcie), a projekt jest "na wczoraj", to jeśli mam pewność, że na chwilę obecną drugi ZONK nie wyskoczy - zostawiłbym. Aczkolwiek cały czas pamiętając, że taka potencjalna słabość istnieje i w wolnej chwili, albo przy kolejnych pracach, będę starał się zarezerwować czas na załatanie.

Jeśli widżę, że jakiś błąd może wystąpić, to przed tym zabezpieczam - jeśli implementacja jest szybka i łatwa. Jeśli nie, to robię oddzielnego taska i informuję zespół o problemie.

Pytanie na dziś - podczas implementacji myślicie dużo o przyszłości czy nie (YAGNI - You ain't gonna need it)?

Np. wykryto bug X, więc go naprawiasz, jednocześnie widzisz że JEST MOŻLIWY w przyszłości bug Y, chociaż według obecnego używania systemu, nie widać buga Y - uwidoczni się on dopiero, jak się doda pewną inną funkcjonalność (nie jest powiedziane czy się doda czy nie)

Co wtedy?

To zależy, czy to jest dużo roboty czy nie i czy jest na to czas czy nie.
Zazwyczaj robimy coś dopiero jak jest na to task.

Fajny temat się tutaj pojawił. Warto jest by znaleźć złoty środek między "programowaniem zachłannym" czyli robimy asap a "arcydziełem sztuki" czy cyzelowaniem nawet najmniejszych detali. Generalnie staram się myśleć o tym jak sprawić, by kod który jest w chwili obecnej był w jak najlepszym stanie - najbardziej czytelny, logicznie uporządkowany, pokryty testami etc. bo założenie jest, że kod jest żywy i ważne jest, by jak najłatwiej (niekoniecznie najszybciej) go sensownie rozwijać. Ostatnio w pracy miałem przypadek który oddaje myśl tej zasady- miałem zaimplementować rozwiązanie, które zadziała dla pewnych kombinacji możliwych przypadków - może być sam przypadek lub jego kombinacja z innym. Póki nie ma kombinacji z trzema czynnikami (przypadek A - przypadek B - przypadek C) nie dodałem takiego kawałka kodu, bo nie jest potrzebny, ale obecny kod jest na tyle sensownie napisany, że gdy przyjdzie prośba od product ownera, by zrobić kombinację trzech przypadków, dodanie tego będzie analogiczne, a co za tym idzie łatwe.
Dostrzegam, że dla pewnego grona programistów YAGNI czy KISS są usprawiedliwieniem "robienia na szybko", a zupełnie nie o to chodzi :)

Edit: Inna sprawa, gdy ktoś np. założył taska, by dodać pole A, a też chcą pole B etc. to wtedy robi się to za jednym zamachem, nie czekając aż wystawią kolejny "tiket". Są różne szkoły i niektórzy opóźniają development innych zespołów tłumacząc się jirą czyt. biurokracją, ale wtedy się przydaje trochę rozsądku i empatii :)

Edit2: Zakładanie, że naprawimy buga dopiero jak poleci na produkcji, bo np. może się trafić race condition to najgorsze możliwe założenie... W tym wypadku trzeba przewidywać zawczasu, bo naprawienie buga, którego się samo stworzyło to żaden powód do dumy.

Raczej nie pamiętam sytuacji, że "błąd będzie możliwy, jak ktoś doda funkcjonalność X" :). Albo jest błąd, albo go nie ma, a jak sytuacja jest wątpliwa, to się siada, dyskutuje i zastanawia przez chwilę.

Trochę inaczej sprawa się ma z nowymi funkcjonalnościami. Czasami jest już jakaś wizja, że chcielibyśmy w przyszłości dodać funkcjonalność X, albo to jest kwestia "kiedy" a nie "czy" dana funkcjonalność się pojawi. Tu zdarza się robić coś pod przyszłość:

1. np. koszt przygotowania kodu pod funkcjonalność X, gdy ten kod dopiero powstaje, jest bardzo niski, a oszczędzi dużo pracy w przyszłości,
2. żeby wprowadzić funkcjonalność X, trzeba najpierw coś zmienić w architekturze. Nie wiemy jeszcze jak dana funkcjonalność będzie wyglądać i kiedy będzie realizowana, ale po prostu najpierw musimy sobie w ogóle odblokować drogę do niej.

Tu się już bazuje na doświadczeniu i "intuicji" :).

Zalezy. Jak zabezpieczneie przed drugim bugiem jest szybkie i wydaje sie realne ze to zaboli w przyszlosci -> naprawiam. Jesli wydaje sie ze zaboli ale jest sporo roboty -> informuje zespol, zglaszam Jire itp.

Za to ze wzgledu na specyfike swojej pracy czesto robie jakies skrypty do mielenia danych, automatyzacji rzeczy itp. To tam przewaznei wg. zasady jak najszybciej, byle dzialalo. (na zasadzie prototypu do wyrzucenia).

Jeśli widzę możliwy bug, to naprawiam go. Bo jeśli coś się może spieprzyć, to na pewno się stanie. YAGNI, jak już było mówione, odnosi się do ficzerów. Często łapię się na tym, że piszę sobie jakąś metodę, której aktualnie nie potrzebuję, ale "na pewno mi się przyda". Jednak staram się tego unikać jak ognia. Nawet jak się złapię na tym, to po prostu wykomentowuję kod i piszę sobie jakieś todo, chociaż nie zawsze. Gotowy projekt powinien być oddany w miarę szybko, na zabawę przyjdzie czas w tzw. "międzyczasie" :) A im lepiej system pisany, tym łatwiej go rozwijać, więc tym więcej zostaje czasu na zabawy później :)

Podsumowując - YAGNI jest dobrym rozwiązaniem. Przekładając to na życie, wyobraź sobie, że mama/żona/kochanka prosi Cię, żebyś obrał ziemniaki. A Ty zaczynasz zmywać, ogarniać podłogi, robisz pranie i na koniec (jak masz jeszcze czas) obierasz ziemniaki. Tak właśnie wygląda życie bez YAGNI :)

Juhas napisał(a):

Jeśli widzę możliwy bug, to naprawiam go. Bo jeśli coś się może spieprzyć, to na pewno się stanie. YAGNI, jak już było mówione, odnosi się do ficzerów. Często łapię się na tym, że piszę sobie jakąś metodę, której aktualnie nie potrzebuję, ale "na pewno mi się przyda". Jednak staram się tego unikać jak ognia. Nawet jak się złapię na tym, to po prostu wykomentowuję kod i piszę sobie jakieś todo, chociaż nie zawsze. Gotowy projekt powinien być oddany w miarę szybko, na zabawę przyjdzie czas w tzw. "międzyczasie" :) A im lepiej system pisany, tym łatwiej go rozwijać, więc tym więcej zostaje czasu na zabawy później :)

Podsumowując - YAGNI jest dobrym rozwiązaniem. Przekładając to na życie, wyobraź sobie, że mama/żona/kochanka prosi Cię, żebyś obrał ziemniaki. A Ty zaczynasz zmywać, ogarniać podłogi, robisz pranie i na koniec (jak masz jeszcze czas) obierasz ziemniaki. Tak właśnie wygląda życie bez YAGNI :)

@Juhas
Hehe no spoko, fajnie piszesz, tylko jedno mnie ciekawi - macie w projekcie zakomentowany kod? Wydaje mi się że to zła praktyka

Juhas napisał(a):

Podsumowując - YAGNI jest dobrym rozwiązaniem. Przekładając to na życie, wyobraź sobie, że mama/żona/kochanka prosi Cię, żebyś obrał ziemniaki. A Ty zaczynasz zmywać, ogarniać podłogi, robisz pranie i na koniec (jak masz jeszcze czas) obierasz ziemniaki. Tak właśnie wygląda życie bez YAGNI :)

Rozszerzając analogię na bugi -- ale jak masz obrać ziemniaki i nóż jest tępy, to jednak go najpierw ostrzysz. Ale tylko ten, co Ci akurat potrzebny... :)

Ja pracuję głównie w przetwarzaniu tekstu naturalnego, i żeby nie było za prosto - w języku polskim. Jeśli chciałabym się zasadzić na wszystkie możliwe błędy, to nigdy bym nie wydała nowej wersji ;)
Jeśli mam dokładny opis wymagania, gdzie ktoś niby zrobił analizę i twierdzi, że słowa występują w jakimś konkretnym schemacie i ja mam coś z tego wywnioskować, to ja już nie powtarzam analizy, tylko programuję, co mi zadano i przekazuję do testów. Wtedy zazwyczaj wychodzi na jaw, że język polski jest zaskakujący i zadanie wraca do mnie z dodatkową analizą. Często już oddając do testów dobrze wiem, że zadanie wróci, albo że nie obsłużyliśmy pewnych skrajnych przypadków. Mimo to przekazuję, bo:

1. analityk też musi przecież coś robić, jeśli ja mam i implementować, i analizować, to ja poproszę pensję analitykę dodatkowo do mojej...
2. bez przykładu na żywo zazwyczaj nie idzie przetłumaczyć,
3. skrajne przypadki występują tak rzadko, że decyzją biznesową jest niemarnowanie mojego czasu na ich obsługę (redaktor robiący korektę ręczną jest tańszy).