- Fail-fast
- Scout rule
- DRY
- DRTW
- KISS
- YAGNI
- RTFM
- No Tests - Don't Touch
- CQRS
- 90-90 rule
- Zen of Python
- SOLID
- GRASP
- STUPID
Jak najszybciej ubijaj program w przypadku problemów. Lepsze to niż działanie i wykrzaczenie się go z powodu Undefined Behavior później. Powodzenia w szukaniu przyczyny w takim przypadku.
- nieobsłużone wyjątki
-
asercje (
assert,static_assert) - w funkcjach sprawdzanie koniecznych warunków na początku
void process(std::shared_ptr<int> value) {
if (!value) {
return;
}
// process normally
}- minimalizowanie UB (Undefined Behavior)
- łatwiejsze debugowanie i szukanie przyczyn problemów
Zawsze zostawiaj obozowisko w co najmniej takim stanie w jakim je zastałeś.
Z kodem tak samo jak z biwakiem. Jeśli nabrudzisz w kodzie - musisz to posprzątać. Bardzo mile widziane jest też posprzątanie po innych.
Jeśli dotkniesz czyjegoś kodu, np. tylko dodając jedną linijkę - spróbuj go ulepszyć.
Sprzątanie ma być w osobnym commicie.
- kod może być tylko coraz czytelniejszy
- nie robimy długu technicznego, który kiedyś trzeba będzie spałcić
Często powielenia powstają wskutek prostej operacji "kopipasty".
Kod, który jest taki sam lub podobny w więcej niż 1 miejscu należy wydzielić do funkcji i wywoływać tę funkcję w tym miejscu
- łatwiejszy refaktoring - zmiana tylko w jednym miejscu
- mniej miejsca na błędy. Nie ma ryzyka, że po odkryciu błędu nie zmienimy wszystkich wystąpień
Nie wynajduj koła na nowa i używaj gotowych bibliotek dostarczających daną funkcjonalność.
- zazwyczaj używasz już przetestowanego kodu
- mniej miejsca na błędne implementacje - możesz nie wymyślić wszystkich przypadków testowych
- oszczędność czasu
Pisząc kod, nie wciskamy na siłę tricków i nowości, które może i uczynią go bardziej uniwersalnym i łatwym do przyszłego rozwijania, ale zmniejszą jego czytelność.
Wielu seniorów ma z tym problem i niepotrzebnie komplikuje kod. Na podstawie doświadczeń wiedzą, że dzięki temu kod będzie łatwiej modyfikować w przyszłości. A co w sytuacji, jeśli nie będzie on później nigdy modyfikowany, a będzie jednak czytany wiele razy?
Każde "usprawnienie" wprowadzamy dopiero wtedy, gdy zachodzi taka potrzeba. Nic nie piszemy "na zapas". Patrz - YAGNI.
- kod łatwiejszy do zrozumienia, w szczególności dla juniorów
Nie będziesz tego potrzebować. Nie piszemy kod na zapas, myśląc, że to się wkrótce przyda. Generujemy w ten sposób martwy kod, który nigdy nie jest i raczej nie będzie używany.
Jeśli w przyszłości dana funkcjonalność będzie potrzebna to pewnie zaimplementuje ją inna osoba (nawet Ty po miesiącu zapomnisz, że coś już zdarzyło Ci się napisać) i napisze(sz) to ponownie.
Im mniej kodu tym lepiej:
- krótszy czas kompilacji
- mniej skomplikowane zależności
- mniej do analizowania
- mniej do pamiętania (że coś było zrobione na zapas)
-
szybsze użycie narzędzie (
greplubCtrl+Fmają mniej do skanowania)
Zanim zasypiesz ludzi pytaniami o daną funkcjonalność / narzędzie przeczytaj instrukcję.
W Linuxie dla narzędzia tool używaj tool --help oraz man tool.
Jeśli po lekturze dokumentacji nadal nie wiesz co robić, wtedy zapytaj innych (osoby z zespołu, stackoverflow, inne forum, Discord Coders School 😉)
- Bardziej doświadczone osoby często mają napięty kalendarz, więc będą wdzięczne jeśli znajdziesz rozwiązanie samodzielnie lub bardziej się streścisz ;)
Jeśli chcesz poprawić jakiś kawałek kodu, ale nie jest on przetestowany, to najpierw napisz testy.
Jeśli "ulepszysz", czy też "poprawisz" kod, do którego nie było testów, to jak udowodnisz, że po Twoich zmianach jego zachowanie się nie zmieniło?
Nigdy nie zmieniaj jednocześnie implementacji oraz testów do niej. Jeśli testy przestaną przechodzić, to nie będziesz wiedzieć, czy to z powodu zepsutej implementacji czy zepsutych testów. Testy testują implementację, a implementacja testuje testy.
- oszczędzanie sobie potencjalnych problemów i czasu
- napisanie testów i refaktoring zajmie mniej czasu niż refaktoring bez testów (serio)
Oddziel zapis od odczytu.
- Query - pobranie (odczyt) danych - gettery
- Command - działanie na danych (zapis)
Powinniśmy unikać metod, które robią jedno i drugie razem, ponieważ:
Asking a question should not change the answer
-- Bertrand Meyer
90% zadania wykonasz w ciągu 90% czasu na nie przeznaczone.
Pozostałe 10% zadania wykonasz przez pozostałe 90% czasu.
Przydatna przy ocenie postępów prac.
Na początku prace idą całkiem żwawo (ogólny zarys zadania), ale dopiero w trakcie odkrywane są nie przemyślane wcześniej przypadki brzegowe, przez które zadanie zajmie więcej czasu się spodziewano.
import thisThe Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!