Zasada YAGNI w tworzeniu oprogramowania: czy naprawdę potrzebujesz tej abstrakcji lub generycznego kodu?

Co to jest YAGNI? Nie buduj tego, czego nie będziesz potrzebował

W centrum tej dyskusji znajduje się zasada YAGNI, czyli 'You Aren't Gonna Need It' — kluczowe pojęcie z ekstremalnego programowania i zwinnego rozwoju oprogramowania. Jak wyjaśnia Derek, YAGNI mówi programistom, by nie implementowali funkcji lub funkcjonalności, które wydaje im się, że będą potrzebować w przyszłości, ale skupiali się na obecnych wymaganiach.

Derek dodaje subtelność: podczas gdy powinieneś unikać pisania spekulacyjnego kodu, również nie chcesz krępować się przed późniejszym dostosowaniem. Wyzwanie polega na tym, aby unikać spędzania czasu na funkcjach, które mogą być użyteczne, jednocześnie będąc otwartym na zmiany. To jest powszechny dylemat w zwinności oprogramowania i inżynierii oprogramowania.

Opisuje dwie powszechne błędne aplikacje YAGNI:

1. Planowanie funkcji – przewidujesz przyszłe wymagania i zaczynasz budowę już teraz.

2. Abstrakcje kodu – uogólniasz lub abstrahujesz istniejący kod zbyt wcześnie, zgadując, które inne funkcje mogą być potrzebne.

W obu przypadkach, zazwyczaj rezultat to zmarnowany wysiłek, dodana złożoność i narastanie funkcjonalności – dokładne przeciwieństwo tego, co promuje dobra praktyka i zasada KISS (Keep It Simple, Stupid).

Rzeczywisty przykład: System powiadamiania o przesyłce

Aby to zilustrować, Derek używa przykładu systemu zarządzania przesyłkami, który wysyła SMS do użytkownika, gdy jego paczka zostanie dostarczona. System korzysta z Twilio, a funkcja działa poprzez obsługę zdarzenia dostawy, pobieranie informacji kontaktowych i wysyłanie wiadomości.

Ten prosty proces rozwoju kodu spełnia bieżące wymagania. Jest to proste, możliwe do przetestowania i zapewnia wartość dodaną. Ale wtedy pojawia się pytanie: co jeśli w przyszłości zechcemy zmienić dostawcę usług SMS?

W tym miejscu wielu programistów błędnie stosuje zasadę YAGNI. Zakładają, że ponieważ w przyszłości może pojawić się inna implementacja, muszą teraz wyodrębnić logikę SMS-ów. W ten sposób tworzą interfejs taki jak ISmsService.

Abstrakcje: Czy budujesz przyszłość, która może nie istnieć?

Derek kwestionuje tę wczesną abstrakcję: jeśli masz tylko jedną implementację i nie ma obecnie potrzeby zmiany dostawcy, to po co abstrakcja? Dodajesz niepotrzebną złożoność, aby ułatwić sobie życie w przyszłości, która może nigdy nie nadejść.

Idzie on jeszcze dalej, ilustrując koszty inżynierii oprogramowania. Kiedy w końcu dodasz drugiego dostawcę, zdasz sobie sprawę, że Twój interfejs jest zbyt ściśle powiązany ze specyficznymi potrzebami Twilio (takimi jak logika numeru telefonu "od"). Nagle abstrakcja staje się odpowiedziąlnością. W ten sposób abstrakcje oparte na ograniczonej wiedzy często wprowadzają błędy i komplikują refaktoryzację.

Najważniejsze wnioski: nie oszczędzasz czasu, tylko tworzysz coś nieprawidłowego z powodu niewystarczającego kontekstu.

Zbyt wczesne uogólnianie: pułapka dla programistów

Jednym z najczęstszych naruszeń zasady YAGNI w projektach informatycznych jest dążenie do uogólniania rzeczy, zanim jest to konieczne. Derek omawia to na innym przykładzie — grupowaniu powiadomień SMS i e-mailowych w jeden, ogólny system powiadomień.

Aby to zrobić, programista może zdefiniować typ powiadomienia (SMS lub e-mail), uniwersalne pole adresu i stworzyć jedną usługę obsługującą oba rodzaje. Jednak ta zbyt abstrakcyjna konstrukcja w rezultacie komplikuje logikę i tworzy ścieżki kodu warunkówego, które są niestabilne i trudne w utrzymaniu.

