хм... чеклисты для экономии мыслетоплипа... надо все ж поподробнее Дорофеева послушать.

я уже посмотрел, мы и используем абсолютно всё, что сказано у тебя в слайдах. Твой доклад - отличная попытка приложить какую-то линейку, выделить критерии.

Мы и проводим peer review(думаю и в мелких компаниях делают это): проверяем читаемость кода, архитекруру, бизнес логику, а ещё проводим гильдии и внутрение доклады, пишем доку и PoC. Но для меня всё это выглядит комплексно и описывает code review, потому что это не просто пролистать код и заапрувить.  Хотя бывают и такие виды ревью, да.

Ещё вопрос, где в докладе шутки? Ну вот правда

шутки должны быть не в слайдах)

вот вот

вот пункт заинтересовал про внешнее ревью - насколько внешнее?

вообще внешние консультанты - насколько распространено?

и насколько сложно организовать/найти

или это скорее доступ к узким специалистам

когда надо раз в месяц

вот кстати это самая большая ошибка у неопытных ревьюеров. Потому что даже задавая вопросы, можно определить задумку более скиллового автора/получить экспертизу

у нас понятие внешнее ревью это про ревью от других команд. А то о чём ты спрашиваешь, это обычно аудитом называют

поощряется, но рефакторинг должен идти отдельно

а вот тесты - нет :)

моё личное мнение, одно включает второе, может использоваться по отдельности. да и линтеры/форматеры/тесты это больше про ideal review в твоей картине мира

По поводу чеклистов - выглядит больше как недонастроенный процесс разработки/релизов

какие-ето чеклисты автоматизируются, какие-то нет

у меня перед релизом есть чеклист из категории "заревьювить миграции"

есть чеклисты у QA заревьювить новые баги

мол передать супорту "что их ждет"

лучше иметь чеклист и использовать его чем "думать над тем как все сделать автоматом вечность"