Jako programiści robimy przede wszystkim dwie rzeczy: piszemy nowy kod i czytamy kod stary. Jest to rzecz tak oczywista, że nikt się nad tym nie zastanawia. Mnie samemu wydawało się to banałem. Oczywiście prawie zawsze, żeby napisać jakiś nowy kod trzeba przeczytać istniejący. Często nie trzeba nawet zbyt wiele dodawać, wystarczy zmiana kilku linijek, by wykonać zadanie.
I tak w gruncie rzeczy więcej tego kodu czytamy niż piszemy. Tymczasem od studiów i kursów, przez konferencje, aż po szkolenia – wszystko kręci się wokół pisania. Czysty kod, nowe języki, nowe frameworki. Na rekrutacjach proszą nas o napisanie jakiejś funkcji, na meetupach pokazują jak ładnie i sprawnie pisać przy użyciu nowych narzędzi. I nikt – ale to naprawdę nikt! – nie skupia się na tym, na czym spędzamy większość czasu w pracy: na czytaniu kodu.
Ile znacie narzędzi pomagających w pisaniu? Formatery, lintery, wtyczki do refaktoryzacji, test runnery, podkreślanie błędów, podpowiadanie nazw metod – cuda wianki. A ile znacie narzędzi pomagających w czytaniu? Kolorowanie składni i debugger? Coś jeszcze?
Powiem więcej. Wymienicie choćby trzy książki, które dotyczą czytania kodu?
Ja znam tylko jedną – Praca z zastanym kodem. Najlepsze techniki, Michaela Feathersa. Co więcej jest to książka raczej mało popularna, choć ceniona i polecana…
Oczywiście niełatwe jest stworzenie takich narzędzi. Czytanie kodu to tak naprawdę nauka, to próba zrozumienia pewnego modelu rzeczywistości, który stworzył inny programista. To żmudny proces poznawania struktur danych i algorytmów. Lecz mimo wszystko jest to esencja zawodu programisty. I prawie nikt się nad tą kwestią nie pochyla.
Nienawidzimy brzydkiego kodu, uciekamy z pracy przed spaghetti, przed legacy, a jednocześnie w każdym projekcie spotykam się z debugowaniem przez console.log / printf / WriteLine i brakiem albo co najmniej niedoborem testów jednostkowych. Jest to chyba nasz wspólny grzeszek, że tak mało serca wkładamy w czytanie kodu…
Wszystkie zasady, które tworzymy np. wzorce, są elementem wspólnej rzeczywistości i języka którym się posługujemy. Dużo książek dotyczących projektowania, architektury, czystego kodu porusza temat czytelności. Tak naprawdę kwintesencją czytelności jest pisanie oczywistego kodu, prostych interfejsów i stosowanie odpowiednich wzorców, gdy jest sens ich używać. To co mi z czasem wydaje się coraz bardziej sensowne, to komentarze objaśniające i dokumentacja, zwłaszcza w sytuacjach, gdy konieczne jest tworzenie wielopoziomowych abstrakcji.