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

Czytelność nie jest cechą binarną. Jest to bardzo subiektywny czynnik ludzki opisujący nasz związek z kodem. I będzie się ona zmieniać wraz z naszymi umiejętnościami i zrozumieniem. Ja osobiście odczułem skutki podobne do pokazanego rysunku, a inni, z którymi rozmawiałem, też to potwierdzają.

Możecie doświadczyć podobnych skutków podczas pracy z tą książką. Ale nabierzcie otuchy. Jeśli wytrzymacie, krzywa wróci skierowana do góry!

Imperatywny oznacza kod, który większość z nas pisze w sposób naturalny. Skupia się on na bezpośrednim instruowaniu komputera, jak coś zrobić. Kod deklaratywny – ten, którego uczymy się pisać, a który trzyma się zasad FP – to kod skupiający się bardziej na opisie, jaki ma być wynik.

Wróćmy do dwóch fragmentów kodu pokazanych wcześniej w tym rozdziale.

Pierwszy jest imperatywny, skupiający się na tym, jak wykonać zadania. Jest zawalony instrukcjami if, pętlami for, zmiennymi tymczasowymi, zmianami wartości, wywoływaniem funkcji ze skutkami ubocznymi oraz niejawnym przepływem danych między funkcjami. Z pewnością możemy prześledzić logikę kodu, aby zobaczyć, jak liczby przepływają i ulegają zmianie do stanu końcowego, ale nie jest to jasne i bezpośrednie.

Drugi fragment kodu jest bardziej deklaratywny. Odchodzi od wszystkich wymienionych tu technik imperatywnych. Zauważmy, że nie ma tu jawnych instrukcji warunkowych, pętli, efektów ubocznych, zmiany wartości ani mutacji. Zamiast tego kod stosuje dobrze znane (w każdym razie dla świata FP!) i godne zaufania wzorce jak filtrowanie, redukcja, przenoszenie i złożenie. Uwaga przesuwa się z niskiego poziomu jak na wyższy poziom co będzie wynikiem.

Zamiast babrania się w instrukcjach if w celu sprawdzenia liczby, delegujemy to do dobrze znanego narzędzia FP jak gte(..) (większe lub równe), a następnie skupiamy się na ważniejszym zadaniu powiązania tego filtra z drugim filtrem i funkcją sumowania.

Co więcej, przepływ danych przez drugi program jest jawny:

1 Lista liczb idzie do printMagicNumber(..).

2 Liczby te są przetwarzane po jednej przez sumOnlyFavorites(..), dając w wyniku jedną liczbę (sumę) jedynie z wybranych liczb.

3 Suma zostaje przekształcona na łańcuch komunikatu za pomocą constructMsg(..).

4 Łańcuch komunikatu zostaje wydrukowany na konsoli za pomocą console.log(..).

Może się nadal wydawać, że to podejście jest zawikłane oraz że imperatywny fragment jest łatwiejszy do zrozumienia. Przyzwyczajcie się. Obeznanie ma ogromny wpływ na nasz osąd czytelności. Po przeczytaniu tej książki dzięki praktyce docenicie drugi fragment z podejściem deklaratywnym, a jego znajomość spowoduje poprawę jego czytelności.

Wiem, że prośba, aby to przyjąć, wymaga od was w tym momencie bezwarunkowej wiary.

Poprawienie czytelności i eliminacja wielu pomyłek prowadzących do błędów, jak to sugeruję, wymaga dużo więcej wysiłku oraz czasem więcej kodu. Uczciwie mówiąc, gdy zaczynałem pisać tę książkę, nie potrafiłbym napisać (i w pełni zrozumieć!) drugiego fragmentu kodu. Teraz, gdy jestem dużo dalej w swojej nauce, jest on bardziej naturalny i wygodny.

Jeśli ktoś ma nadzieję, że przejście na FP zadziała jak magiczna różdżka i szybko przekształci kod na przyjemniejszy, elegantszy, mądrzejszy, bardziej odporny i zwięzły – i że to pójdzie łatwo w krótkim terminie – to niestety nie są to realistyczne oczekiwania.

FP różni się bardzo sposobem myślenia o tym, jaka powinna być struktura kodu, aby przepływ danych był bardziej oczywisty i pomagał czytelnikom podążać za naszym myśleniem. To potrwa. Ten wysiłek jest zdecydowanie wart zachodu, ale może to być niełatwa podróż.

Wciąż często potrzebuję kilku prób, aby zrefaktoryzować fragment kodu imperatywnego na bardziej deklaratywny kod FP, zanim uda mi się dojść do czegoś, co jest dostatecznie jasne, abym zrozumiał to później. Doszedłem do wniosku, że przechodzenie na FP to powolny proces iteracyjny, a nie szybkie przełączenie się z jednego paradygmatu na inny.

Stosuję też test „później tego naucz” do każdego kawałka napisanego przez siebie kodu. Po zapisania kawałka kodu zostawiam go na kilka godzin lub dni, a potem próbuję odczytać na świeżo, udając, że chcę kogoś nauczyć lub mu wytłumaczyć. Zwykle na początku jest to pogmatwane i mylące, więc to poprawiam i powtarzam!

Nie próbuję nikogo zdołować. Chciałbym, żeby każdy poczuł bluesa. Cieszę się, że mnie się udało. Mogę wreszcie zobaczyć, jak pokazana krzywa zagina się w górę w kierunku lepszej czytelności. Wysiłek się opłacił. I opłaci się każdemu.