Jest to klasyczny przykład rozrostu funkcji i cecha charakterystyczna ignorowania zasad lean development oraz solidnych zasad programowania. Piszesz kod spekulacyjny, który nie zaspokaja żadnych bezpośrednich potrzeb użytkowników — to sygnał ostrzegawczy w każdym zwinnym procesie tworzenia oprogramowania.

Preferuj rozszerzenia zamiast modyfikacji

Zamiast nadmiernego komplikówania, Derek sugeruje podejście oparte na najprostszym rozwiązaniu: jeśli później zajdzie potrzeba obsługi powiadomień e-mailowych, wystarczy zaimplementować tę funkcję osobno.

Dzięki architekturze sterowanej zdarzeniami każde zdarzenie może wywołać wiele niezależnych procedur obsługi. Na przykład jeden moduł obsługi wiadomości SMS, a drugi wiadomości e-mail. Możesz później usunąć jedno z nich bez wpływu na drugie. Metoda ta promuje prostotę, wspiera zmieniające się wymagania i respektuje rozdział zagadnień — wszystko to jest zgodne z najlepszymi praktykami zwinnego i opartego na testach programowania.

Tworząc systemy, które są rozszerzalne, a nie nadmiernie rozbudowane, zachowujesz elastyczność bez konieczności przewidywania każdej możliwej przyszłości. W ten sposób unikniesz niepotrzebnej złożoności i zachowasz elastyczność.

Rzeczywisty koszt naruszenia zasady YAGNI

Derek podkreśla rzeczywisty koszt tworzenia zbędnych funkcji:

• Czas poświęcony na tworzenie czegoś, czego nigdy nie używasz

• Dodatkowa złożoność, która nie zapewnia natychmiastowej wartości

• Wyższe koszty utrzymania dla programistów, którzy muszą teraz zajmować się nieużywanym lub nadmiernie rozbudowanym kodem

• Większe prawdopodobieństwo wystąpienia błędów i niedociągnięć spowodowanych nadmierną inżynierią

Jest to zgodne z kolejną podstawową zasadą zwinnego tworzenia oprogramowania: skup się na dostarczaniu wartości teraz, a nie być może później.

Zauważa on, że doświadczeni programiści często popełniają błąd, ufając swoim przeczuciom co do przyszłych potrzeb — i się mylą. Nawet mając doświadczenie, przewidywanie, czego system będzie potrzebował za kilka miesięcy, często jest grą przegraną.

Podsumowanie: kontekst ma znaczenie, a prostota wygrywa

Derek podsumowuje, wyjaśniając, że nie jest przeciwny zasadom projektowania ani abstrakcjom. W rzeczywistości wierzy on w tworzenie systemów, które mogą ewoluować. Błędem jest jednak wdrażanie rozwiązań bez aktualnego uzasadnienia — co zasadniczo stanowi naruszenie zasady YAGNI.

Zachęca programistów do "pisania kodu i wdrażania funkcji, które mają wartość już teraz". Należy unikać dążenia do spełnienia przyszłych wymagań kosztem obecnych użytkowników. Trzymaj się zasad czystego kodu i wybieraj strategie projektowe, które wspierają zmiany, nie ograniczając Cię do spekulatywnych struktur.

Zaprasza również programistów do podzielenia się własnymi przerażającymi historiami związanymi z zasadą YAGNI, w których tworzyli rozwiązania na przyszłość, a nigdy ich nie potrzebowali — co jest częstym zjawiskiem w wielu projektach.

Wniosek: Zastosuj zasadę YAGNI w swoim procesie programowania

Zasada YAGNI pozostaje jednym z najcenniejszych narzędzi w arsenale programisty. Jest to zgodne z filozofiami agile, lean i KISS, przypominającymi nam, aby tworzyć tylko to, co jest potrzebne — nic więcej. Analiza tego pomysłu przeprowadzona przez Dereka Comartina w jego filmie, oparta na rzeczywistych przykładach kodu i procesów programistycznych, stanowi jasną wskazówkę, jak skutecznie stosować zasadę YAGNI.

Więc następnym razem, gdy poczujesz pokusę, by dodać warstwę abstrakcji, klasę generyczną lub dodatkową funkcję, zatrzymaj się i zadaj sobie pytanie:

Czy rozwiązujesz problem, z którym się borykasz, czy też taki, który, jak przypuszczasz, może pojawić się w przyszłości?

Nie poświęcaj czasu na wyobrażone przyszłości. Skup się na budowaniu wartości już dziś. Dbaj o to, by Twoje oprogramowanie było proste, łatwe w utrzymaniu i odpowiadało rzeczywistym potrzebom.

Bo prawdopodobnie nie będziesz tego potrzebować.