Czysty kod w C++. O czym powinien wiedzieć każdy programista? Devdebata

Kiedy poznać zasady czystego kodu? W jaki sposób najlepiej przyswoić wiedzę: poprzez poprawianie swojego czy czyjegoś kodu? Jakie korzyści przynosi dbanie o czysty kod? Na te i na wiele innych pytań odpowiedzieli zaproszeni programiści, którzy podzielili się swoimi doświadczeniami.

Zdaniem Tomasza Kozika, zasady pisania czystego kodu należy wdrożyć, gdy nasz kod przestaje być tzw. radosną twórczością, poznawaniem podstaw języka programowania, a zaczynamy dla celów nauki przygotowywać projekty realizujące jakąś funkcjonalność. – Zwłaszcza kształcący się we własnym zakresie powinni uważać, by nie przegapić właściwego momentu. Jako samouk musiałem nadrobić tę zaległość – powiedział nam Tomasz, Software Developer w Ericsson. O zasadach czystego kodu więcej dowiecie się z poniższej devdebaty.

W devdebacie udział wzięli:

• Michał Rad. Instruktor w Learning Service Delivery. W Ericsson/Ericpol od 2015 roku, prowadzi szkolenia z C, C++, Erlanga, Perla, Pythona. Doświadczenie: od aplikacji na mikrokontrolery jednoukładowe po programy pomiarowo – obliczeniowe dla użytkownika końcowego. Pracuje także na AGH zarówno naukowo, jak i prowadząc zajęcia z tematów informatycznych.
• Krystian Jóźwiak. Software Developer w Ericsson od 5 lat. W firmie zajmuje się rozwojem i utrzymaniem kontrolera ruchu w sieci komórkowej 3G. Doświadczenie zbierał na pisaniu gier tekstowych oraz majsterkowaniu z elektroniką, co wciąż robi chętnie w wolnym czasie po pracy. Uwielbia spędzać czas przy grach planszowych oraz rozwiązywać różnego rodzaju zagadki, nawet jeśli dotyczą niedziałającego kodu.
• Paweł Szczudło. Senior Software Developer w Ericsson. Zajmuje się symulatorem telekomunikacyjnym, na studiach jednak najbardziej pasjonował się programowaniem robotów. Przebrnął pełną drogę od Juniora do Seniora, z dodatkowym epizodem w roli Scrum Mastera. Podobno każde rozwiązanie problemu zaczyna od kartki i ołówka, a za najważniejsze uważa branie odpowiedzialności za wyniki swojego kodu.
• Tomasz Kozik. Software Developer w Ericsson od listopada 2018. Zajmuje się maintenance‘em kodu produktu w dziale zarządzania sprzętem w stacjach bazowych telefonii komórkowej. Samouk, wprawę w pisaniu w C++ zdobywał pisząc programy do opracowywania danych, optymalizacji i obliczeń pod kątem prac dyplomowych i pracy naukowej na AGH. Fan gier planszowych i komputerowych. Nie musząc już balansować pracy ze studiami doktoranckimi, niedawno ukończonymi, nadal szuka nowych zainteresowań.

1. W jaki sposób najlepiej poznawać zasady czystego kodu? Junior powinien poprawiać swój czy czyjś kod – co go więcej nauczy?

Paweł Szczudło: Najlepszą metodą na poznanie zasad czytelnego kodu jest wzorowanie się na otoczeniu. Rzadko kiedy młody programista (w sensie niedoświadczony) otwiera pusty plik w próżni i zaczyna pisać, także zawsze gdzieś w zasięgu ręki są “dobre przykłady”.

Duże firmy mają zazwyczaj dokumenty opisujące sposób, w jaki należy formatować kod więc warto od tego zacząć. Literatura programistyczna, zawarte w niej przykłady, są napisane z reguły w czysty sposób, także warto nie tylko zwracać w nich uwagę na to, co jest napisane, ale również jak jest napisane.

Młodzi są oceniani od momentu przyjścia na rozmowę rekrutacyjną, przez miesiąc próbny i dalej przez całą karierę. Ich startowe stanowisko to junior software developer, mówi się do młodych “junior”, co zazwyczaj tylko motywuje do awansu i pozbycia się tego przedrostka.

