Najpierw problem. Potem rozwiązanie. Na końcu konsekwencje. Kod bez dogmatów

Question

20+ lat programowania, kilkanaście lat za granicą, doświadczenie jako Senior Developer, Lead Developer i Software Architect i zamiast kolejnego kanału z 5 zasadami dobrego kodu postanowiłem zrobić eksperyment.Zaczynamy niewinnie i tworzymy potwora.

Od dłuższego czasu chodziła mi po głowie pewna rzecz. W programowaniu bardzo często słyszymy, jak coś robić:

używaj tego wzorca, stosuj tę zasadę, tego nie rób, to jest clean, to jest bad practice...

Tylko że w prawdziwych projektach odpowiedź rzadko jest aż tak prosta.

Po ponad 20 latach programowania, pracy jako Senior Developer, Lead Developer i Software Architect, również w dużych projektach i za granicą, coraz bardziej interesuje mnie nie samo rozwiązanie, ale dlaczego zostało wybrane i jakie będą jego konsekwencje.

Dlatego postanowiłem zrobić mały eksperyment i stworzyć kanał Kod bez dogmatów. Nie chcę zaczynać od:

„Dzisiaj nauczymy się wzorca X i pokażę Wam, jak go poprawnie zastosować.”

Chcę zrobić odwrotnie.

Najpierw pojawia się problem. Potem szukamy rozwiązania. A na końcu sprawdzamy jego konsekwencje.

W pierwszej serii budujemy od zera prosty projekt pizzerii. Zaczynamy od kilku pizz, a następnie dokładamy kolejne wymagania i obserwujemy, jak nasze wcześniejsze decyzje wpływają na dalszy rozwój programu.

Poziom trudności będzie rósł razem z projektem. Początek jest celowo prosty i powinien być przystępny również dla osób, które dopiero zaczynają swoją przygodę z programowaniem. Z każdym kolejnym wymaganiem kod będzie jednak coraz bardziej złożony, więc z czasem pojawią się tematy, które będą interesujące również dla bardziej doświadczonych programistów i architektów.

Jeżeli chcecie, możecie budować ten projekt razem ze mną. Kod jest dostępny na GitHubie, a każdy odcinek ma przypisaną konkretną wersję projektu. Dzięki temu możecie pobrać dokładnie ten stan kodu, który widzicie w danym odcinku, i samodzielnie wykonywać kolejne kroki razem ze mną.

Nie chcę jednak od początku budować „idealnego” rozwiązania. Wcielamy się w programistę, który jest już całkiem dobry, ale jeszcze nie ma doświadczenia, które pozwala mu przewidzieć wszystkie konsekwencje swoich decyzji.

Chcę zobaczyć, czy uda się w ten sposób pokazać coś, czego często brakuje w typowych materiałach programistycznych — proces myślenia stojący za decyzjami.

A kiedy z prostego projektu zrobimy potwora, spróbujemy zobaczyć, czy i jak można go z niego wyciągnąć.

Kod bez dogmatów:
YouTube — https://www.youtube.com/@kodbezdogmatów

Pierwszy odcinek:
https://youtu.be/g8HmtqRasOM

Kod źródłowy w opisie filmu.

Nie tylko jak. Przede wszystkim dlaczego.

Comments

Świetny pomysł, odzwierciedla mój punkt widzenia. Czy można będzie liczyć na jakiegoś bloga tekstowego w przyszłości?

---

Witam. O blogu nie myslalem , ale na pewno, jak bedzie wiecej osob na kanale, to chetnie bede robil regularnie Streamy na zywo, gdzie bedziemy dyskutowac.

Z tym blogiem to zart prawda? :)

Answer 1

W programowaniu bardzo często słyszymy, jak coś robić:

używaj tego wzorca, stosuj tę zasadę, tego nie rób, to jest clean, to jest bad practice...

Tylko że w prawdziwych projektach odpowiedź rzadko jest aż tak prosta.
 

Tak było kiedyś, teraz masz AI i gotowe narzędzia, setki agentów itd., te narzędzia/Ci agenci itd. są wstanie poprawnie przez to Cię przeprowadzić, robiąc dokładnie to, co jest wymagane, co jest potrzebne i odpowiednie, oszczędzając czas, błędy, nawet jednocześnie objaśniając, dlaczego coś na danym etapie jest pomijane, dodatkowo nie trzeba  zastanawianie się i marnować czas nad optymalizacją "optymalizowania", teraz to takie "premature optimization".

