Jak grają razem „Nie potrzebujesz” i „Teraz jest lepiej niż nigdy”?

17

Często popieram „teraz jest lepiej niż nigdy”, kiedy zwiększam SUSZENIE projektu. Zazwyczaj uważam, że muszę kultywować zrozumienie Jednej Autorytatywnej Lokalizacji dla fragmentu wiedzy w kontekście systemu innych fragmentów wiedzy. Dlatego mam tendencję do projektowania systemu „teraz”.

I odwrotnie, ta praktyka powoduje, że buduję z dużym wyprzedzeniem, pomimo uzasadnionej szansy, że nie będę jej potrzebować.

W jaki sposób te dwa wzory się równają?

Jakie praktyki stosujesz, aby zapewnić, że dobrze się bawią?

Jak uczysz ich razem bez powodowania zamieszania?

Justin Myles Holmes
źródło
2
Rozejrzyj się zanim skoczysz. Ale ten, kto się waha, jest zgubiony.
mmyers

Odpowiedzi:

26

Próbuję też myśleć daleko w przyszłość, ale zwykle nie w kodzie. Burzę mózgów i robię notatki, mam nadzieję, że organizuję rzeczy na tyle dobrze, aby móc się do nich odnieść.

Skłaniam się bardziej ku „nie będziesz go potrzebować” w odniesieniu do kodu, ale „teraz lepiej niż nigdy” w projektowaniu.

Zaczynając od zbudowania nowego systemu, kuszące jest chęć zbudowania wszystkiego teraz, ale może także osłabić pęd i morale. Zwykle myślę o ogólnym projekcie i staram się narysować przez niego bezpośrednią linię - wymyślić kompleksową architekturę szkieletową i zbudować ją najpierw, stosując rozsądne zasady projektowania, aby później ją rozwinąć i przerobić w nowych funkcjach.

Zbuduj najprostszą kompleksową reprezentację systemu, który może działać; zrób to najpierw, a potem masz coś do przemyślenia. To pomaga skrystalizować wszystkie niejasne pytania „co jeśli” i pomóc ci ustalić, co musisz zbudować w następnej kolejności.

samplebias
źródło
3
+1 pozostawienie miejsca na coś w projekcie nie oznacza, że ​​musisz początkowo dużo zbudować. ZNACZNIE zbyt wiele osób zaczyna absolutnie kopać, że przed prośbą nie należy brać pod uwagę niczego i pozostawić się w sytuacji znacznie gorszej niż gdyby zbudowali całość bez udziału klienta.
Bill
9

YAGNI oznacza, że ​​wszystko jest zrobione, gdy trzeba to zrobić, a nie wcześniej. Nie oznacza to, że nigdy się nie skończą, chyba że nigdy nie będą potrzebne. Oznacza to, że robisz tylko to, co zapewnia klientowi natychmiastową wartość biznesową . Znaczenie bezpośredniej wartości biznesowej jest subiektywne dla każdego klienta i każdego projektu.

W obu przypadkach nic nie stracisz dzięki YAGNI.

W innym przypadku tracisz czas na pisanie kodu, który nigdy nie jest używany, i pisanie testów dla kodu, który nigdy nie jest używany, i pisanie dokumentacji dla kodu, który nigdy nie jest używany, i utrzymanie kodu, który nigdy nie jest używany, ludzie zastanawiają się, co robi ten kod , a jeśli kiedykolwiek się przyda, ad nauseum.

Przykład

Jeśli pracuję nad prototypem / próbą koncepcji lub wersją 1.0 aplikacji, nie potrzebuję projektu, aby skalować się do poziomu Facebooka. Piekło nie muszę projekt do skali do poziomu Facebooku, aż zacznę widząc, że mają ten rodzaj ruchu.

Czy uważasz, że Zuckerberg zaprojektował pierwszą wersję Facebooka, aby skalować ją do 500 milionów użytkowników? Nie, zaprojektował i zbudował to tak, aby po prostu tego potrzebowało i nie więcej. Gdyby od samego początku próbował sfotografować projekt dla 500 milionów użytkowników, Facebook prawdopodobnie nigdy nie zostałby wydany.

Praktycznym sposobem robienia rzeczy jest to, jak to zrobił. Zaczął od PHP i MySQL, a przeprojektowanie i przepisanie w razie potrzeby w oparciu o wartość biznesową , skalowanie do milionów użytkowników miało ogromną wartość biznesową, ale nie w dniu 0. W dniu 0 samo uruchomienie czegoś było ogromną wartością biznesową.

