Наверное, каждый из вас слышал о SOLID, KISS, DRY, DI, HWDP и других популярных наборах хороших практик программирования.
Но позволю себе предположить, что никто не знает принципов CHAD, касающихся хороших практик работы с системами контроля версий и рецензирования кода.
Ну что же, приступим!
C – Clear History
История должна быть чистой, как твоя комната после прочтения книги Джордана Питерсона (с). Ну или как хорошая водка! Каждый коммит должен иметь смысл, никаких "quick fix" или "small refactoring". И никаких говнобранчей пятилетней давности в репо.
H - Hermetic PR
Каждый создаваемый пулл-реквест должен содержать в себе конкретное изменение функциональности или обособленную часть крупных изменений. А если, по каким-то причинам, это невозможно, то хотя бы включи голову и придумай нормальный заголовок вместо "Add new table + add migration + add some test + fix some issues + use new table in code".
A - Alternative Review
Сделать ревью кода не означает проверить, что тесты светятся зелёным, и запустить код локально и подтвердить "У меня работает". Недостаточно даже пробежаться по списку - SOLID, KISS, MPK, MPO, PDK. Подумай - нельзя ли реализовать фичу лучше, чем автор пулл-реквеста. Если возможно - предложи реализацию автору, обсудите вместе возможные решения.
D - Detailed Comment
Уточнённый принцип C. Пиши нормальные описания коммитов (commit-messages). Знаю, что ты пошёл в программисты, потому что ненавидел писать сочинения в школе, но раз уж зарабатываешь 100500к/наносек и умеешь печатать разные смешные символы на клавиатуре, то было бы неплохо уметь описать словами то, что понаписывал в коде. А не всякую хрень, в стиле "use new method", "fix bug", "modify interface" и т.д.
