Wujek Bob vs Jonh Ousterhout

Robert C. Martin "Uncle Bob" (Clean Code), John Ousterhout (A Philosophy of Software Design).

Ciekawi mnie wasze podejscie do twierdzeń tych dwóch panów, oraz do tego na ile korzystacie z ich rad do pisania kodu (myśenia o kodzie).

Czytelność

• Martin - skupia się na niej. Metody mają być mikroskopijne (4-6 linii). Jeśli metoda jest długa, to znaczy, że jest "brudna" i wypada ją rozdzielić.
• Ousterhout - Skupia się na "cognitive load". Twierdzi, że rozbijanie wszystkiego na mikroskopijne metody tworzy "shallow modules"- płytkie moduły. W efekcie musisz skakać po 10 plikach, żeby zrozumieć jeden proces. Dla niego "czysty" kod to taki, który ma prosty interfejs, ale "głęboką" i kompletną implementację w jednym miejscu.

Abstrakcja

• Martin - "Abstrakcja ponad wszystko" - argumentuje testowalnością. Interfejsy, fabryki, wstrzykiwanie – nawet jeśli mamy tylko jedną implementację.
• Ousterhout - "Define errors out of existence" - zaprojektuj system tak, żeby błędy były niemożliwe. Abstrakcja jest kosztem – jeśli nie ukrywa dużej złożoności, to jest szkodliwa. Dobra abstrakcja ukrywa decyzje projektowe, nie tylko złożoność.

Classitis

• Martin - małe klasy są zawsze lepsze.
• Ousterhout - Twierdzi, że zbyt duża liczba małych klas rozmywa to, co system faktycznie robi.

Komentarze

• Martin - "Komentarze to porażka" - kod ma być self-documenting.
• Ousterhout - Komentarze są kluczowe - wyjaśniają dlaczego i w jakim kontekście.

Złożoność

• Martin - Walcz ze złożonością przez rozbijanie - klasy, metody.
• Ousterhout - Walcz ze złożonością przez enkapsulację (chowaj ją głęboko).

Wyjątki

• Martin - rzucaj wyjątki zamiast kodów błędu. Oddzielaj "happy path" od obsługi błędów tak bardzo, jak to możliwe. Wyjątek to przerwanie, które czyści kod z if-ologii.
• Ousterhout - każdy wyjątek to nowa ścieżka w systemie, którą trzeba zarządzać. Zamiast rzucać wyjątek, spróbuj zaprojektować metodę tak, żeby wynik był poprawny nawet w dziwnych sytuacjach (np. zwrócenie pustego stringa zamiast błędu).

Martina nie czytałem, ale widziałem dużo jego twórczości w internecie. IMO to trochę odklejony dziadzia, który zrobił więcej złego niż dobrego dla branży.

A Philosophy of Software Design (ta z wzorkami na okładce) czytałem. Całkiem dobra książka, IMO dużo bardziej przyziemna i sensowna choć na pewno jest na wyższym poziomie niż to co proponuje Martin.

Martin - skupia się na niej. Metody mają być mikroskopijne (4-6 linii). Jeśli metoda jest długa, to znaczy, że jest "brudna" i wypada ją rozdzielić.

To jest debilizm. Widziałem przykład refaktoru kodu według Martina, który uznał, że dla zachowania tej zasady lepiej wprowadzić stan w klasie, który modyfikują te mikrometody. Do takiego wniosku może dojść tylko osoba, która nigdy nie utrzymywała żadnego kodu

Czytałem zarówno "Clean Code" Martina jak i "A Philosophy of Software Design" Ousterhouta.
Zacznę od tej drugiej pozycji.
Książka w mojej opinii bardzo mocno średnia. Na początku jest faktycznie parę celnych spostrzeżeń na temat designu oprogramowania i złożoności kodu. Jest trafna, w mojej ocenie, kategoryzacja interfejsów programistycznych, podzielone są na tzw. głębokie i płytkie. Autor podaje dość ogólne porady jak projektować kod, aby był łatwy w modyfikacji i utrzymaniu.

Ale im dalej w książkę, tym gorzej.