On planowany na przeprojektowanie i przepisanie. Jest to inny sposób myślenia niż planowanie zlewu kuchennego i nigdy tak naprawdę nie rozwija ani nie dostarcza niczego pożytecznego, co jest kompletne.

Planowanie końca kodu źródłowego i przepisywanie jest zwinne i przyszłościowe. Próba wypracowania jakiegoś nieokreślonego celu „elastyczności” kończy się niepowodzeniem za każdym razem. Projektujesz bez potrzeby i marnowania czasu, możesz rozwijać to, co ma wartość biznesową, zamiast żenować marzenia o funkcjach, które nigdy nie będą używane.


źródło
2
Jeśli twój projekt jest zły (np. Nieelastyczny), możesz dużo stracić dzięki YAGNI.
EricSchaefer
1
@EricSchaefer - nie, jeśli spełnia cele i zapewnia wartość biznesowi i nie masz dużo czasu zainwestowanego, po prostu wyrzucasz go mniej, niż tracisz, nigdy nie dostarczając magicznego, nieskończenie elastycznego systemu, który nigdy nie będzie kompletny i dostarczony a jeśli tak, będzie to koszmar konfiguracji.
6

Sposób Zen Pythona mówi:

Teraz jest lepiej niż nigdy. Chociaż nigdy nie jest często lepiej niż teraz.

Chodzi o to, że nie dlatego, że możesz teraz zdefiniować coś, co powinieneś. Potrzebujesz go teraz?

  • Tak: zrób to teraz!
  • Nie: nie rób tego! Poczekaj na potrzebę! YAGNI!

Przypadki, w których jest to mniej oczywiste, dotyczą przypadków refaktoryzacji. Czy powinienem stosować DRY za każdym razem, gdy mogę? Odpowiedź nie jest jasna, ponieważ zdarza się, że zastosowanie SUCHEGO kosztuje więcej (w poświęconym czasie) niż duplikacja. Jednak w dłuższej perspektywie stosowanie metody DRY do momentu wystąpienia przyczyn technicznych / związanych z wydajnością nie zawsze jest dobre.

Więc YAGNI, dopóki tego nie zrobisz, a następnie ZRÓB TO TERAZ. Nie czekaj!

Klaim
źródło
3

Nie sądzę, żeby w ogóle grali razem. Myślę, że albo wychylasz się w ten czy inny sposób. I pochylam się w kierunku YAGNI.

Ale jeśli chodzi o wartość, nie zgadzam się z drugą propozycją, że „Teraz jest lepiej niż nigdy”. Jeśli wymaganie jest ważne, będzie musiało zostać wykonane. Zatem „nigdy” nie jest możliwe. Jeśli nie jest to ważne, to „teraz” nie jest lepsze - „nigdy” nie jest lepsze.

Tylko moje dwa centy.

MJB
źródło
A teraz pytanie za milion dolarów: co znaczy „ważny”?
Aaronaught
1
„Ważne” oznacza, że ​​jest to test akceptacyjny.
uprzejmie
ważne oznacza, że ​​klient krzyczy, gdy go nie ma.
Paul Nathan
2
Ważne oznacza, że ​​klient nie płaci, jeśli go nie ma.
Christopher Mahan
@Christopher, można to interpretować jako zachęcające do nieprofesjonalizmu. Np. Ochrona przed iniekcją SQL jest ważna, nawet jeśli klient nie wiedziałby, co to jest i na pewno nie przetestuje go przed zapłaceniem.
Peter Taylor
2

W jaki sposób te dwa wzory się równają?

Są ortogonalne i nie mają ze sobą nic wspólnego.

Jakie praktyki stosujesz, aby zapewnić, że dobrze się bawią?

Um. Czy oni oboje? Co jeszcze może być?

Jak uczysz ich razem bez powodowania zamieszania?

YAGNI opisuje funkcje postrzegane przez użytkowników. Nie potrzebujesz fantazji.

Teraz jest lepiej niż nigdy nie opisuje tego procesu. Napisz teraz testy. Napisz kod teraz. Nie marnuj godzin rozważając alternatywnych rozwiązań. Zbuduj coś, zamiast mówić o budowaniu czegoś.

S.Lott
źródło
2