Rozmawiam czasem z młodymi ludźmi, jeszcze na studiach i najbardziej ich interesuje co zrobić, na czym się skoncentrować, aby szybko wejść na wysokie obroty zawodowe. Wtedy właśnie pojawia się temat czystego i spójnego kodu, pisania testów i dokumentacji. Tego wszystkiego czego te młody gwiazdy devRocka nie biorą w ogóle pod uwagę, myśląc o obowiązkach programisty.

Krystian Jóźwiak: Sądzę, że zarówno poprawianie swojego kodu, jak i wzorowanie się na cudzym jest wartościowe dla programisty, co podkreślił Paweł. Przeglądając własne skrypty napisane przykładowo pół roku wcześniej, można zauważyć trudność w czytaniu kodu źródłowego lub jego adaptacji do nowych potrzeb, jeśli pominięte zostały zasady pisania czystego kodu. Wystąpienie takiej sytuacji często kończy się koniecznością ponownej implementacji funkcjonalności. Warto, aby młody programista wyciągnął z tego wnioski i uczył się na własnych błędach.

Tomasz Kozik: Zdarzyło mi się musieć przepisać od początku jeden ze swoich własnych programów ze względu na niewystarczające zastosowanie się do zasad czystego kodu. Zaimplementowanie kolejnej funkcjonalności okazało się niemożliwe ze względu na zbyt zagmatwany design. Takie doświadczenie jest bardzo cenne dla rozwoju i rozumienia idei pisania czystego kodu. Z drugiej strony, patrząc w cudzy kod ma się mniejsze opory przed wskazywaniem i poprawianiem miejsc, w których przestrzegania tych zasad zabrakło. W obu sytuacjach dobrze jest się kiedyś znaleźć.

2. Tak samo jest w przypadku mida i seniora? Także powinni uczyć się na swoim czy na cudzym kodzie?

Krystian Jóźwiak: W przypadku osób bardziej doświadczonych bardziej pomoże nauka na cudzym kodzie. Takie osoby etap nauki na swoich błędach mają częściowo za sobą, więc więcej czasu spędzają nad przemyśleniami dotyczącymi implementacji. Dodatkowo wyrabiają sobie własny styl, który z reguły zawiera kilka zasad pisania czystego kodu, które są uniwersalne i niezależne od stosowanego języka programowania. To z kolei może spowodować swego rodzaju zamknięcie się w swojej strefie komfortu, z czego wyrwać może właśnie przeglądanie cudzych prac oraz kolaboracja z innymi.

Paweł Szczudło: Tutaj dodam, że powyżej juniora oczekuje się samodzielności, jak i weryfikacji poczynań innych, ale to nie znaczy, że trzeba być Zosią Samosią. Czasem można patrzyć w swój kod godzinami i pewnych rzeczy nie zauważać, więc zwracanie się do innych o weryfikacje tuż przed wrzutą do kodu nie jest żadną ujmą na honorze. W ten sposób obie strony uczą się i szlifują wiedzę, przy okazji pomagając sobie nawzajem. W naszym projekcie jest to nawet wpisane w „way of working”.

Michał Rad: Dodam tylko, że dla osób z nieco większym doświadczeniem oglądanie fatalnych kodów też może przynieść dobre efekty – będzie to uczenie przez kontrprzykład.

Tomasz Kozik: Choć stwierdzenie to słyszy się często, nauka to proces, który nigdy nie ustaje. Jak w poprzednim punkcie, zdobywanie wiedzy i doświadczenia na oba sposoby jest wartościowe, niezależnie od stopnia zaawansowania.

Oferty pracy z

3. Co gdy mid czy senior zaczyna pisać w C++, ale ma złe nawyki?

Michał Rad: Odpowiem żartobliwie: jeśli nawyki są faktycznie fatalne to nie robić nic, jest szansa na dobry wynik w konkursie na najbardziej nieczytelny kod. Takie konkursy są organizowane. Dla C jest to: Obfuscated_C_Code_Contest. Może dla C++ też jest taki konkurs?

