Wszyscy piszą artykuł o tym jak być super deweloperem. Ale bycie ZŁYM programistą też nie jest proste. Trzeba się starać i łamać wszystkie dobre praktyki. Zobacz co musisz zrobić, by stać się naprawdę złym deweloperem.
Rozbijanie komponentów na mniejsze pliki jest dla słabych. To tylko powoduje problemy. Musisz utrzymać strukturę katalogów, dzielić pliki, pilnować porządku w importach. Jednym słowem – duże marnotrawstwo czasu. A wiadomo, czas jest najważniejszy w programowaniu. Rozwiązanie tego problemu jest proste – jeden wielki plik, w którym jest wszystko. Nie musisz się martwić o importy, strukturę katalogów, masz wszystko w jednym miejscu, nie musisz się zastanawiać gdzie umieścić współdzielony komponent. Jednym słowem same zalety.
Kto wpadł na genialny pomysł, by z nazw zmiennych robić całe zdania. Potem trzeba ekrany panoramiczne, by zmieściło ci się to w edytorze. A w czym niby są gorsze zwykłe jedno litrowe zmienne. I tak wiadomo, o co chodzi, a edytor sobie poradzi z podpowiadaniem. Tworząc jednoliterowe zmienne, oszczędzasz miejsce w pliku. A im mniejszy plik tym przeglądarka ma mniej kodu do pobrania.
Słyszałeś o DRY? Ty musisz się twardo trzymać tej zasady i wydzielasz rzeczy do wspólnych funkcji. Co z tego że funkcja ma ostatecznie 20 parametrów? W końcu o to chodzi, by się nie powtarzać i ograć parametrami drobne zmiany. No i IDE na pewno sobie poradzi z podpowiadaniem.
Tworzenie małych pull requestów to strata czasu. Więcej czasu spędzasz na tworzeniu, opisywaniu i potem aktualizacji pull requestów niż na właściwym programowaniu. Dużo lepiej jest stworzyć jeden duży pull request ze wszystkim. Koledzy z zespołu sprawdzą to za jednym razem i będzie po wszystkim. A że zajmie to więcej czasu i będzie mniej dokładne? No trudno, to wina kolegów nie twoja.
Pisanie testów to głupota. W końcu twój kod jest najlepszy na świecie i nie ma w nim błędów. Nie potrzebujesz pisać dodatkowego kodu, żeby się o tym przekonać. Niech testy piszą juniorzy, którzy nie potrafią programować, a nie ty. A co jeśli wrócisz w przyszłości do kodu. Masz pamięć doskonałą, więc będziesz pamiętał wszystkie szczegóły.
Koledzy w zespole się uparli, by jednak pisać te testy? Zawsze możesz stworzyć testy, które zawsze są zielone. Ty w końcu ich nie potrzebujesz, a koledzy się odczepią. Przecież nikt ich nie będzie sprawdzał, skoro będą ciągle zielone.
Teraz z robotą jest łatwo, ale czy wiadomo, jak to będzie wyglądało w przyszłości? Lepiej zadbać o to już teraz dlatego nie dziel się swoją wiedzą dotyczącą kodu, nie twórz dokumentacji, trzymaj wszystkie informacje dla siebie – bądź Alfą i Omegą tego projektu. Dzięki temu nikt cię nie wyrzuci z roboty. Bez Ciebie projekt upadnie.
Pamiętaj, że wszyscy inni deweloperzy są mniej zaawansowani od ciebie. I musisz im ciągle pomagać. Dlatego komentuj każdą drobną rzecz w kodzie, żeby się nie pogubili. Pisząc więcej komentarzy niż kodu, pomagasz innym deweloperem. Pamiętaj o tym.
Nie po to zostałeś programistą, by rozmawiać z ludźmi. Rozmowy są w końcu stratą czasu. I tak ty wiesz najlepiej, jak powinna wyglądać aplikacja. A klient nic nie wie i tylko przeszkadza. Sam nie wie czego chce. Lepiej, żebyś ty to zrobił po swojemu, bo tak będzie najlepiej.
Widzisz tych wszystkich juniorów na bootcampach. To jest twoja przyszła konkurencja. Dlatego nie dziel się, tym co wiesz, nie pisz bloga, nie dziel się wiedzą na konferencjach itd. Im więcej wiedzy zachowasz dla siebie, tym lepiej dla ciebie. Dzięki temu będziesz zawsze o krok przed juniorami. Masz przewagę lat, więc na pewno nie dogonią cię, jeśli im nie pomożesz.
FSGeek