Jeśli „nigdy” jest implikacją „nie teraz”, to twój projekt jest wadliwy.

Podejmowane przez ciebie decyzje lokalne powinny być przejrzyste dla reszty systemu.
Na przykład, jeśli masz komponent CookieSource, który wymaga CookieFactoryprzekształcenia, w CookieRecipesktóry wie Cookies, na podstawie niektórych twoich parametrów wejściowych, CookieSourcenie musisz, a tym samym nie może zależeć od tego, jak CookieFactoryjest implementowany i jak CookieRecipesjest reprezentowany.
Jeśli CookieFactoryw rzeczywistości jest to Bakery, to może wziąć każdy Recipezgodnie z Pastrynie powinno mieć znaczenia. A jeśli nie potrzebujesz tej funkcjonalności, nie musisz jej implementować. I nie ma na świecie powodu, dla którego nie można go później dodać, z wyjątkiem sytuacji, gdy nie ma wyraźnej bariery abstrakcji między CookieSourceusługami, z których korzysta.

Budując oprogramowanie, dodaj funkcjonalność w razie potrzeby i staraj się nie angażować w podejmowane decyzje. Zamiast tego zablokuj decyzję w odpowiedniej abstrakcji .

back2dos
źródło
1

Najprostszym rozwiązaniem, jakie znalazłem, jest oczekiwanie zmian podczas pisania kodu z góry. Kiedy przekazuję bool do funkcji, zazwyczaj zmieniam ją jak najszybciej na flagę / wyliczenia, aby była a) bardziej czytelna i b) łatwa do rozszerzenia. Podobnie, jeśli zauważę, że przekazuję wiązkę parametrów wokół tego, co pachnie, jakbym potrzebował jeszcze jednego, zwykle tworzę specjalną strukturę. Mamy nadzieję, że YAGNI to zrobi, ale jeśli to zrobisz, nie od razu okropnie złamie wszystkich użytkowników, a „chrząknięcie” zostało już wykonane. Często wystarczy dodać komentarz, taki jak / * przyszłe dodatki tutaj * / tak, więc jest jasne, że nie został jeszcze zaimplementowany, ale tutaj jest miejsce, aby go dodać. Zwykle najbardziej to pomaga, ponieważ później uważałem, że refaktoryzacja interfejsu jest najbardziej czasochłonna.

Anteru
źródło
Zasadniczo podoba mi się ta filozofia, ale w praktyce migracje są na tyle bolesne, że zmuszają mnie do dwukrotnego zastanowienia. Czy kiedykolwiek zdarzyło Ci się, że migracja modeli przeszkadza w oczekiwaniu zmian?
Justin Myles Holmes
Zaletą tego podejścia jest to, że zmiany są mniej bolesne; wciąż jest dużo pracy. Nie jestem pewien, co masz na myśli mówiąc o migracji modeli - zdecydowanie jestem po stronie YAGNI, ale przygotowuję się na najgorsze :)
Anteru
0

Projektuj z myślą o przyszłych rozszerzeniach, ale nie implementuj tych rozszerzeń, dopóki ich nie potrzebujesz.

Przykładem, który przychodzi na myśl, jest pierwsze uruchomienie Netflix, z którym można przypisać tylko jedną kolejkę. Później zhakowali obsługę wielu kolejek. Ponieważ nie był tak zaprojektowany od samego początku, stał się coraz trudniejszy w utrzymaniu, dlatego postanowili przerwać tę funkcję. Po wzburzeniu klienta ugryzli pocisk i przeprojektowali go, aby poprawnie zintegrować wiele kolejek.

Gdyby ktoś na początku dopuścił możliwość, że może chcieć wielu kolejek później, mogliby zaoszczędzić sobie długiego żalu za bardzo niewielki dodatkowy wysiłek krótkoterminowy. Nie musieli od razu wdrażać wielu kolejek, po prostu upewnij się, że jeśli to zrobią, nie będzie to wymagało ogromnego przepisywania lub niemożliwego do utrzymania hakowania.

Na pierwszy rzut oka wydaje się, że wymagałoby to zdolności przypominającej wróżki do przewidywania przyszłych wymagań, ale w praktyce takie rzeczy trzymają się dobrego programisty, gdy zauważa, że ​​coś koduje na sztywno lub tabelę bazy danych zbiera wiele tylko niejasno powiązanych kolumn.

Karl Bielefeldt
źródło