I nie mam tu na myśli generowania kodu, a realnie planów i realizacji biznesowych, odpowiedzi na problemy technologiczne i projektowe, analizę danych zwykłych, statystycznych, czy analizy naukowej wraz z opracowaniem sposobu rozumowania. Natomiast jako osoba  mająca +20 lat doświadczenia w branży, idąca z duchem czasu i rozwojem, celem biznesowym w jakim aktualnie idą firmy IT, powinieneś dobrze to wiedzieć 
O ile sam mam +12 lat w IT, to widzę, że wiele osób, starych wyjadaczy, próbuje wrócić do podstaw, jakoby z sentymentu, czy tęsknoty za latami, kiedy takie rzeczy były ważne i istotne, a już nie są, a jeśli są, to automatycznie są robione, szczególnie widać to po interview, gdzie CV i papier przyjmuję wszystko, nawet to 20+ lat w IT, a wiedza, zatrzymała się na etapie kompilacji i uruchamiania serwerów manualnie ( pytanie: po co uczyć się czegoś, potrafić coś, co jest już totalnie niepotrzebne i nigdy nie będzie, tylko dla zasady, że kiedyś było bardzo istotne) 

Comments

Tak było kiedyś, teraz masz AI i gotowe narzędzia, setki agentów itd., te narzędzia/Ci agenci itd. są wstanie poprawnie przez to Cię przeprowadzić, robiąc dokładnie to, co jest wymagane, co jest potrzebne i odpowiednie, oszczędzając czas, błędy, nawet jednocześnie objaśniając, dlaczego coś na danym etapie jest pomijane, dodatkowo nie trzeba  zastanawianie się i marnować czas nad optymalizacją "optymalizowania", teraz to takie "premature optimization".

Po czym patrzę, jak po 40 minutach mielenia Opus podjął bezsensowne decyzje projektowe i dopisał do tego wyhalucynowane testy oraz kod, który nie obsługuje prostego przypadku, jaki jestem w stanie wymyślić od ręki ¯\_(ツ)_/¯

AI to jest tylko narzędzie i zwracają uwagę na to nawet osoby siedzące bezpośrednio przy rozwijaniu takich systemów, np. Addy Osmani nieustannie powtarza o potrzebie "human in loop" czy o smaku. I oddawanie całego procesu AI jest IMO głupotą. Bo ostatecznie odpowiedzialność za wszystko i tak ponosi człowiek – Claude'a nikt nie zwolni ani nie wsadzi do więzienia.

---

Zastanawiam sie gdzie popelnilem blad, ze cel mojego kanalu nie zostal zauwazony. Odnosnie KI nie wiem jakich ty uzywasz ja uzywam w pracy
ChatGpt, Copilot i Codex. Zadna z tych KI nie jest w stanie wygenerowac, kod na dobrym poziome architektury uwzgledniajac nie tylko wzorce dla konkretnego przypadku, czy zasady SOLID, one sie gupia juz pryz pierwszej zasadzie SOLID. Przy skomplikowanach Use Casach generuja taki Overhead a nawet Overhead Boilerplate :) ze nie jeden poczatkujacy z np. SRP zrobilbym to lepiej. Niewazne, jak dlugo jej i dokladnie opisujesz kontext, nie zrobi tego poprawnie. I to jest cel tego kanalu.

Dygresja: Tu mamy podobna wizje. Za kilka lat bedzie programowanie raczej z prompta, ale dla skomplikowanych systemow, bedzie wymagany zawsze programista, ktorz bedze robil Review tego co wypluje KI i bedzie to dopasowywal, ale prompt i skille KI. Pytanie, ktore ja sobie zadaje, jest w cenie beda wtedy programiscie srednio zaawansowani, czy zaawansowani i architekci. Srednio zaawansowany ogarnia i jest tanszy niz ci 2 pozostali. Ciekawe czasy nas programistow czekaja!

Dziekuje za Feedback i pozdrawiam.

---

Chodzi o tok myslenia moj przyjacielu, zapraszam ponownie, jak bedzie refaktoryzacja, tego "dziela". Kod jest dostepny, jak bede juz na tym etapie, mozemy sprobowac porownac, ta refaktoryzacje, ktora ty zrobisz z AI i moja. Byloby to ciekawe doswiadczenie. Pozdrawiam.

Answer 2

Nie mogę się z tym nie zgodzić:

20+ lat programowania, kilkanaście lat za granicą, doświadczenie jako Senior Developer, Lead Developer i Software Architect i zamiast kolejnego kanału z 5 zasadami dobrego kodu postanowiłem zrobić eksperyment.Zaczynamy niewinnie i tworzymy potwora.

 

Często, tak jak piszesz, powstaje bestia / komuch / potwór / UBywatel..... :)

Comments

Jeszcze nie wiesz jak ja pisze kod, narazie widziales jak pisze kod poczatkujacy programista, w ktorego sie wcielilem. Po tym weekendie skonczy sie ta seria i zacznie seria z wieloma wymaganiami, wtedy powstanie prawdziwy potwor. Wtedy zaczne refaktorowac juz jako ja. Zapraszam.