Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Dlaczego senior pisze banalny kod i po czym poznać juniora

Scott Shipp Senior Software Engineer / Zillow
Sprawdź, dlaczego pisanie skomplikowanego kodu się nie opłaca.
Dlaczego senior pisze banalny kod i po czym poznać juniora

Jeden z moich ulubionych cytatów jest od Briana Goetza, mądrego gościa ze świata Javy, który jest między innymi jednym z autorów Java. Współbieżność dla praktyków. Cytat pojawia się w wywiadzie opublikowanym przez Oracle pod tytułem Pisz prosty kod. Goetz został zapytany, jak napisać kod, który działa dobrze. Oto co miał do powiedzenia:

Często sposobem pisania szybkiego kodu w aplikacjach Java jest pisanie banalnego kodu — takiego, który jest prosty, czysty i zgodny z najbardziej oczywistymi zasadami obiektowymi.

Reszta, około 1000 słów, jest poświęcona wyjaśnieniu, dlaczego próba optymalizacji kodu i próba bycia sprytnym, to powszechne błędy początkującego programisty.

Kod doświadczonego deva

Jeśli tak jak ja, byłeś kiedyś junior devem, może pamiętasz myśl, która pojawiła się, gdy patrzyłeś na kod Seniora: Sam mogę taki napisać. Dlaczego ja nie jestem seniorem?

Mimo to starałem się pisać właśnie taki kod przez długi czas, ale mi to nie wychodziło.

To, co było tak tajemnicze w kodzie senior deva, polegało nie na tym, że go nie rozumiałem, ale że mogłem go zrozumieć natychmiast. Był wręcz idiotycznie prosty i wydawało mi się, że musi za tym stać coś więcej. Gdzie jest reszta? Zastanawiałem się. Jak on to wszystko to robi?

Od tamtej pory nauczyłem się wszystkich nazw zasad i cech kodu, które sprawiają, że jest właśnie banalny: YAGNI, Zasada Pojedynczej Odpowiedzialności, DRY, Zasada Pojedynczego Poziomu Abstrakcji, niski coupling itp. Tak oto zostałem senior devem. (Właściwie nienawidzę tego określenia “senior dev” i odnoszę się do siebie wyłącznie jako “inżynier oprogramowania" ale to historia na inny raz).

Najważniejsza lekcja, jakiej się nauczyłem, to fakt, że pisanie głupiego kodu jest naprawdę trudne, ale i ostatecznie opłacalne.

Jak rozpoznać junior deva z daleka

W książce Refaktoryzacja: Ulepszanie struktury istniejącego kodu, Kent Beck mówi:

Każdy głupek może napisać kod, który jest zrozumiały dla komputera. Dobrzy programiści piszą kod, który jest zrozumiały dla ludzi.

Zawsze rozpoznasz pracę junior deva, gdy natrafisz na kod pełen sprytnych pojedynczych linii kodu, Dziwacznych abstrakcji i/lub masy funkcji języka. Powiedziałbym, że to drugie jest całkiem powszechne. To tak, jakby kod próbował krzyczeć: Spójrz na mnie! Mój twórca naprawdę zna język! Używam zsynchronizowanych z domyślnym interfejsem lokalno-wątkowych konstruktorów kopiujących JavaBean z niestandardowymi nieoznaczonymi wyjątkami generycznymi i międzyfunkcyjnym generowaniem super bezpiecznego kodu Lombokiem.

Tak, ten bełkot to nonsens, ponieważ właśnie w nonsens zamienia się kod, gdy jest w rękach kogoś, kto myśli wyłącznie o zmartwieniach komputera, a nie ludzi.

Programowanie polega na komunikowaniu się z innymi ludźmi i jednocześnie przekazywaniu instrukcji komputerowi, ale ostatnio znacznie za dużo w tym tego drugiego. Kompilator zajmuje się tłumaczeniem tego, co programiści piszą w języku maszynowym. Często istnieje kilka warstw tego tłumaczenia, np. gdy Java jest kompilowana do byte code’u, który jest odczytywany przez wirtualną maszynę Javy podczas jej odpalenia. To ostatecznie przekłada się tylko na zera i jedynki.

Jednak kod jest językiem ludzi. Musi przekazać takie informacje, jak: kto, co, kiedy, gdzie, jak i dlaczego, a nie tylko instruować komputer. Musi mieć sens i być zrozumiały również za pięć lat, gdy firma zostanie przejęta i zupełnie nowy zespół, który nigdy wcześniej nie widział tego kodu, będzie musiał go otworzyć, ulepszyć lub naprawić błąd.

Podsumowanie

Tak, pisanie banalnego kodu jest trudne. Osobiście czuję, że z upływem czasu wychodzi mi to coraz lepiej. Jestem zadowolony, gdy otrzymuję komentarze typu “Ale czysty kod!” w recenzjach mojej pracy. Wiem, że najlepszą rzeczą, jaką mogę zrobić dla mojego zespołu i przyszłych opiekunów kodu, jest napisanie go w banalny sposób.

Dla zabawy zostawię Was na koniec ze słowami Dave’a Carharta:

Zawsze pisz taki kod, jakby koleś, który miał go czytać i serwisować, był brutalnym psychopatą, który wie, gdzie mieszkasz.


Oryginał artykułu w języku angielskim możesz przeczytać tutaj.

Masz coś do powiedzenia?

Podziel się tym z 120 tysiącami naszych czytelników

Dowiedz się więcej
Rocket dog