Cała książka to zbiór mocno ogólnych, powtarzających się porad na temat pisania kodu. Autor w rozważaniach przytacza ledwie trzy, może cztery projekty, przy których brał udział, powołując się na nie przy każdej możliwej okazji. Przykładów z kodem czy refaktorowaniem jak na lekarstwo.
Nie da się nie zauważyć ogromnej autora sympatii do komentarzy w kodzie, którym poświęcił trzy lub cztery całe rozdziały.
Jest też pełno uwag do wspomnianego Clean Code, trochę tak, jakby autor stawiał ją za wzór złych praktyk albo jakby jego książka miała być niejako "odpowiedzią" na Czysty Kod. W zasadzie całe APOSD możnaby zawrzeć w paru kilkustronicowych artykułach n.t. ogólnych porad pisania dobrego kodu.

Co do Clean Code, to można cały osobny temat na forum poświęcić dyskutowaniu sensowności praktyk pisania kodu tam proponowanych i jak się one mają do rzeczywistości, więc może wrzucę swoje doświadczenie z nimi.
Miałem w swojej karierze (nie)przyjemność spotkać apologetów Wujka Boba i jego 2-linijkowych metod. Miałem też nieprzyjemność spotkać klasy liczące po 9000 linii kodu, których dosłownie nikt nie chciał tykać, i na rozbicie których na sensowne, zarządzalne mniejsze części zajęłoby stanowczo za dużo czasu względem budżetu na projekt.
I wniosek mój jest taki, że we wszystkim trzeba mieć umiar
Refaktorowanie klas i ich metod na takie, które mają po max 4 linie i max 2 parametry nie sprawi, że kod będzie łatwiejszy w rozumieniu. Paradoksalnie cognitive load będzie jeszcze większy, będzie więcej "potworków" w stylu metodaKtóraRobiTylkoJednąRzeczIMaBardzoDługąNazwęŻebyTęPierdołęDobrzeOpisać();
Z drugiej strony no jest presja na jak najszybsze wypluwanie kodu-crapu który co prawda robi robotę, ale jest nie do utrzymania i zmiany w przyszłości.

Weźmy kontekst wydania obu książek pod uwagę.
Clean Code wyszedł w 2008 roku. Z mojego prywatnego doświadczenia - ludzie nie przywiązywali wtedy AŻ takiej uwagi do pisania dobrego kodu wtedy jak to robią teraz. Nie było DDD, SOLID, TDD, CQRS i innych śmiesznych skrótów (tj. w założeniach były - a kto używał, ten używał...)

APOSD to książka z 2018 roku, i ani słowem nie wspomina o wyżej wymienionych praktykach. Trochę jakby autor spóźnił się z wydaniem 9 lat i miała ona być niejako polemiką do książki wujka Boba.

Gdybym miał którąkolwiek z nich (i koniecznie z tych 2 książek) polecić - przeczytać Clean Code, ale nie brać wszystkiego "na poważnie" tj. nie stosować się dosłownie do 4 linijkowych metod z max 2 (a może to było 3-ma?) parametrami. Bardziej jako zajawkę, ciekawostkę jak można do programowania podejść inaczej i nie pisać potworków na 10k LOC.

Nie czytałem nic z tego, jedyne do designu to łyknąłem wielką księgę do DDD, a patternów uczyłem się w dyskusjach. Ale wydaje mi się, że jakieś dogmatyczne podejścia są słabe, bo software engineering można zrobić dobrze na rózne sposoby. A wypowiem się tak: dla mnie kod powienien być testowalny i mieć testy ofcors, wtedy i klasę na nk linii się zrefaktoruje:)

Krytykę "Czystego kodu" @Magazyn Programista opublikował, ich artykuł zrecenzowałam zgadzając się z tą krytyką https://4programmers.net/Mikroblogi/View/146146

Dla rozwoju programowania jako zawodu istotne było spisanie zasad dobrego pisania, wzorców projektowych itp. Jest transfer wiedzy od weteranów.

Myślę też, że na pewnym osobistym etapie rozwoju programistycznego warto sięgnąć po tego typu książki.

Ale na pewnym poziomie przestajesz myśleć sztywnymi kategoriami. I zasady mogą sobie istnieć, ale zaczynasz je traktować w bardziej elastyczny sposób, a nie Metody mają być mikroskopijne (4-6 linii).. Chyba że jesteś autorem tych zasad, to wtedy ten fanatyzm ma swoje wyjaśnienie.

Metody mają być mikroskopijne (4-6 linii). Jeśli metoda jest długa, to znaczy, że jest "brudna" i wypada ją rozdzielić.

