Złe nawyki są trudne do złamania, a jeszcze trudniejsze, jeśli nie zdajesz sobie sprawy, że to, co robisz, podkopuje twoją pracę. Jeśli wiesz, ale nie dbasz o to – to byłoby najgorsze. Ale jesteś tutaj, czyż nie?
Jako programista, widziałem wiele złych praktyk, nie tylko wokół kodu, ale także wokół umiejętności pracy w zespole. Sam byłem winny praktykowania wielu z tych złych nawyków. Oto 35 moich najlepszych złych nawyków programistycznych, podzielonych na cztery kategorie: organizacja kodu, praca zespołowa, pisanie kodu oraz testowanie i konserwacja.
Organizacja kodu
1. Mówienie: „Poprawię to później”
Nawyki odkładania poprawek w kodzie nie są jedynie problemem priorytetów. Zorganizowanie swojego issue trackera może przynieść pewien postęp, ale musisz też mieć sposób na śledzenie mniejszych problemów, które się pojawiają. Dodawanie komentarzy „TODO” jest szybkim sposobem upewnienia się, że niczego nie przeoczysz.
2. Upieranie się przy jednolinijkowym rozwiązaniu
Obsesja na punkcie pisania wydajnych, eleganckich kawałków kodu jest wspólną cechą programistów. To jest jak rozwiązywanie zagadki – znajdujesz kombinację funkcji i wyrażeń regularnych, które zamieniają 20 linii kodu w 2 lub 3. Niestety, nie zawsze skutkuje to czytelnym kodem, a to zazwyczaj jest o wiele ważniejszy rezultat. Najpierw uczyń swój kod dostępnym, potem mądrym.
3. Dokonywanie bezsensownych optymalizacji
Innym miejscem, w którym często źle lokujemy nasze wysiłki, są optymalizacje. Zmniejszenie rozmiaru strony o kilka bajtów brzmi świetnie, ale czy gzip i tak tego nie nadrobi? I czy żądania nie są ważniejsze? Zajmij się optymalizacjami na końcu projektu, ponieważ częściej niż nie, wymagania się zmienią, a Twój czas zostanie zmarnowany.
„Przedwczesna optymalizacja jest korzeniem wszelkiego zła.”
-Donald Knuth
4. Przekonywanie siebie, że kwestie stylu nie są aż tak ważne
Jeśli nauczyłem się czegoś przez lata patrzenia na kod innych ludzi, to tego, że zajmowanie się kwestiami stylu kodowania jest rzeczą, którą programiści najczęściej odkładają na później. Być może niedoświadczonym programistom trudno jest dostrzec, co dobrego może wyniknąć z zajmowania się kwestiami stylistycznymi, ale z czasem stanie się oczywiste, że gdy jakość kodu się wykolei, efekt kuli śnieżnej zamieni każdy projekt w kompletny bałagan. Należy ściśle przestrzegać najlepszych praktyk, nawet jeśli wydają się one nieistotne. Skonfiguruj narzędzia do sprawdzania kodu i lintingu, aby dać sobie przestrzeń do martwienia się o ważniejsze rzeczy.
5. Zamiatanie spraw pod dywan
Czy to przez łapanie i ignorowanie wyjątków, czy też przez używanie bibliotek, które nie zgłaszają błędów (takich jak jQuery), istnieje wiele sposobów na zamiatanie spraw pod dywan. Ale kiedy jeden z tych błędów stanie się priorytetem, wyzwanie związane z jego naprawieniem będzie wielokrotnie większe, biorąc pod uwagę, że nie będziesz miał pojęcia od czego zacząć. Łatwym sposobem na uniknięcie tego jest rejestrowanie tych ignorowanych błędów, aby można było je później przeanalizować.
6. Używanie nazw, które nie dodają informacji
Nazewnictwo jest trudne, ale istnieje prosty sposób, aby upewnić się, że nazwy zmiennych i funkcji są przynajmniej przyzwoitej jakości. Tak długo, jak nazwy dodają jakiś rodzaj informacji, których reszta kodu nie przekazuje, inni programiści będą mieli łatwiejszy czas czytając twój kod. Powodem, dla którego nazewnictwo jest tak ważne jest to, że nazwy mogą dać ogólne pojęcie o tym, co robi kod. Zajmuje to więcej czasu, jeśli musisz zagłębić się w obliczenia, aby dowiedzieć się, co robi dany fragment kodu, ale dobra nazwa może pomóc ci zrozumieć, co robi kod w ciągu kilku sekund.
7. Ignorowanie sprawdzonych najlepszych praktyk
Przeglądy kodu, rozwój sterowany testami, zapewnienie jakości, automatyzacja wdrażania – te praktyki, i kilka innych, udowodniły swoją wartość w niezliczonych projektach, dlatego programiści ciągle o nich piszą na blogach. Doskonałym punktem odniesienia dla tych najlepszych praktyk jest książka Making Software: What Really Works, and Why We Believe It (Co naprawdę działa i dlaczego w to wierzymy). Poświęć trochę czasu, aby nauczyć się, jak robić to poprawnie, a Twój proces rozwoju poprawi się we wszystkich Twoich projektach w sposób, który Cię zaskoczy.
Praca zespołowa
8. Porzucanie planów zbyt wcześnie
Pewnym sposobem na uczynienie twojego systemu nieodgadnionym jest niezobowiązanie się do planu. Zawsze możesz powiedzieć, za każdym razem, gdy twój kod jest krytykowany, że plan nie jest kompletny. Jednak posiadanie w połowie gotowych modułów doprowadzi do ciasno sprzężonego kodu, gdy tylko spróbujesz sprawić, by te niedokończone moduły działały ze sobą. Ten rodzaj komplikacji pojawia się również, gdy role lidera projektu się zmieniają, a nowi liderzy decydują, że posiadanie go po swojemu jest ważniejsze niż spójność architektoniczna.
9. Upieranie się przy planie, który ma małe szanse zadziałać
Tak jak porzucenie planów może spowodować problemy, tak samo trzymanie się planu, który nie działa. Dlatego właśnie powinieneś dzielić się swoimi pomysłami z zespołem, aby uzyskać informacje zwrotne i porady, gdy sprawy stają się trudne. Czasami inna perspektywa może zrobić różnicę.
10. Praca na własną rękę przez cały czas
Powinieneś dążyć do dzielenia się swoimi postępami i pomysłami z zespołem. Czasami wydaje Ci się, że budujesz coś we właściwy sposób, ale tak nie jest, więc stała komunikacja jest bardzo cenna. Jest to również korzystne dla innych ludzi, kiedy z nimi pracujesz. Ich praca często się poprawia, gdy omawiasz z nimi pomysły i mentorujesz mniej doświadczonych członków zespołu, którzy z większym prawdopodobieństwem utkną.
11. Odmawianie pisania złego kodu
W życiu każdego programisty przychodzi czas, kiedy terminy zmuszą cię do pisania okropnego kodu, i to jest w porządku. Próbowałeś ostrzec klienta lub menedżera o konsekwencjach, ale oni nalegają na trzymanie się terminu, więc teraz nadszedł czas na kodowanie. A może jest jakiś pilny błąd, który nie może czekać, aż wymyślisz czyste rozwiązanie. Dlatego ważne jest, aby być wszechstronnym programistą i być w stanie napisać bardzo szybko zarówno słaby kod, jak i dobry kod. Miejmy nadzieję, że będziesz mógł ponownie przejrzeć kod i spłacić dług techniczny.
12. Obwinianie innych
Nie jest tajemnicą, że arogancja jest zbyt powszechną cechą wśród programistów i innych specjalistów technicznych. Branie odpowiedzialności za swoje błędy jest cnotą, która sprawi, że będziesz błyszczeć wśród swoich rówieśników. Nie bój się przyznać, że popełniłeś błąd. Kiedy już się z tym pogodzisz, będziesz mógł skupić się na nauce, dlaczego popełniłeś ten błąd i jak go uniknąć. Jeśli nie przyznasz się do błędu, nauka stanie się niemożliwa.
13. Nie dzielenie się ze swoim zespołem tym, czego się nauczyłeś
Twoja wartość jako programisty nie opiera się tylko na kodzie, który piszesz, ale także na tym, czego się nauczyłeś podczas jego pisania. Dziel się swoimi doświadczeniami, pisz komentarze na ten temat, daj innym znać, dlaczego rzeczy są takie, a nie inne, i pomóż im dowiedzieć się nowych rzeczy o projekcie i jego zawiłościach.
14. Bycie zbyt powolnym w dawaniu informacji zwrotnej menedżerom/klientom
Jedną z najcenniejszych cech charakteru każdego rzemieślnika jest upewnianie się, że wszyscy są na tej samej stronie w sprawie pracy, tak bardzo jak to możliwe. Powodem tego nie jest to, że Twój menedżer może wypełniać arkusze kalkulacyjne. Jest to również dla Twojego własnego zysku: Będziesz miał mniej niepewności i zmniejszysz niepewność co do czasu trwania i przyszłości projektu.
15. Za mało korzystasz z Google
Najlepszym sposobem na szybkie rozwiązanie złożonego problemu jest nie musieć go w ogóle rozwiązywać. Kiedy masz wątpliwości, wygoogluj to. Oczywiście, możesz zamiast tego zawracać głowę inżynierowi obok ciebie, ale rzadko kiedy będzie on w stanie udzielić tak szczegółowej odpowiedzi jak Stack Overflow, nie wspominając już o tym, że i jemu będziesz przeszkadzać w pracy.
16. Przecenianie swojego osobistego stylu
Zawsze dąż do skoordynowania swojego stylu pracy i konfiguracji środowiska ze swoim zespołem. Idealnie byłoby, gdyby wszyscy w twoim zespole pracowali w podobnych warunkach i stosowali ten sam styl kodowania. Robienie rzeczy po swojemu może być przyjemniejsze, ale współpracownicy mogą nie być przyzwyczajeni do Twojego stylu kodowania, a jeśli jest on nietypowy, kolejnemu programiście będzie trudniej pracować na tym, co zbudowałeś.
17. Posiadanie osobistego przywiązania do swojego kodu
Gdy ktoś komentuje twój kod, nie bierz tego do siebie. Twój kod powinien stać na solidnym gruncie; to znaczy, powinieneś być w stanie wyjaśnić, dlaczego napisałeś go w ten sposób. Jeśli wymaga poprawy, jest to tylko odzwierciedlenie poprawności kodu, a nie ciebie samego.
Pisanie kodu
18. Niewiedza, jak optymalizować
Dobra strategia optymalizacji wymaga pewnego doświadczenia, aby uzyskać właściwą. Wymaga eksploracji, analizy i znajomości każdego systemu zaangażowanego w proces. Poinformuj się o tych rzeczach. Dowiedz się o złożoności algorytmów, ocenie zapytań do bazy danych, protokołach i sposobach mierzenia wydajności w ogóle.
19. Używanie niewłaściwego narzędzia do pracy
Możesz wiedzieć tylko tyle, ale powodem, dla którego musisz się ciągle uczyć, jest to, że każdy nowy problem przynosi inny kontekst i wymaga innego narzędzia – jednego, bardziej odpowiedniego do danego zadania. Bądź otwarty na nowe biblioteki i języki. Nie podejmuj decyzji wyłącznie w oparciu o to, co wiesz.
20. Nie zawracanie sobie głowy opanowaniem narzędzi i IDE
Każdy nowy klawisz skrótu, skrót lub parametr, którego nauczysz się podczas używania narzędzi, z którymi pracujesz na co dzień, będzie miał bardziej pozytywny wpływ na szybkość kodowania, niż zdajesz sobie z tego sprawę. Nie chodzi o zaoszczędzenie kilku sekund poprzez użycie skrótu klawiszowego; chodzi o zmniejszenie przełączania kontekstu. Im więcej czasu poświęcasz na każdą małą czynność, tym mniej czasu będziesz miał na zastanowienie się, dlaczego to robisz i co będzie dalej. Opanowanie skrótów pozwoli uwolnić Twój umysł.
21. Ignorowanie komunikatów o błędach
Nie zakładaj, że wiesz, co jest nie tak z twoim kodem, nawet nie przeczytawszy komunikatu o błędzie, albo że zorientujesz się wystarczająco szybko. Posiadanie większej ilości informacji o problemie jest zawsze lepsze, a poświęcenie czasu na zebranie tych informacji pozwoli zaoszczędzić więcej czasu na dłuższą metę.
22. Romantyzowanie zestawu narzędzi deweloperskich
Czasami preferowany edytor lub narzędzie wiersza poleceń nie jest najlepszym narzędziem do danej pracy. Visual Studio jest świetne do pisania IDE, Sublime jest świetne do języków dynamicznych, Eclipse jest świetne do Javy, i tak dalej. Możesz kochać vima lub emacsa, ale to nie znaczy, że jest to właściwe narzędzie do każdego zadania.
23. Twarde kodowanie wartości zamiast uczynienia ich konfigurowalnymi
Zawsze myśl o tym, jakie zmiany mogą nadejść i jak sobie z nimi poradzić. Dług techniczny będzie rósł w monstrualnym tempie, jeśli nie oddzielisz ruchomych elementów od reszty swojej pracy. Używaj stałych i plików konfiguracyjnych tam, gdzie to właściwe.
24. Wymyślanie koła na nowo przez cały czas
Nie pisz kodu, którego nie potrzebujesz. Być może ktoś inny spędził już sporo czasu nad twoim problemem i może mieć dobrze przetestowane rozwiązanie, które możesz ponownie wykorzystać. Oszczędź sobie kłopotów.
25. Ślepe kopiowanie/wklejanie kodu
Zrozum kod, zanim go ponownie użyjesz. Czasami nie od razu zauważasz wszystko, co robi kod na pierwszy rzut oka. Dowiesz się również więcej o problemie, gdy poświęcisz czas na szczegółowe przeczytanie kodu.
26. Nie poświęcanie czasu na naukę, jak rzeczy naprawdę działają
Zawsze korzystaj z okazji do poszerzania swojej wiedzy poprzez zastanawianie się nad tym, jak rzeczy działają i czytanie o ich podstawowych problemach. Możesz zaoszczędzić czas, nie zawracając sobie tym głowy teraz, ale to, czego nauczysz się w trakcie projektu, będzie ważniejsze w dłuższej perspektywie niż faktyczne jego wykonanie.
27. Posiadanie nadmiernego zaufania do własnego kodu
Niebezpiecznie jest zakładać, że tylko dlatego, że coś napisałeś, musi to być świetne. Uczysz się więcej o programowaniu, gdy pracujesz nad nowymi rzeczami i zdobywasz doświadczenie, więc od czasu do czasu rzuć okiem na swój stary kod i zastanów się, jakie poczyniłeś postępy.
28. Nie myślenie o kompromisach każdego projektu, rozwiązania lub biblioteki
Każdy produkt ma swoje drobne punkty, które poznasz tylko używając i analizując go. Zobaczenie kilku przykładów użycia danej biblioteki nie uczyni z Ciebie mistrza w tej dziedzinie, ani nie oznacza, że będzie ona idealnie pasować do każdej sytuacji, która pojawi się w Twoim projekcie. Bądź nieustannie krytyczny wobec wszystkiego, czego używasz.
29. Nie otrzymywanie pomocy, kiedy utkniesz
Utrzymywanie krótkiej pętli informacji zwrotnej zawsze będzie dla Ciebie mniej bolesne. Zwrócenie się o pomoc nie oznacza, że jesteś niekompetentny. Właściwi ludzie będą postrzegać twój wysiłek i przyznanie się do niewiedzy jako dążenie do nauki, a to wielka cnota, którą warto mieć.
Testowanie i konserwacja
30. Pisanie testów, które mają przejść
Pisanie testów, które wiesz, że przejdą, jest konieczne. Dzięki nim refaktoryzacja i reorganizacja projektu będzie o wiele bezpieczniejsza. Z drugiej strony, musisz również pisać testy, o których wiesz, że nie przejdą. Są one niezbędne do posuwania projektu naprzód i śledzenia problemów.
31. Lekceważenie testów wydajnościowych dla krytycznych przypadków
Przygotuj automatyczną konfigurację testów wydajnościowych mniej więcej w połowie procesu rozwoju projektu, abyś mógł się upewnić, że nie masz eskalujących problemów z wydajnością.
32. Nie sprawdzanie, czy twój build działa
Rzadko zdarza się, że build przechodzi, ale tak naprawdę nie działa, ale może się to zdarzyć, a naprawienie problemu może być kłopotliwe, im dłużej zwlekasz z przyjrzeniem się mu. Szybkie testowanie każdego builda jest ważnym nawykiem do posiadania.
33. Pchanie dużych zmian późno, lub opuszczanie po zrobieniu dużego pchnięcia
To jest miejsce gdzie nadmierna pewność siebie cię dopadnie, i może to zająć kilka razy, aby nauczyć się dlaczego nie powinieneś tego robić, więc skorzystaj z mojej rady teraz i upewnij się, że zawsze jesteś tam, kiedy twój build w końcu się zepsuje.
34. Wypieranie się kodu, który napisałeś
Bądź skłonny wspierać kod, który napisałeś. Jesteś najbardziej odpowiednią osobą do pomagania innym w jego zrozumieniu. Powinieneś dążyć do tego, aby Twój kod pozostał czytelny dla siebie i innych za wiele lat.
35. Ignorowanie wymagań niefunkcjonalnych
Gdy próbujesz coś dostarczyć, łatwo może być zapomnieć o pewnych ważnych obszarach, takich jak wydajność i bezpieczeństwo. Miej listę kontrolną dla tych obszarów. Nie chcesz, aby zrujnowały one twoją imprezę, ponieważ wyznaczyłeś sobie terminy, nie myśląc o tych niefunkcjonalnych problemach.
Jakie są twoje najgorsze nawyki programistyczne?
Jak to się często mówi, jesteśmy stworzeniami z przyzwyczajenia. Poprawa sposobu pracy poprzez nawyki to świetny sposób, aby uniknąć konieczności myślenia zbyt wiele o każdej sytuacji. Kiedy już przyswoisz sobie dobry sposób robienia czegoś, staje się to bez wysiłku.