Если у вас AWS, Bitbucket, GSuite в стэке, то просто красота)

йеп

Плюс можно одновременно получить iso270001

У них пересечений много по требованиям

а дорогой это сколько

15к в год

Ну мы маленькие ещё, поэтому не много) цена зависит от количества сотрудников в компании

+ за сам аудит

Ага, 10к

мда...

Даже бас-фактор 1.1 лучше, чем 1.0. А бас-фактор равный числу членов команды, если их больше трёх - всё равно утопия.

Ещё одна важная часть фазы ревью - убедиться, что код понятный (т е. про поддерживаемость и future-proof). И кажется, что эта задача решается только тут, потому что только тут ревьюер может осознать, что он не понимает чего-то.

мне кажется у нас уже был с тобой этот разговор. Те вещи о которых ты говоришь, кмк можно заменить другими практиками. Естетственно там будут другие проблемы.
Конкретно те вещи о которых ты написал сейчас можно решить при помози: design review + каждое утро садиться всем вместе (или не вместе) и смотреть на diff кода за вчера. Почему это проще, потому что PR приходит в рандомное время, ревьюишь diff всегда в одно и то же.
При этом я не отрицаю, что у этого подхода есть свои минусы

А как ты видишь это суточное ревью? Делает кто-то один, он же является точкой истины в том как правильно и как нет? Делают все, и что происходит по итогам: дискуссия, одностороннее изменение кода так, как каждый считает нужным?

все эти и другие практики очень хорошо работают совместно. конечно, можно заменять одну другой или несколькими, но если делать и то и другое, то эффект будет накапливаться. если кто-то посмотрел ПР это ж не значит, что можно отправлять сразу в прод (обеспечение качества).  или если кто-то рассказал, как он будет собирается задачу, это не значит, что окончательное решении в коде будет таким же ясным, как на словах. с наличием код стандарта и тулов для автоматической валидации часть проблем, выявляемых человеком на просмотре ПР действительно отпадает, но зато и появляется больше возможностей выявить что-то поинтереснее.

вот тут тоже начинаются варианты. Если нет удаленки, то у нас отлично заходил такой вариант:
- сначала все смотрят код самостоятельно (по желанию), минут 10-20. Потом каждый человек, который вмержил что-то со вчера - рассказываем про те подводные камни, которые он знает и расставляет акценты. Потом обсуждение вопросов ревьюеров и решение - дописываем/исправляем или нет.

Идея в корне такая:
за день, маленькаая команда не напишет много кода и на этой встрече раздают только “важный” контекст + ответы на вопросы, которые волнуют людей в команде

именно по этому нет “золотого стандарта разработки”, мы что-то делаем чтобы избавиться от проблем, которые у нас есть и получить другие взамен. Идея такая: нужно выбирать такую модель, в которой “внештатные ситуации, которые для вас критичны” случаются как можно реже.

соглашусь. в этом смысле сколько проблем решает и сколько приносит ревью кода?

перед деплоем на прод нужно автоматически тестировать миграции на свежей копии продовской бд

как показала практика, ревью глазами и ревью девелоперскими и тестерскими базами недостаточно) заодно будут точные данные о том, сколько займет