94 zdania które każdy programista powinien przeczytać

To jest krótsza wersja książki 97 rzeczy, które każdy programista powinien widzieć po jej przeczytaniu chciałem podzielić się tym co tam przeczytałem, jak i lekką interpretacją tamtejszych myśli. Ponieważ czterech z nich nie rozumiem do końca i/lub nie umiem wytłumaczyć to w temacie są tylko 94 (powinny być 93, liczyć też nie umiem), natomiast linki w każdym ze zdań odnoszą się do pełnego rozdziału – pozostawiam tam także oryginalny tytuł (dziękuje za pomysł – hyuli).

  1. Dług techniczny kosztuje, podobnie jak kredyt gotówkowy – teraz przez chwilę jest lepiej, ale trzeba spłacić. Jeśli zaprzestaniesz spłat zjedzą cię odsetki
  2. Nie zmieniaj stanu obiektów z którymi pracujesz, twórz nowe i zwracaj je jako wynik operacji
  3. Pytaj czego chce użytkownik podczas implementacji funkcjonalności, pamiętaj że ty nim nie jesteś – ty masz się upewnić, że użytkownik będzie zadowolony z tego jak działa aplikacji i w jaki sposób rozwiązuje jego problem.
  4. Zautomatyzuj swoje standardy programistyczne – oddaj komputerowi to co robi szybciej niż ty, spacje, wcięcia, kolejność, etc. niech to sprawdza komputer, który się nie nudzi i robi to tysiąc razy szybciej.
  5. Prostota jest nadal w modzie, utrzymuj kod prostym, czytelnym, łatwym w czytaniu i zrozumieniu
  6. Przemyśl porządnie re faktoring; nie przepisuj całości, zmiany wprowadzaj w małym częściach, pilnuj testów, uzgodnij z resztą zespołu, nie idealizuj
  7. Kod nie zawsze wyciąga się do wspólnego, nie każdy kod który wygląda tak samo należy uwspólnić, szczególnie gdy odpowiedzialności leża bardzo daleko od siebie
  8. Kod zostawiaj czystszym niż go zastałeś, napraw, popraw literówki, dopisz klamerki, uzupełnij testy
  9. Zanim zaczniesz szukać nowego buga we frameworku, czy bibliotece – upewnij się, że problem nie leży po twojej stronie.
  10. Zanim dołączysz nową bibliotekę do projektu, „pomacaj” się z nią trochę, zobacz co wciągasz do rodziny, jakie inne zależności, jaki proces, jakie mroczne sekrety będziesz musiał od tej pory utrzymywać.
  11. Tam gdzie możesz pisz kod blisko biznesu, używaj języka z którego korzystają użytkownicy, łatwiej będzie ci porozumieć się z użytkownikami i podobnie użytkownikom będzie korzystać z aplikacji, gdy ta będzie mówiła ich językiem
  12. Projektuj, poświęć chwilę i pomyśl co tworzysz, w przeciwnym wypadku krzywa wieża w pizie będzie perfekcyjnie prosta w porównaniu do twojego systemu
  13. Formatowanie ma znaczenie, konwencja ma znaczenie, gdy się tego stosujesz w całym projekcie, łatwiej się go czyta, analizuje i rozumie
  14. Rób code review, rób je zawsze, dla każdego PR, nawet w jednoosobowym projekcie, to jeden ze sposobów na poprawę kodu i zmniejszenie ilości błędów
  15. Podziel kod na części, taki będzie prościej utrzymywać w wysokiej jakości, porządku niech pilnują automaty, zawsze, wszędzie i bez przymrużenia oka
  16. Nie komentuj. Chyba że dzielisz przez zero, lub gdy kod zachowuje się nielogicznie, lub hakujesz system
  17. No dobra, jeśli biznes karze robić coś dziwnego i czytając kod, mózg puchnie z tego powodu, zostaw linijkę z wytłumaczeniem lub przeprosinami
  18. Nie przestawaj się uczyć, nie będę pisać jak, każdy ma swój sposób na poszerzanie wiedzy, po prostu nie przestawaj
  19. Pamiętasz o biznesie? Przy projektowaniu api to też ma znaczenie, nie używaj ‚i’, ‚lub’, ‚albo’ w metodach, które starowane są parametrami przesyłanymi do metody, twórz osobne na osobne przypadki
  20. Publikuj (nie znam lepszego słowa) szybko, często i namiętnie – niech ten proces przestanie być tajemnicą i przestanie boleć.
  21. Rozróżniaj wyjątki biznesowe od technicznych, inaczej obsługuj problem połączenia z bazą danych, a inaczej przelewu z konta na którym nie ma hajsu
  22. Ćwicz, poza nauką nowego, ćwicz to co już umiesz, przez ćwiczenia staniesz się lepszy w tym co robisz, ale też zaczniesz (mam nadzieję) zmieniać to jak korzystasz ze swojej wiedzy, poznasz nowe zastosowania czy rozwiązania z nią związane
  23. Jest wiele żargonów domenowych, każdy z kręgów operuje swoim, dostosuj się do niego
  24. Nie bój się eksperymentować i psuć, tylko w ten sposób poznasz co się stanie gdy coś się zepsuje, jasne sprawa że dobrze mieć po kontrolą co i kiedy się psuje, tak tylko piszę żebyś nie bał się tego robić świadomie
  25. Pilnuj brudnych słów, nawet w testach, różne rzeczy wychodzą na światło publiczne, nawet „śmieszne” komentarze z testów, czy danych testowych
  26. Nie ignoruj błędów, nawet tych prostych, jeśli występuje błąd na który aktualnie nie masz czasu, zaloguj – może z niskim priorytetem, może coś inaczej, ale nie ignoruj błędów, bo zaczną się pojawiać „dobre” błędy, te które muszą wystąpić, aby aplikacja działała dobrze
  27. Gdy poznajesz nową technologię, poznaj też wzorce w niej wykorzystywane, te lepsze biblioteki i inne dobre praktyki, w ten sposób wyciągniesz jeszcze więcej nowości
  28. Pozwól jej się wywalić, nie każdy wyjątek należy przechwycić i uratować, czasem jesteś (i aplikacja) tak głęboko w czarnej, że najlepsze co możesz zrobić to przeprosić użytkownika i posprzątać po sobie
  29. Czas czarów przeminęły, nie stosuj magicznych sztuczek w kodzie, nie wszyscy posiadają tą samą magiczną różdżkę co Ty, nie wszyscy znają runy
  30. Staraj się nie powtarzać – to marnowanie czasu, automatyzuj powtarzające się czynności, testy, buildy, etc
  31. Lepiej będzie dla Ciebie i dla projektu, jeśli nie będziesz mieć bezpośredniego dostępu produkcji i fixów na niej, niech ten szybki quick fix przejdzie przez maszynkę continousX i samo się wrzuci, masz pewność, że „przy okazji” nie wprowadzisz nowego robaka na produkcje
  32. Encapsulate Behavior, not Just State
  33. Ułamki są udawana i są tylko w przybliżeniu, uważaj na nie
  34. Nie oczekuj że w każdej pracy będziesz się rozwijać, praca daje hajs, fajnie jeśli daje możliwość nauki, ale jeśli nie to rób to w domu, np. open source
  35. The Golden Rule of API Design
  36. Nie idź na łatwiznę, jasne że prosto jest zapytać kolegę jak rozwiązać wyjątek ABC, ale gdy on to zrobi za Ciebie, punkty doświadczenia zostaną przy nim, a nie pójdą do twojej głowy i zawsze będziesz się pytać, zawsze będziesz na doczepkę, nigdy nie będziesz tym do którego przychodzą z pytaniami
  37. Nie bądź bohaterem dnia – dzień w dzień, jasne gdy serwery płoną to warto je uratować i czasem trzeba się ubrudzić czy poświęcić, natomiast jeśli te serwery płoną dzień w dzień, to znaczy że znacznie większego dzieje się źle i twoje bohaterskie codzienne działa pójdą na nic, będziesz chodzić nie wyspany i zły, a serwery będą płonąć nadal
  38. Dobrze opisuj bugi, tak aby potem prosto i łatwo i pewnie można je odtworzyć i naprawić, dobrze jeśli napiszesz także co jest i co powinno być
  39. Najlepszym sposobem na poprawę jakości kodu jest jego usunięcie, najtańszy w utrzymaniu kod to takie którego nie ma, dlatego prawdą jest pierwsze zdanie
  40. Bądź przyjazny użytkownikom, prowadź ich za rękę, ale gdy tego chcą rób za nich wszystko, w zależności od ich preferencji i ich poziomu zaawansowania
  41. Dużo czasu aplikacja spala na komunikacji pomiędzy procesami, podczas optymalizacji poszukaj tam miejsc które można usprawnić
  42. Usuń z builda wszelkie warningi i „dobre” błędy, build powinien zawsze zakończyć się poprawnie i na czysto. W ten sposób nie będzie niespodzianek gdy warning na produkcji zamieni się w wyjątek na produkcji
  43. Nie bój się konsolki, to narzędzie które umożliwia wszystko, pamiętaj że UI to czarodzieje nad konsolką i często część funkcjonalności jest nie dostępna przez wyklikanie
  44. Znaj więcej niż jeden język programowania (obcy także się w to wliczają), każdy nowy język daje trochę inną perspektywę na to jak dany problem można rozwiązać
  45. Znaj swoje narzędzie pracy, znaj skróty (tak wiem), wiedz jak twoje narzędzie pracy może ci pomóc, ale także znaj jego słabe strony, inwestuj w zamienniki czy alternatywy
  46. Znaj ograniczenia sprzętowe (ty też jesteś sprzętem), pomyśli ile danych maksymalnie zmieści się w pamięci, ile danych można przesłać w żądaniu http czy jaki json nie powiesi przeglądarki, nie obiecuj kokosów
  47. Miej kontrolę nad tym co robisz, planuj, estymuj chociaż trochę, tak aby klient choć trochę (w najgorszym przypadku) wiedział kiedy może oczekiwać nowe wersji, funkcjonalności, rozwiązania problemu
  48. Jeśli dane gdzieś latają i są mocno rozproszone, wrzuć jest do bazki i centralizuj, łatwiej będzie zarządzać i utrzymywać te informacje
  49. Ucz się języków obcych, co tu kryć, to rozwija
  50. Ucz się estymować, ale nie rób dla PM który ciśnie, wyceń i broń swojego zdania, możesz oczywiście zmienić zdanie gdy zmienią się wymagania lub ktoś podrzuci gotowe rozwiązania
  51. Gdy czegoś próbujesz, próbuj na małych kawałkach, nie trzeba zaprzęgać całego świata, wszystkich wzorców, bibliotek czy narzędzie, to sprawdzenia jednej idei czy algorytmu
  52. Pozwól projektowi mówić o sobie, zainstaluj narzędzia do monitorowania testów, stanu technicznego, długu, a potem korzystaj z raportów aby wiedzieć w jakim stanie jest po każdej wprowadzonej zmianie i reaguj na to
  53. Linker nie jest tajemniczym narzędziem, to kolejne rzecz która działa po kompilatorze i nie czyni cudów, po prostu skleja kod i zamienia do na inny
  54. Rozwiązania tymczasowe które działają, zostają na zawsze
  55. Gdy projektujesz interfejs programistyczny dla kogoś, sprawdź go wcześniej u siebie, i nie chodzi tu o testy, napisz kod który korzysta z niego, sam sprawdź czy jest łatwy w wykorzystaniu, czy utrudnia pomyłki
  56. Śledź swoją aplikację, śledź postępy, wyniki testów, jakoś – w ten sposób, będziesz będziesz na bieżąco i sam się nie zaskoczysz że coś idzie długo lub coś jest trudne
  57. Wiadomości skalują się lepiej niż współdzielona pamięć
  58. Pisz kod tak prosty, aby każdy po tobie mógł z łatwością go przeczytać i zrozumieć, nie ważne czy to junior czy to senior
  59. Korzystaj z polimorfizmu, unikaj if-else
  60. Przyjaciele są twoimi przyjaciółmi, dzięki ich pracy nie musisz się wstydzić przed klientem
  61. Miej pewność co poszło na produkcje, znaj i loguj wersję, śledź zmiany aplikacji, podobnie jeśli konfigurujesz aplikację przez system, śledź zmiany w konfiguracji i w systemie, będzie łatwiej powtórzyć buga gdy coś się posypie
  62. Pamiętaj że aplikacja wykonuje to co napisane w kodzie, a nie w komentarza czy dokumentacji
  63. Refaktoryzuj i poprawiaj nie tylko kod aplikacji, ale i także skrypty budujące
  64. Paruj się 😉 rób zadania wspólnie z innymi członkami zespołu, dziel się wiedzą, w ten sposób każdy może robić wszystko, każdy jest zastępowalny i w razie grubego pożaru każdy posiadać wiedzę tajemną i uratować dzień
  65. Wprowadź i używaj typów domenowych, łatwiej się czytają i trudniej o pomyłkę
  66. Unikaj błędów, unikaj ich poprzez wprowadzanie domyślnych wartości, ładne UI które mówi użytkownikowi czego oczekujesz, jeśli oczekujesz formatu telefonu ze bez spacji a użytkownik poda ze spacjami, usuń je samodzielnie i ponownie sprawdź czy mają sens, zanim zaczniesz rzucać oskarżeniami o błędach
  67. Bądź pro! Dbaj o projekt, o kod, o ludzi i o zespół, o porządek w kodzie i projekcie
  68. Git FTW, nie okłamuj się że zip czy kopiowanie z jednego folderu do innego zapewni jego utrzymanie, czy w razie wtopy przywrócenie do ostatniej działającej wersji
  69. Idź zrobić siku, jeśli masz pożar w projekcie, ale za cholerę nie wiesz co się rypnęło i nie wiesz jak to naprawić, i siedzisz i siedzisz i nie wiesz, a bardzo chcesz to zrób siku, odpocznij pięć minut, pomyśl o trabanciku i dopiero wtedy pomyśl wróć do pracy, pozwól głowie odpocząć
  70. Czytaj kod i ucz się z niego, jeśli kod jest prosty do przeczytania pomyśl czemu tak jest, jeśli jest trudny to czemu tak jest, nawet jeśli nie do końca rozumiesz co się w nim dzieje, wyciągaj z niego formę, kształt, ułożenie, schematy
  71. Aplikacje są tworzone przez ludzi i ludzi oraz dla ludzi, pamiętaj o dwóch rzeczach: ktoś inny może utrzymywać aplikację po tobie, nie utrudniaj mu tego, ktoś będzie korzystać z aplikacji nie obrzydzaj mu tego
  72. Uwaga! Wymyślaj koło od nowa, ćwicz i twórz rzeczy które istnieją, poznasz ile bólu i skrótów trzeba było przeżyć, aby twoje nowe koła zaczęły się toczyć
  73. Nie będę owijać w bawełnę, omijaj singletony, jeśli już musisz, skorzystaj z IOC żeby zrobiły co muszą, ale tylko wtedy gdy naprawdę musisz singletonować, ale nie oszukujmy się nie musisz tego robić – prawda
  74. Droga do wydajności jest usłana złym kodem, gdzie wydajność która jest brana pod uwagę to wydajność twoja, a na tej drodze stoi kod który z pierwotnego planowania na kilka godzin, taska zmienia w miesiąc przekleństw, potu i łez
  75. Wywalaj kod, prosty kod to ten którego nie ma i nie trzeba czytać
  76. SRP tak samo jak git, czyli FTW, reszta innych dobrych rzeczy też przyjdzie, zacznij od tego
  77. Bądź pozytywny do ludzi i wymagań i tego co zamawia klient, w najgorszym wypadku lub najmniej logicznym, zanim powiesz nie, zapytaj dlaczego
  78. Raz, dwa, automatyzuj swoją pracę
  79. Korzystaj ze statycznej analizy kod
  80. Pisz testy opisane w wymaganiach, a nie na podstawie implementacji
  81. Testy pisz w jawny i konkretny sposób, dokładnie określaj czego oczekujesz i co oznacza dla ciebie poprawny wynik testu
  82. Długie testy odpalaj w nocy, lub w trakcie weekendów, w ciągu dnia gdy idzie dużo wrzutek na repozytorium odpalaj te testy, który działają najkrócej i dają szybko informują o (nie)udanym procesie budowania aplikacji i stanie testów
  83. Testowanie to nie fanaberia, tylko jeden z kilku kroków procesu powstawania systemu
  84. Thinking in States
  85. Uprawiaj pair-programming, praca w parze to nie tylko lepszy kod, bo ten drugi też patrzy, to także lepsza koncentracja na pracy, lepsze zrozumienie kod, być może poznanie czegoś nowego, ale i także code-review dokonywane w locie – pamiętaj, dwie głowy to nie jedna
  86. Błędy mogą się niwelować, jeśli ty zwracasz wartość ujemną a nie powinienś, a ktoś z cienie korzysta i mnoży cie przez -1 żebyś miał sens to wszystko działa pięknie, dopóki nie naprawisz pierwszego, wtedy zepsuje się drugi 🙁 także albo oba+ naprawiasz jednocześnie, albo żadnego
  87. Nie tylko człowiek może zaszkodzić kodu 🙂 Ale inny kod też, jeśli korzystasz z brzydkiego API to miejsce u ciebie też zacznie trącić, pamiętaj o tym projektując swój kod dla innych
  88. Pamiętaj o konsoli, jest tam masa dodatkowych narzędzi, IDE ma ich dużo, ale system ma ich jeszcze więcej
  89. Korzystaj z właściwych algorytmów, metody i struktur danych, jeśli kod wykonuje się dłużej niż kilka milisekund i nie przetwarza peta bajtów danych to weź się ogarnij
  90. Uporządkuj poziom logowania swojej aplikacji, nie pozwól aby poprawne logowania i inne rzeczy na potrzeby debug czy verbose zapełniały ci nie potrzebnie głowy 
  91. Nie powtarzaj się, jeśli to zrobisz a to będzie bug, to będziesz dwa a nie jeden, a jeśli będzie powolny to będzie powolny w dwóch miejsca do naprawy
  92. Kooperuj z testerami, testy możesz pisać sam przeciwko swojej implementacji (przecież wiesz jak to działa i co ma robić), lub z testerem który zna specyfikacje (kontrakt) i który ma oczekiwania do tego jaki problem ma to rozwiązać, możesz nawet napisać szkic testu (np. dobrze brzmiący tytuł) i sprawdzić go w testerem, aby mieć pewność że dobrze zaimplementować wymagania i że dobrze je testujesz
  93. Jeśli piszesz kod ciężki w utrzymaniu, nikt nie będzie chciał go utrzymywać za ciebie, twój zmiennik nie przyjdzie, a ty będziesz tkwić w tym bagnie, które sam sobie zgotowałeś
  94. Write Small Functions Using Examples
  95. Testy pisz dla ludzi, aby czytając wiedzieli gdzie się wszystko ustawia, uruchamia i wreszcie upewnia (UUU – czy raczej AAA), nazwę testu także dopasuj do tego aby jasno powiedzie co-kiedy-jak (GWT)
  96. Dbaj o kod, o spójność, o przejrzystość, o brak magii, o świadomość innych kolegów w projekcie o zmianach które wprowadzasz
  97. Kliencie nie zawsze myślą w zgodzie z tym co mówią i piszą w wymaganiach, poświęć chwilę i upewnij się że to co właśnie implementujesz ma sens, jest spójne z resztą biznesu i jest najlepszym rozwiązaniem problemu twojego klienta

