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

Mam zawsze bardzo proste założenie, które leży u podstaw wszystkiego, co robię jako nauczyciel tworzenia oprogramowania (w JavaScripcie): kod, któremu nie możemy ufać, to kod, którego nie rozumiemy. Prawdziwe jest także twierdzenie odwrotne: kod, którego nie rozumiemy, jest kodem, któremu nie możemy ufać. Ponadto, jeśli nie potrafimy zrozumieć naszego kodu ani mu ufać, to nie możemy mieć żadnej wiary w to, że pisany przez nas kod jest odpowiedni do postawionego zadania. Uruchamiamy program i po prostu trzymamy kciuki.

Co rozumiemy przez zaufanie? Dla mnie oznacza to, że można go zweryfikować, czytając go i analizując, a nie tylko wykonując, i że rozumiemy, co dany kawałek kodu naprawdę zrobi. Częściej niż jest to rozważane, mamy tendencję, aby polegać na uruchomieniu zestawu testów do zweryfikowania poprawności programu. Nie mam zamiaru sugerować, że testy to coś złego. Ale wydaje mi się, że powinniśmy aspirować do tego, aby zrozumieć nasz kod na tyle, żeby przed uruchomieniem wiedzieć, że przejdzie testy.

Techniki stanowiące podstawę FP są zaprojektowane z punktu widzenia znacznie większego zaufania do naszych programów po samym ich przeczytaniu. Ktoś, kto rozumie FP i jest dostatecznie zdyscyplinowany, aby skrupulatnie wykorzystywać je w swoich programach, napisze kod, który on i inni będą mogli przeczytać i zweryfikować, czy program będzie robił to, czego od niego oczekują.

Zaufanie jest także zwiększane przez użycie technik, które pozwalają omijać lub minimalizować prawdopodobne źródła błędów. To prawdopodobnie jedna z największych zalet FP: programy napisane funkcyjnie zwykle mają mniej błędów, a istniejące błędy są często w bardziej oczywistych miejscach, więc są łatwiejsze do znalezienia i wyeliminowania. Kod FP jest zazwyczaj bardziej odporny na błędy, ale zdecydowanie nie jest od nich wolny.

W miarę podróży przez tę książkę zaczniemy rozwijać w sobie więcej wiary w pisany kod, gdyż będziemy używać wzorców i praktyk, które będą sprawdzone. I będziemy unikać najpopularniejszych przyczyn błędów w programach.