Комментарии 7
Вот я бы оверинжиниринг в группу 4 записал. Это часто причина большинства остальных зол.
Хорошая практика: делать подробное описание, которое включает в себя причины, по которым нужна эта задача, и описание решения с пояснением, почему задача решалась именно таким путем.
Противоречит первому же пункту. Если изменения действительно вносятся атомарно, то их не приходится сопровождать портянкой чейнжлога. Иначе автоматически возникают или вопросы к декомпозиции задачи, или к невменяемому неймингу, или к оверхеду в решении.
Портянкой нет. А вот пояснить выбор именно такого решения даже в атомарном коммите нужно. Иначе, появятся вопросы про оверхед или "я бы сделал вот так". А потом долгая переписка о том, почему же все-таки было выбрано именно такое решение. Вроде всем было бы проще, если бы даже атомарный коммит сразу ответил на вопрос "Почему?".
очевидно сейчас - забудется потом. на вопрос в ходе ревью - лучше сделать коммит с комментарием к непонятному, нежели оставлять ответ текстом: бывает сложно понять смысл изменения из кода, а уже по тикетам врядли кто ковыряться будет.
В Перекладывание ответственности ожидал увидеть ситуацию, что никто не рвется делать ревью, если просить команду, потому что всегда может сделать кто-то другой.
Как справляетесь (справились) с этой проблемой? Автоматизированное назначение и оповещение или ручной процесс?
Мы назначаем ревьюверов исходя из задачи. Обычно это человек, который более или менее погруешен в контекст проекта. Возможно это человек который заводил задачу, или если человек пишет в чужой проект, то в ревью должен быть тех лид проекта.
Если честно за свою правктику я ни разу не сталкивался с тем, что кто-то прямо говорил, что не хоче делать КР.
Код ревью с учётом человеческих слабостей