Podobało się? Udostępnij proszę.

9 thoughts on “94 zdania które każdy programista powinien przeczytać

  1. Pingback: dotnetomaniak.pl
  2. Mimo iż we wstępie uprzedzasz że kilku punktów nie rozumiesz,
    proponuję aby punkty 32, 35, 84, 94 zacytować w oryginale
    a w nawiasie dopisać „nie rozumiem”, np. coś w stylu
    32. „Encapsulate Behavior, not Just State” (od autora: nie umiem tego wytłumaczyć – nie rozumiem)

    Rozjaśni to czytanie tej listy i wyraźnie oddzieli teksty przez Ciebie objaśnione od tych które tylko linkujesz.

    Pozdrawiam

  3. Hej,
    bardzo ciekawy wpis. Przeczytałem „jednym tchem” od razu rzuciło mi się, że na 100% powtarza się sformułowanie „nie umiem wytłumaczyć – nie rozumiem” i faktycznie jest ono 3 razy:
    32 Nie umiem tego wytłumaczyć – nie rozumiem
    84 Nie umiem wytłumaczyć – nie rozumiem
    94 Nie umiem tego wytłumaczyć – nie rozumiem.

    1. U mnie i w okolicach obyło się bez srogich wpadek, ‚debugger’ w .js na produkcji, czy dupa w logach. Nie „udało” nam się nawet na codereview dojść do słynnych akcji jak w PKP czy innych większych portali.

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.