TL; DR: zależy to od tego, co próbujesz rozwiązać.
Rozmawiałem na ten temat z moimi Grampami, kiedy rozmawialiśmy o tym, jak Func i Action w C # są niesamowite. My Gramps to bardzo stary programator czasowy, który był związany z kodami źródłowymi, odkąd oprogramowanie działało na komputerach, które zajmowały cały pokój.
Kilka razy zmieniał technologię w swoim życiu. Napisał kod w C, COBOL, Pascal, BASIC, Fortran, Smalltalk, Java i ostatecznie zaczął C # jako hobby. Nauczyłem się, jak programować z nim, siedząc na kolanach, gdy byłem diabłem, wycinając pierwsze wiersze kodu w niebieskim edytorze SideKick IBM. Kiedy miałem 20 lat, spędziłem już więcej czasu na kodowaniu niż granie na zewnątrz.
To trochę moje wspomnienia, więc przepraszam, jeśli nie jestem do końca praktyczny, gdy je powtarzam. Trochę mi się podobają te chwile.
Tak mi powiedział:
„Czy powinniśmy dążyć do uogólnienia problemu, czy rozwiązać go w określonym zakresie, pytasz? Cóż, to… pytanie”.
Gramps zatrzymał się na chwilę, aby pomyśleć o tym, jednocześnie ustalając położenie okularów na twarzy. Grał w grę match-3 na swoim komputerze, słuchając płyty Deep Purple na swoim starym systemie dźwiękowym.
„Cóż, to zależy od tego, jaki problem próbujesz rozwiązać”, powiedział mi. „Kuszące jest przekonanie, że istnieje jedno święte rozwiązanie dla wszystkich wyborów projektowych, ale nie ma jednego. Architektura oprogramowania jest jak ser, rozumiesz.”
„... Ser, Gramps?”
„Nie ważne, co myślisz o swoim ulubionym, zawsze znajdzie się ktoś, kto uważa, że śmierdzi”.
Przez chwilę mrugałam zmieszana, ale zanim zdążyłam cokolwiek powiedzieć, Gramps kontynuował.
„Jak budujesz samochód, jak wybierasz materiał na część?”
„Myślę… Myślę, że to zależy od kosztów i tego, co ta część powinna zrobić, jak sądzę.”
„To zależy od problemu, który stara się rozwiązać część. Nie zrobisz opony wykonanej ze stali lub przedniej szyby wykonanej ze skóry. Wybierasz materiał, który najlepiej rozwiązuje problem, który masz pod ręką. Teraz czym jest ogólne rozwiązanie? Albo konkretne? Na jaki problem, na jaki przypadek użycia? Czy powinieneś zastosować pełne funkcjonalne podejście, aby zapewnić maksymalną elastyczność kodowi, który będzie użyty tylko raz? Czy powinieneś napisać bardzo specjalistyczny, delikatny kod do część twojego systemu, która będzie miała wiele zastosowań i być może wiele zmian? Takie wybory projektowe są podobne do materiałów, które wybierasz do części w samochodzie lub kształtu klocków Lego, które wybierasz do budowy małego domu Jaka klocki Lego jest najlepsza? ”
Starszy programista sięgnął po mały model pociągu Lego, który ma na swoim stole, zanim kontynuował.
„Możesz odpowiedzieć tylko na to, jeśli wiesz, po co ci ta cegła. Skąd, do diabła, dowiesz się, czy konkretne rozwiązanie jest lepsze niż ogólne, i odwrotnie, jeśli nawet nie wiesz, na czym polega problem? próbujesz rozwiązać? Nie widzisz przeszłości, której nie rozumiesz ”.
„..Czy właśnie zacytowałeś Matrycę? ”
"Co?"
„Nic, mów dalej”.
„Załóżmy, że próbujesz zbudować coś w systemie faktur krajowych. Wiesz, jak wygląda ten piekielny interfejs API i jego plik XML zawierający trzydzieści tysięcy wierszy od wewnątrz. Jak wyglądałoby„ ogólne ”rozwiązanie do tworzenia tego pliku na przykład? Plik jest pełen opcjonalnych parametrów, pełen spraw, z których powinny korzystać tylko bardzo specyficzne gałęzie biznesu. W większości przypadków możesz je bezpiecznie zignorować. Nie musisz tworzyć ogólnego systemu faktur, jeśli jedyną rzeczą, którą „ Zawsze będę sprzedawać buty. Po prostu stwórz system sprzedaży obuwia i spraw, aby był to najlepszy system fakturowania butów, który istnieje na rynku. Teraz, gdybyś musiał stworzyć system faktur dla dowolnego rodzaju klienta, w szerszym zakresie - zostać odsprzedane jako niezależny, ogólny system sprzedaży,na przykład - teraz interesujące jest wdrożenie tych opcji, które są używane tylko w przypadku gazu, żywności lub alkoholu.Teraz są to możliwe przypadki użycia. Wcześniej były to tylko hipotetyczne przypadki Nie używaj przypadków, a nie chcesz wdrożyć Nie używaj przypadków. „Nie używaj” to młodszy brat „ Nie potrzebujesz ”.
Gramps umieścił pociąg lego z powrotem na swoim miejscu i wrócił do swojej gry polegającej na dopasowywaniu trzech elementów.
„Aby więc wybrać ogólne lub konkretne rozwiązanie danego problemu, musisz najpierw zrozumieć, na czym polega ten problem. W przeciwnym razie zgadujesz, a zgadywanie jest zadaniem menedżerów, a nie programistów. Jak prawie wszystko w IT, to zależy ”.
Więc masz to. "To zależy". To chyba najpotężniejsze wyrażenie dwuliterowe, gdy myśli się o projektowaniu oprogramowania.