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

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?

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.

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.

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!

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.

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ś.

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 .

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.

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.