To jedna z najgorszych rad, jakie możesz usłyszeć na początku nauki programowania.
Kiedy zaczynałem studia, moja definicja sukcesu przy każdym projekcie była bardzo prosta – dowieźć wynik. Program się kompiluje? Konsola wypluwa to, o co prosił prowadzący na zajęciach? Świetnie, zamykam IDE, można iść na kawę. Jeśli coś działało, nie zadawałem pytań.
Problem w tym, że takie podejście działa tylko do pierwszej próby rozbudowania aplikacji.
Zrozumiałem to dość szybko przy jednym z pierwszych projektów. Teoretycznie wszystko było skończone. Chciałem tylko dodać małą zmianę, poprawić jeden warunek, nic poważnego. Miało to zająć kilkanaście minut. Skończyło się na tym, że po pół godzinie patrzyłem na błędy, których nawet nie bardzo wiedziałem, jak szukać.
Szybko wyszło na jaw, że mój kod był bardzo kruchy. Jedna drobna zmiana wystarczyła, żeby coś przestało działać w zupełnie innym miejscu. Zamiast rozwijać projekt, spędziłem wieczór na cofnięciu zmian i próbach zrozumienia, co właściwie się stało.
Wtedy dotarło do mnie coś prostego. kod, który się uruchamia, to nie to samo co kod, który jest dobrze napisany.
Na początku łatwo to przeoczyć. Skoro wszystko działa, to gdzie problem? Problem pojawia się dopiero przy zmianach. Nagle okazuje się, że nie do końca wiesz, po co istnieje dany fragment, co robi konkretna zmienna albo jakie skutki będzie miało jej usunięcie. Każda modyfikacja zaczyna wymagać zgadywania zamiast świadomej decyzji.
Uczelnia szybko to weryfikuje. Sklejanie fragmentów kodu znalezionych w internecie bez ich zrozumienia działa tylko przez chwilę. Prędzej czy później trafiasz na zadanie albo projekt zespołowy, gdzie bez podstaw nie jesteś w stanie iść dalej.
Dochodzi jeszcze jedna rzecz, kod prawie nigdy nie jest pisany tylko dla siebie. Nawet na studiach ktoś go czyta, kolega z grupy, prowadzący, a czasem Ty sam po kilku dniach. I wtedy łatwo zobaczyć, czy jest zrozumiały, czy tylko „działa”.
To był moment, w którym zacząłem zwracać uwagę na czytelność. Nazwy zmiennych, podział na funkcje, ogólna struktura to nie są detale. To rzeczy, które decydują o tym, czy do tego kodu da się wrócić i coś w nim zmienić bez chaosu.
Musiałem też zmienić sposób myślenia. Zamiast pytać „czy działa?”, zacząłem pytać „dlaczego to działa?”. Przyjąłem prostą zasadę – jeśli nie potrafię w kilku zdaniach wyjaśnić swojego rozwiązania, to znaczy, że jeszcze go nie rozumiem.
Z czasem doszło do tego kolejne pytanie: „co się stanie, jeśli coś tu zmienię?”. To podejście mocno porządkuje pracę. Zamiast działać metodą prób i błędów, zaczynasz przewidywać skutki.
Zmieniło się też moje podejście do błędów. Na początku każdy komunikat w konsoli oznaczał chaos i szukanie rozwiązania na oślep. Teraz traktuję to jako wskazówkę. Sprawdzam, gdzie pojawia się problem i co mogło go spowodować. Debugowanie przestaje być zgadywaniem, a zaczyna być analizą.
Co ciekawe, takie podejście wcale nie spowalnia nauki. Na początku faktycznie wszystko trwa dłużej. Ale z czasem widać efekty, kolejne tematy zaczynają się ze sobą łączyć, a nowe rzeczy wchodzą szybciej, bo mają już solidne podstawy.
Największa zmiana to chyba brak poczucia przypadkowości. Kiedy coś się psuje, to nie jest już „pech” albo „magia”, tylko problem, który można zrozumieć i rozwiązać.
I to był moment, w którym przestałem po prostu zaliczać zadania, a zacząłem faktycznie uczyć się informatyki.
Z perspektywy czasu widać to dość wyraźnie: „działa, to nie ruszaj” brzmi rozsądnie tylko na początku. Później okazuje się, że to najprostszy sposób, żeby utknąć albo wracać do tego samego kodu i za każdym razem zaczynać od zera.
Do zobaczenia na korytarzach i pamiętajcie, nie poddawajcie się, nawet jeśli czasem coś kompletnie nie działa. To zwykle znak, że właśnie zaczynacie się naprawdę uczyć. Trzymajcie się – Mateusz K.