Kiedy preferować uogólnione rozwiązanie zamiast rozwiązywania konkretnych przypadków

W programowaniu często mamy do wyboru: uwzględnij każdy możliwy przypadek użycia osobno lub rozwiąż ogólny problem:

Oczywiste jest, że rozwiązanie natychmiastowego problemu jest szybsze, jednak stworzenie ogólnego rozwiązania pozwoli zaoszczędzić czas w przyszłości.

Skąd mam wiedzieć, kiedy najlepiej spróbować objąć skończoną listę przypadków lub stworzyć ogólny system obejmujący wszystkie możliwości?

Najpierw podajesz sól. Następnie podajesz pieprz. Następnie podajesz startego parmezanu. W tym momencie masz wystarczające doświadczenie, aby rozpocząć opracowywanie ogólnego systemu przekazywania przypraw.

Działa w projektach oprogramowania w ten sam sposób: używaj systemów specjalnych, które opracowujesz jako etapy uczenia się, do uogólnionych, więc kiedy nadszedł czas, aby uruchomić system ogólnego przeznaczenia, masz większą pewność co do tego, co budujesz, ponieważ masz za sobą kilka systemów specjalnych.

Skąd mam wiedzieć, kiedy najlepiej spróbować objąć skończoną listę przypadków lub stworzyć ogólny system obejmujący wszystkie możliwości?

Doświadczenie.

Jedynym sposobem, aby się dowiedzieć, jest wypróbowanie jednej ścieżki wcześniej, zobaczenie, jak ugryzł cię w tyłek (lub zmarnowałeś sporo czasu). Powtarzaj tę czynność, dopóki nie dostaniesz trochę tyłka

Nawet wtedy tak naprawdę nie wiesz ; po prostu lepiej zgadnij.

Aby skorzystać z odpowiedzi dasblinkenlight i Paddy3118 , jeśli nie masz wielu przypadków do zaimplementowania, nie musisz generalizować! Powodem, dla którego kreskówka XKCD jest śmieszna, jest to, że nęka przedwczesne uogólnienie . Po poproszeniu o podanie soli, niewidoczna postać natychmiast przeskakuje do „opracowania systemu do przekazywania dowolnych przypraw”, gdy jedyną pytaną postacią była sól. To dobry żart dla programistów, ponieważ myślę, że wszyscy widzieliśmy przypadki przedwczesnego uogólnienia.

Zasada przeciwna przedwczesnemu uogólnieniu to YAGNI (You Ain't Go Need Need). Istnieje wiele materiałów na ten temat dostępnych w Internecie, ale w zasadzie YAGNI wskazuje na szereg zagrożeń uogólniających bez korzyści wynikających z kilku faktycznych przypadków użycia, w tym możliwość, że przypadki wielokrotnego użycia mogą się nie pojawić. Lub, bardziej subtelnie, brak faktycznych przypadków użycia wymaga przyjęcia założeń dotyczących tego, co jest konieczne w przyszłości. Te założenia mogą być i często są błędne.

Wydaje się, że łatwiej jest być ogólnym w małych, tzn. Nie tworzyć klasy do obsługi tabeli odnośników, która odwzorowuje liczby całkowite na ciągi, gdy można stworzyć rozsądną klasę słownikową, która obsługuje dowolną parę typów (gdzie pierwszy typ obsługuje pewien typ porównanie).

W poprzednim życiu wykonałem wiele projektów automatyki przemysłowej dla maszyn, które obsługiwały ciągłą wstęgę materiału. Stal, aluminium, papier, plastik ... Rozwijasz go na jednym końcu i ponownie zrolujesz na drugim, po zrobieniu czegoś przydatnego na środku. W jednej branży zaczynasz od „bębna wypłat”, a nie „odwijacza”. Jeśli użyjesz złej terminologii, jesteś idiotą w oczach klienta o wartości wielu milionów dolarów. Zdziwiłbyś się, jak niewiele można wyodrębnić do ponownego wykorzystania z jednego projektu do drugiego. OTOH, często można stworzyć ramy lub szablon jako punkt wyjścia. Zostałby dostosowany do danego zadania, ale przynajmniej miał korzyść z uczenia się na podstawie wcześniejszych projektów. I wszyscy członkowie zespołu wiedzieli, od czego zaczynamy.

Zrób to raz, zrób to dwa razy, zrób to trzy razy, uogólnij.

Raz, dwa, wiele!

W drugim przypadku powinieneś pomyśleć o uogólnieniu. Gdy zostaniesz poproszony o trzeci, powinieneś dostarczyć go z kodu uogólnionego i użyć pierwszego i drugiego przypadku wcześniej rozwiązanego indywidualnie jako przypadków testowych.