Mentionsy

DevStarter
DevStarter
27.04.2026 10:09

Jak dbać o swój kod źródłowy — nawyki i praktyki, które robią różnicę

W dzisiejszym odcinku bierzemy na warsztat fundament pracy każdego dewelopera, czyli dbanie o kod źródłowy. Choć nagrywaliśmy go „na wariackich papierach” i walcząc z uciekającym głosem, udało nam się skondensować konkretną wiedzę w 40-minutowej pigułce. Odpowiadamy na pytanie: jak pisać kod, który nie będzie wstydem dla Ciebie i udręką dla zespołu?

W tym odcinku dowiecie się:

dlaczego kod należy pisać dla ludzi, a nie tylko dla maszyn,jakie codzienne nawyki i podejście do code review realnie podnoszą jakość projektów,kiedy refaktoryzować, a kiedy odpuścić, by nie wpaść w pułapkę perfekcjonizmu,jak junior może ocenić swoją pracę, gdy w zasięgu wzroku nie ma mentora,w jaki sposób AI może stać się Twoim prywatnym strażnikiem czystego kodu.

Ogromne dzięki za Wasz feedback po debiucie! Część sugestii już wdrożyliśmy i obiecujemy, że to dopiero początek podnoszenia poprzeczki. Przesłuchał_ś odcinek do końca? Podziel się swoją opinią – każda uwaga pomaga nam tworzyć lepszy content!

Napisz do nas! [email protected]

Prowadzący: Radek Wojtysiak

linkedin: https://www.linkedin.com/in/radekwojtysiak/ instagram: https://www.instagram.com/karieradevelopera/

Cezary Sanecki:

linkedin: https://www.linkedin.com/in/cezary-sanecki/ instagram: https://www.instagram.com/cezary.sanecki/

Realizacja i montaż: Cezary Sanecki

Rozdziały (10)

1. Wprowadzenie i motywacja

Podcast DevStarter zaczyna rozmowę o znaczeniu dobrego kodu źródłowego i praktyk, które pomagają w komunikacji za pomocą kodu.

2. Analiza jakości kodu jako tekstu czytelnego przez ludzi

Radko i Cezary omawiają znaczenie jakości kodu dla innych programistów i sztucznej inteligencji, podkreślając potrzebę czytelności i zrozumiałości.

3. Zastosowanie sztucznej inteligencji w refaktoryzacji kodu

Radko opisuje swoje doświadczenia z korzystaniem z sztucznej inteligencji do generowania i poprawiania kodu, podkreślając humanistyczny podchód.

4. Formatowanie kodu i code review

Radko i Cezary omawiają korzyści i problemy z użyciem narzędzi do code review i refaktoryzacji, podkreślając znaczenie guideline i narzędzi do automatycznego sprawdzania.

5. Refaktoryzacja kodu i priorytety

Rozmowa o refaktoryzacji kodu, priorytetach i subtelności decyzji dotyczących jakości kodu.

6. Doświadczenie z refaktoryzacją

Podzielenie się własnymi doświadczeniami z refaktoryzacją kodu i błędnymi przekonaniami.

7. Oceniać jakość kodu

Rozmowa o korzystaniu z AI w procesie refaktoryzacji i konwencjach kodowania.

8. Nawyki i praktyki

Porady dotyczące wprowadzania nowych nawyków i praktyk dotyczących jakości kodu.

9. Solid, Dry, Yagni

Korekta tematu Solid, Dry, Yagni i propozycja dalszych rozważań na ten temat.

10. Podsumowanie i zakończenie

Podsumowanie odcinka i dziękowanie słuchaczom, zaproszenie do podania opinii.

Szukaj w treści odcinka

Znaleziono 7 wyników dla "formater"

I niestety na takie rzeczy, albo stety nawet, mamy już wypracowane rozwiązania, jakieś lintery, formatery.

Możemy przecież w jakimś naszym kroku w CI poprosić, żeby właśnie jakiś linter, jakiś formater nam to wszystko ładnie ustrukturyzował tak, żeby dostosować się do konwencji, które zawarliśmy w zespole.

I to jeszcze był czas, kiedy te lintery, o których wspomniałeś, czy tam formatery, jeszcze nie były też takie popularne.

Jeszcze teraz jak mamy AI, to możemy mu po prostu powiedzieć wprost słowami po polsku, że chcemy, żeby wyglądał to, żeby ten formater wyglądał tak, a nie inaczej.

Czasami wyłapuje też takie rzeczy typu właśnie formatery, ale czasami potrafi zadać takie niewygodne pytania, które zaczynają nam otwierać jakieś dodatkowe klapki na to, czego nie dostrzegliśmy i w ten oto sposób możemy wyłapywać jakieś dodatkowe corner case'y, żeby ten model był dużo, dużo lepszy do wymagań, które zostały nam

Bo tutaj też w sumie o tym nie powiedzieliśmy, bo mówiliśmy tylko o formaterach, mówiliśmy o linterach.

Ale też ta konfiguracja jest bardzo ważna, a mianowicie, jeżeli dany, nie wiem, linter czy formater znajdzie błąd, nazwijmy to krytyczny w cudzysłowie, no to niech on tego nie poprawia, niech nie próbuje sam poprawić, tylko niech zgłosi, że to jest błąd, który programista powinien rozwiązać, a wszystkie te takie małe rzeczy, właśnie jakieś spacje, czy tam jakieś entery, niech robi, nawet niech nie pyta, tylko niech o tę jakość po prostu dba.