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).
- 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
- Nie zmieniaj stanu obiektów z którymi pracujesz, twórz nowe i zwracaj je jako wynik operacji
- 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.
- 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.
- Prostota jest nadal w modzie, utrzymuj kod prostym, czytelnym, łatwym w czytaniu i zrozumieniu
- 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
- 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
- Kod zostawiaj czystszym niż go zastałeś, napraw, popraw literówki, dopisz klamerki, uzupełnij testy
- Zanim zaczniesz szukać nowego buga we frameworku, czy bibliotece – upewnij się, że problem nie leży po twojej stronie.
- 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ć.
- 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
- 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
- Formatowanie ma znaczenie, konwencja ma znaczenie, gdy się tego stosujesz w całym projekcie, łatwiej się go czyta, analizuje i rozumie
- 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
- 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
- Nie komentuj. Chyba że dzielisz przez zero, lub gdy kod zachowuje się nielogicznie, lub hakujesz system
- 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
- Nie przestawaj się uczyć, nie będę pisać jak, każdy ma swój sposób na poszerzanie wiedzy, po prostu nie przestawaj
- 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
- Publikuj (nie znam lepszego słowa) szybko, często i namiętnie – niech ten proces przestanie być tajemnicą i przestanie boleć.
- 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
- Ć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
- Jest wiele żargonów domenowych, każdy z kręgów operuje swoim, dostosuj się do niego
- 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
- Pilnuj brudnych słów, nawet w testach, różne rzeczy wychodzą na światło publiczne, nawet “śmieszne” komentarze z testów, czy danych testowych
- 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
- 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
- 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
- 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
- Staraj się nie powtarzać – to marnowanie czasu, automatyzuj powtarzające się czynności, testy, buildy, etc
- 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
- Encapsulate Behavior, not Just State
- Ułamki są udawana i są tylko w przybliżeniu, uważaj na nie
- 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
- The Golden Rule of API Design
- 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
- 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
- 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ć
- 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
- 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
- Dużo czasu aplikacja spala na komunikacji pomiędzy procesami, podczas optymalizacji poszukaj tam miejsc które można usprawnić
- 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
- 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
- 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ć
- 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
- 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
- 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
- Jeśli dane gdzieś latają i są mocno rozproszone, wrzuć jest do bazki i centralizuj, łatwiej będzie zarządzać i utrzymywać te informacje
- Ucz się języków obcych, co tu kryć, to rozwija
- 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
- 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
- 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
- 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
- Rozwiązania tymczasowe które działają, zostają na zawsze
- 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
- Ś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
- Wiadomości skalują się lepiej niż współdzielona pamięć
- 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
- Korzystaj z polimorfizmu, unikaj if-else
- Testerzy są twoimi przyjaciółmi, dzięki ich pracy nie musisz się wstydzić przed klientem
- 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
- Pamiętaj że aplikacja wykonuje to co napisane w kodzie, a nie w komentarza czy dokumentacji
- Refaktoryzuj i poprawiaj nie tylko kod aplikacji, ale i także skrypty budujące
- 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ń
- Wprowadź i używaj typów domenowych, łatwiej się czytają i trudniej o pomyłkę
- 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
- Bądź pro! Dbaj o projekt, o kod, o ludzi i o zespół, o porządek w kodzie i projekcie
- 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
- 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ąć
- 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
- 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
- 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ć
- 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
- 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
- Wywalaj kod, prosty kod to ten którego nie ma i nie trzeba czytać
- SRP tak samo jak git, czyli FTW, reszta innych dobrych rzeczy też przyjdzie, zacznij od tego
- Bądź pozytywny do ludzi i wymagań i tego co zamawia klient, w najgorszym wypadku lub najmniej logicznym, zanim powiesz nie, zapytaj dlaczego
- Raz, dwa, automatyzuj swoją pracę
- Korzystaj ze statycznej analizy kod
- Pisz testy opisane w wymaganiach, a nie na podstawie implementacji
- Testy pisz w jawny i konkretny sposób, dokładnie określaj czego oczekujesz i co oznacza dla ciebie poprawny wynik testu
- 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
- Testowanie to nie fanaberia, tylko jeden z kilku kroków procesu powstawania systemu
- Thinking in States
- 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
- 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
- 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
- Pamiętaj o konsoli, jest tam masa dodatkowych narzędzi, IDE ma ich dużo, ale system ma ich jeszcze więcej
- 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
- 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
- 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
- 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
- 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ś
- Write Small Functions Using Examples
- 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)
- Dbaj o kod, o spójność, o przejrzystość, o brak magii, o świadomość innych kolegów w projekcie o zmianach które wprowadzasz
- 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ę.
35., którego nie potrafiłeś przetłumaczyć, to wg mnie przetłumaczone 55.
Dobra robota!
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
Zmieniłem, dzięki.
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.
Tak, w jasny sposób zaznaczyłem że czegoś nie wiem, ale już to zmieniłem na trochę inne podejście.
A propos punktu 25, na jakie najciekawsze perełki trafiliście?:)
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.
60. “Przyjaciele są twoimi przyjaciółmi, dzięki ich pracy nie musisz się wstydzić przed klientem” – powinni być testerzy są twoimi przyjaciółmi.
Tak jest, poprawione, dziękuje pięknie 🙂