Paweł Szczudło: Za każdym razem, gdy będzie wracał do kodu, poczuje swoje błędne podejście. W wieloosobowych projektach otoczenie nie pozwoli mu na kontynuowanie samowolki. Review kodu są powszechne, nie da się przed nimi uciec.

Tomasz Kozik: Rozwiązaniem takiej sytuacji jest proces code review, choć stopień jego praktykowania, rozbudowania i sformalizowania bywa różny. Tak jak podkreślił Paweł w poprzednim pytaniu, jest to okazja nie tylko do poprawiania nie dość czystego kodu, ale też okazja do wymiany wiedzy i doświadczeń. Bywa, że proces ten budzi emocje (100 komentarzy do 10 linijek kodu nie są najprzyjemniejszym widokiem z rana), ale w rozmowie można na spokojnie wymienić opinie, zmienić zdanie, nauczyć się lub kogoś czegoś nowego. Takie dyskusje rodzą też przemyślenia na temat utartych praktyk, które się przyjęły, a które niekoniecznie są czystym kodem. Warto dbać o code review, może być czymś o wiele lepszym i pożyteczniejszym niż się wydaje.

4. Przy rozmowie o czystym kodzie trudno pominąć kwestię czasu. Lepszy szybki, ale niechlujny kod czy ten pisany kilka razy wolniej, ale dokładniej?

Paweł Szczudło: Szybki, tymczasowy kod ma to do siebie, że lubi wedrzeć się do kodu produktowego. Późniejsze przepisywanie go zajmuje zdecydowanie więcej czasu niż pisanie go w poprawny sposób od początku. Dlatego dobrą praktyką jest trzymanie się ustalonych zasad od początku pracy z kodem, nawet w fazie prototypowania.

Michał Rad: Pokusa pisania “na szybko”, bez dbałości o czystość, jest często silna, ale z mojego doświadczenia wynika, że pisząc niechlujnie w efekcie końcowym tracimy dużo więcej czasu, niż pisząc od razu poprawnie. Pisząc “z mojego doświadczenia” mam na myśli fakt, że sam często traciłem wiele czasu na czyszczenie kodu albo – co gorsza – na znajdowanie błędów wynikających z niechlujności. Niestety, nie jestem osobą, która od początku miała nawyk czystego pisania – ten nawyk staram się cały czas w sobie kształtować.

Krystian Jóźwiak: W pełni zgadzam się z Pawłem i nie ukrywam, na początku mojej przygody z programowaniem zdarzało mi się ignorować dobre praktyki z powodu presji czasu. Efekt był dokładnie taki, jak opisał Michał – jeszcze więcej czasu stracone na przepisywaniu kodu. Być może nie sposób przewidzieć wszystkie przyszłe zastosowania kodu, ale warto poświęcić czas na przemyślenie implementacji, tak aby w ogólnym rozrachunku go zaoszczędzić.

Tomasz Kozik: Popieram przedmówców. Można to też ująć w następujący sposób: nie da się kupić czasu (krótszego na implementację funkcjonalności) za cenę jakości kodu, choć niektórzy tak myślą. Tak naprawdę, kupując w ten sposób czas, zaciąga się na ogół tzw. dług techniczny (choć przyczyną jego powstawania jest nie tylko brak czystości kodu). Od długu ktoś kiedyś zapłaci odsetki i spłaci sam dług, i stanie się to za cenę czasu.

Dopisując z czasem kolejne funkcjonalności do niewystarczająco czystego kodu, trzeba będzie się dostosować (jeśli nie poprawi się po poprzednikach, znowu za cenę czasu), co może mieć negatywny wpływ na design i być czasochłonne. W najczarniejszym scenariuszu koniec końców do zaniedbanego kodu nie będzie dało się dopisać kolejnej funkcjonalności i trzeba będzie poświęcić czas na spłatę długu – refactoring kodu.

5. Jakie Tobie korzyści przyniosła dbałość o czysty kod?