Tu widzę ukryte założenie, że wiele linijek kodu znaczy, że jest skomplikowana logika. W rzeczywistości dużo linijek kodu może równie dobrze oznaczać dużo prostych warunków (np. gałęzie w switch-case) i może to być proste w rozumieniu i utrzymaniu.

Plus kod może być dość niskopoziomowy i polegać na obsłudze API z dużą ilością boilerplate'u. Np. WebGL czy inne API do przyśpieszonej sprzętowo grafiki. Wtedy normalne jest, że przez kilkadziesiąt linijek kodu nic nie robisz innego, jak tylko inicjujesz jakieś bufory. Nie jest to specjalnie czytelny kod, ale API tego wymaga, inaczej nie napiszesz. Możesz to powydzielać do osobnych metod, obiektów...

...tylko że wtedy zaczniesz pisać wrapper na API i własne abstrakcje. I tu jest problem, bo łatwo można napisać słabe i dość przypadkowe abstrakcje, więc ten "brzydki" kod czasem lepszy (bardziej praktyczny) od tego "ładnego", który cię blokuje. Tak jak Sandi Metz napisała: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Ale na pewnym poziomie przestajesz myśleć sztywnymi kategoriami. I zasady mogą sobie istnieć, ale zaczynasz je traktować w bardziej elastyczny sposób, a nie Metody mają być mikroskopijne (4-6 linii).. Chyba że jesteś autorem tych zasad, to wtedy ten fanatyzm ma swoje wyjaśnienie.

Ja to widzę inaczej. Część dobrych rad np. wspomniane rozbijanie metod jest po prostu z d**y. Programowanie to nie religia i radykalne zasady należy mocno analizować i odrzucać.

Niestety w branży jest mnóstwo szarlatanów, którzy w różny sposób manipulują. Np. Uncle Bob bardzo ludzi cherry-picking pokazując przykłady, gdzie wprowadzenie polimorfizmu zamiast drabinki switchy ma faktycznie sens. To czego ci nie pokaże to odwrotny przykład

Dobre rady są albo oczywiste (np. ograniczenie czasu życia zmiennych albo skrajne przypadky copy-pasty) albo są mocno rozpisane na wiele różnych przypadków w taki sposób, że czytający wie, że problem nie jest oczywisty do rozwiązania.

slsy napisał(a):

Ja to widzę inaczej. Część dobrych rad np. wspomniane rozbijanie metod jest po prostu z d**y.

Rozbijanie na metody jest spoko, ale sama liczba linijek nie jest dobrym kryterium. Prędzej unikanie zbędnej duplikacji kodu, rozdzielenie odpowiedzialności, ale i głos rozsądku, że może nie trzeba wszystkiego kompulsywnie wydzielać i może jedna duża funkcja jest łatwiejsza w utrzymaniu niż logika rozsiana po 10 różnych.

Metody mają być mikroskopijne (4-6 linii).

No i finalnie znaczenie mają większe kawałki kodu niż byle funkcja. Można robić moduły na kilkadziesiąt, kilkaset, a można po kilka tysięcy linijek.

Najlepiej mi się pracuje z kodem, gdzie jeden moduł ma 100-600 linijek kodu. To jeszcze da radę jakoś ogarnąć na raz. Gdzieś koło tysiąca jest mój próg wytrzymałości. Wtedy też widzę, że ten kod mógłby być 2 razy krótszy i robiłby to samo. Albo że warto byłoby to podzielić na mniejsze moduły.

Z kolei nieraz widzę malutkie moduły (np. 50 linijek kodu), które nie zasługują na miano modułu, bo nic nie robią, a są tylko przekierowaniami czy jakimiś przygodnymi utilsami.

Tylko, że jakbym napisał książkę i coś takiego napisał, to jedni by traktowali to niepotrzebnie dogmatycznie, a inni by się kłócili, bo by się nie zgadzali z tymi szacunkowymi i subiektywnymi liczbami.

Swoją drogą Uncle Bob też pisze, że to jego preferencja po prostu:

 In Java I prefer functions that are ~4-6 lines long.  (Thats a preference, not a demand).

https://x.com/unclebobmartin/status/1762864610279821565

LukeJL napisał(a):

Swoją drogą Uncle Bob też pisze, że to jego preferencja po prostu:

Swoją myśl bazuje na jego przykładzie z książki https://theaxolot.wordpress.com/2025/11/18/dont-refactor-like-uncle-bob-second-edition/ , gdzie małe metody są priorytetem ponad zdrowym rozsądkiem.