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.
Umieść wszystko w jednym pliku
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.
Twórz jednoliterowe zmienne
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.
Funkcje z mnóstwem parametrów
Słyszałeś o DRY? Ty musisz się twardo trzymać tej zasady i wydzielasz rzeczy do wspólnych funkcji. Co z tego iż 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.
Rób ogromne Pull Requesty
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 adekwatnym 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 iż zajmie to więcej czasu i będzie mniej dokładne? No trudno, to wina kolegów nie twoja.
Po co komu testy?
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żeli wrócisz w przyszłości do kodu. Masz pamięć doskonałą, więc będziesz pamiętał wszystkie szczegóły.
Niech Twoje testy będą zawsze zielone
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.
Bądź niezastąpiony
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.
Komentuj wszystko jak leci
Pamiętaj, iż 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.
Unikaj spotkań
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.
Jesteś moją konkurencją
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żeli im nie pomożesz.