Michał Rad: Trudno tutaj podać konkretny przykład, ale odpowiem tak: słyszałem wypowiedzi młodych ludzi w stylu: “Oj bardzo dawno nie programowałem w języku X, ostatni raz chyba miesiąc temu”. Mnie zdarza się wracać do kodu sprzed kilku lat – jeśli zapisany był czysto, sprawa jest prosta. Jeśli nie – lepiej napisać od nowa.

Paweł Szczudło: Młodzi to uwielbiają dywagować na tematy pokroju ++i++, które z punktu widzenia osoby doświadczonej mogą być nawet “głupie”, zamiast odrzucić taki kod ze względu na jego nieczytelność (abstrahując, czy się w ogóle skompiluje). Tym właśnie się różni nowicjusz od starego wygi – świadomością, że najwyższą wartością kodu nie jest to, że działa, ale czy jest łatwo rozwijalny.

Ciężko jest podać taki namacalny przykład korzyści płynącej z czystego kodu. Jeśli jednak wszyscy w projekcie piszą z użyciem wspólnych zasad, to każdy kod w projekcie wygląda jak nasz własny, dzięki czemu łatwiej i szybciej się go analizuje.

Tomasz Kozik: Paweł bardzo trafnie to ujął, rozwijalność jest bardzo ważnym aspektem kodu. Czystość kodu jest jedną z cech, która może mu tę rozwijalność zapewnić. Osobiście, dbanie o czystość kodu ułatwiło mi dzielenie funkcjonalności na odrębnie dostarczane fragmenty. Łatwo rozwijać i wpisywać się w przejrzysty schemat.

6. Jak zachęciłbyś juniora do poznawania zasad czystego kodu?

Paweł Szczudło: Ktoś, kto aplikuje, powinien potrafić pisać w czysty i zrozumiały sposób i to jest wymóg – o ile pojawiają się zadania praktyczne w procesie rekrutacji. Nie jest też tak, że wymaga się konkretnych zasad bo te przecież mogą być różne.

Przy rekrutacji nowego kandydata brana jest również pod uwagę jego konsekwencja w pisaniu kodu. Jeżeli jego składnia np. dla instrukcji “if” jest nawet najbardziej patologiczna, to o ile stosuje ją wszędzie w taki sam sposób, czyli stosuje jakąś zasadę i prawdopodobnie dostosuje się do nowych.

Można śmiało postawić tezę, że ramię w ramię z umiejętnością pisania czystego kodu idzie biegłość w pisaniu go w ogóle.

Krystian Jóźwiak: Warto, aby taki junior podczas pracy w projekcie miał swojego mentora, który nakierowałby go na dobre praktyki, sugerował zmiany. Myślę, że pokazanie juniorowi, jakie korzyści daje czysty kod na jego własnym kodzie, jest najlepszą zachętą do poznania i stosowania zasad. Poza tym, jak wspomniał Paweł, należy się dostosować do zasad już istniejących w projekcie. Natomiast osoby na samym starcie swojej nauki, jeszcze przed zatrudnieniem, mogą mieć problem, jeśli nie mają kogoś znajomego w formie mentora.

Sam zauważam, że w przykładach opisujących start z jakąś technologią, brakuje wskazówek dla zupełnie początkujących. Oczywiście, większości czytelników nie będą one potrzebne, ale skąd osoba rozpoczynająca naukę ma wiedzieć, że istnieje coś takiego jak zasady czystego kodu? Podczas nauki można spotkać przykłady zarówno dobre, jak i złe, więc można już na starcie złapać niewłaściwe nawyki.

Michał Rad: Zgadzam się z przedmówcami. Dodam jeszcze, że mnie nikt nie zachęcał – wystarczyła sytuacja, w której miałem na szybko wykonać drobne zmiany we własnym kodzie napisanym rok wcześniej.

Tomasz Kozik: Sądzę, jak wszyscy się wcześniej zgodzili, że poznawanie zasad czystego kodu powinno się rozpocząć na etapie nauki programowania, jeszcze przed podjęciem pracy. Niemniej, jeśli trzeba na jakimkolwiek etapie nadrobić wiedzę z zakresu czystego kodu, to sądzę, że wszystkie udzielone w tej debacie wypowiedzi stanowią zachętę.

---

Zdjęcie główne artykułu pochodzi z unsplash.com.