CHAD Principles!

Każdy zna i słyszał o SOLID, KISS, DRY, DI, HWDP i innych popularnych zestawach dobrych praktyk w programowaniu.

Ale założę się, że nikt nie zna pryncypiów CHAD dotyczących dobrych praktyk korzystania z systemu kontroli wersji i recenzji kodu.

Do rzeczy!

C – Clear History

Historia ma być czysta, jak Twój pokój po przeczytaniu książki Jordana Petersona! Ewentualnie jak dobra polska gorzałka! Każdy commit ma być sensowny i ma mieć znaczenie, żadnych „quick fix”, „small refactoring”. I żadnych gównobranczy sprzed 5 lat…

H – Hermetic PR

Jak robisz PR, to ten PR ma być na konkretną zmianę – konkretną funkcjonalność albo jej logiczną część. A jak się nie da w osobnych PR, bo się nie buduje, to rusz głową, żeby dać lepszy tytuł niż „Add new table + add migration + add some test + fix some issues + use new table in code”

A – Alternative Review

Code Review nie polega na tym, że patrzysz czy testy zielone i czy u Ciebie działa. Nawet nie wystarczy, czy zrobisz czecklistę SOLID, KISS, MPK, MPO, PDK… Pomyśl, czy nie da się tego zrobić lepiej niż autor PR, to zrobił. Jak się da to zaproponuj, pomyślcie razem.

D – Detailed Comment

Bardziej szczegółowe C. Napisz porządnie tę wiadomość. Wiem, że zostałeś programistą, bo ledwo Cię przepuścili w gimbazie za oblanie 99% sprawdzianów z polskiego, ale jak już masz te 20k, umiesz te śmieszne cyferki i literki, to dobrze by było, jakbyś umiał opisać słowami to, co zrobiłeś w kodzie. Nie jakieś gunwo typu „use new method”, „fix bug”, „modify interface”.

Stosujesz, czy jesteś lamus?