Читать книгу JavaScript funkcyjnie. Zrównoważone, pragmatyczne programowanie funkcyjne w JavaScript - Kyle Simpson - Страница 13

Osoby, które mają długo styczność z FP, zapewne słyszały określenie „YAGNI”: „You Ain’t Gonna Need It” (Nie będziesz tego potrzebować). Zasada ta pochodzi pierwotnie z programowania ekstremalnego (extreme programming) i kładzie nacisk na wysokie ryzyko i koszt tworzenia funkcji, zanim będą one potrzebne.

Czasami wydaje nam się, że będziemy potrzebowali czegoś w przyszłości, więc tworzymy to w przekonaniu, że łatwiej to zrobić przy okazji pracy nad innymi rzeczami, a potem zdajemy sobie sprawę, że nasze przypuszczenie było nieprawdziwe i funkcja nie jest potrzebna lub powinna być całkiem inna. Przy innej okazji przypuszczenie jest prawdziwe, ale funkcja zostaje utworzona zbyt wcześnie i pochłania czas, który powinniśmy poświęcić na funkcje potrzebne teraz. Ponosimy koszty, rozpraszając swoją energię.

YAGNI niesie wyzwanie warte zapamiętania: nawet jeśli wydaje nam się to w danej sytuacji sprzeczne z intuicją, powinniśmy odłożyć tworzenie rzeczy do czasu, kiedy będą naprawdę potrzebne. Mamy tendencję do przesady w naszych ocenach przyszłych kosztów refaktoryzacji związanych z jej późniejszym wykonaniem, gdy będzie naprawdę potrzebna. Prawdopodobne później nie będzie to tak trudne, jak założyliśmy.

W zastosowaniu do programowania funkcyjnego przestrzegam: w tym tekście omawianych jest wiele ciekawych i istotnych wzorców, ale nie warto umieszczać wzorca w swoim kodzie tylko dlatego, że wydaje nam się fascynujący.

Różnię się tu od formalistów FP: to, że do czegoś można zastosować FP nie oznacza, że należy zastosować FP. Co więcej, jest wiele sposobów podzielenia problemu, więc jeśli nawet poznaliśmy bardziej wyrafinowane podejście, które jest w utrzymaniu i możliwości rozszerzania bardziej „odporne na przyszłość”, prostszy wzorzec FP może być w danym punkcie wystarczający.

Ogólnie zalecam szukanie w kodzie równowagi i konserwatywne podejście do stosowania FP, w miarę jak poznajemy jego elementy. Warto przyjąć zasadę YAGNI przy decydowaniu, czy dany wzorzec lub abstrakcja pomogą sprawić, że dany fragment kodu stanie się bardziej czytelny, czy tylko wprowadzą mądre wyrafinowanie, które (jeszcze) nie ma uzasadnienia.

Pamiętajmy, że każde rozszerzenie, które nie zostanie nigdy użyte, to nie tylko marnowanie wysiłku, ale także coś, co może się stać przeszkodą.

Jeremy D. Miller @jeremydmiller 20/2/15

https://twitter.com/jeremydmiller/status/568797862441586688

Pamiętajmy, że każdy wiersz kodu, który piszemy, ma związane z tym koszty czytelnika. Czytelnikiem może być członek innego zespołu lub nawet my sami w przyszłości. Żaden z czytelników nie będzie pod wrażeniem czegoś przemądrzałego, niepotrzebnie wyrafinowanego, co tylko pokazuje naszą biegłość w FP.

Najlepszym kodem jest kod najbardziej czytelny w przyszłości, gdyż celuje dokładnie we właściwe proporcje między tym, co można i co powinno być (idealizm), a tym, co musi być (pragmatyzm).