Zawód programisty nie jest łatwy, ale na pewno jest bardzo płatny. Twoi koledzy mogą być bezrobotni lub rozdawać ulotki (nie jest jednak to fajne uczucie), a ty już jesteś we właściwym miejscu.
Łatwo więc zacząć podchodzi do swojej profesji emocjonalnie jak i traktować swój kod jak swoje własne dzieci.
Nie nazwałbym się profesjonalnym programistą. Dwa lata doświadczenia zawodowego to nie wiele. Człowiek definitywnie musi się jeszcze dużo nauczyć.
Niedługo pójdę z duchem czasu i będę umieszczał swój kod na GitHub tak aby każdy początkujący programista mógł z niego skorzystać.
W branży jednak twój kod może określać wiele rzeczy.
Ja oczywiście wiem, że nie jestem swoim kodem. 95% moich znajomych nawet nie wiem co takiego robię w pracy i o czym jest ten blog. Jednym słowem oni na pewno nie będą mnie mierzyć w ten sposób.
Twój kod jednak wpływa na twoją reputację. Blog, praca…
Jeżeli jesteś kiepskim programistą lub miałeś zły dzień to wcześniej czy później ktoś to zauważy. Być może nawet nie zdasz sobie z tego jak twój kod jest koszmarny dopóki druga osoba tego nie zaobserwuje.
Dzieląc jednak swój kodu może znajdziesz swojego nauczyciela lub guru.
Stworzenie idealnego kodu jest niemożliwe. A wszystko czasami sprowadza się do czytelności kodu jak i do pewnych cwanych sztuczek.
Trochę to ironicznie ponieważ moja praca magisterska o “Wzorcach projektowych” stoi tak samo jak wpisy pod kategorią “wzorce projektowe”. Na pewno przydałoby się zapamiętać pewne sztuczki by później być może tworzyć swoje rozwiązania.
Inna ironia polega jednak na tym, że w prostych projektach większość osób jednak doceni prostoliniowy kod. Problem jednak się pojawi gdy projekt urośnie i nagle się okaże, że 1000 linijek w jednym pliku bądź inny pomysły, który się sprawdzał jak do tej pory - stanie się czyimś koszmarem.
Nawet jeśli jesteś dobry programistą to co robić gdy musisz napisać kod jak najszybciej bo trzeba wdrożyć 5 innych rzeczy. Po miesiącu się okazuje, że twój kod jest jednym wielkim śmietnikiem starych i nowych metod i coraz trudniej dodawać do niego nowe funkcjonalności.
Dlatego Visual Studio posiada narzędzie “Code Analysis” które potrafi analizować twój kod. Jeśli narzędziowi się nie podoba twój kod wtedy aplikacja się nie skompiluje. Brzmi genialnie, ale zdarzyło mi się poprawiać pewien błąd krytyczny w firmie i w takiej chwili jednak by chciał by mój kod się kompilował bez względu na to czy on łamie pewne zasady czy nie.
Filozofia zawsze dbamy o “jakość kodu” ma jednak też pewien problem z definicją słowa “zawsze”.
Z drugiej strony, aż strach pomyśleć o miejscu pracy gdzie nie ma TFS i nie ma żadnych procedur co do “coding standardu”.
Ważne jest by być “gruboskórnym”.
To chyba najlepsza rada jaką mogę komuś dać.
Wszyscy jesteśmy ludźmi. Każdy popełnia błędy. Jeśli pracujesz pod presją to prawdopodobieństwo złych decyzji gwałtownie wzrasta.
O czym więc musimy pamiętać?
Każdy kod…
Każda architektura, decyzja, test jednostkowy jest dla nas – no chyba, że jesteś na urlopie to wtedy twoi koledzy potwierdzą jakość twojego kodu.
Dla użytkownika program jest rozwiązaniem pewnego problemu. Jak jest on napisany nie jest częścią jego problemu.
Każdy z nas ma gdzieś zły kod. Czasami uczymy się nowej technologii. Czasami nie ma budżetu i czasu by postarać się aby kod wyglądał dobrze.
Powinieneś ciągle rozwijać swoje możliwości - nie jako programista, ale też jako człowiek. Człowiek który popełnia błędy.
Tak długo jak zaakceptujemy tą niekończącą się walkę pomiędzy kodem, a zasobami i zdolnościami wtedy łatwiej będzie nam zaakceptować nasz kod.
Oczywiście kod trzeba refaktoryzować przy każdej okazji i starać się nie popełniać tych samych błędów w nowym projekcie.
Taka zasada dobrze sprawdza się nie tylko do kodu, ale także do życia.
