У нас есть продуктовый и технический менеджмент, я вот архитект домейна, в мои метрики входят штуки типа mttr(mean time to recover), чтобы это время было небольшое есть гайдлайн как писать, тестить и деплоить фичи. Я делаю код ревью 90% кода- это проверка, чтобы прод не упал, что фича реализована согласна спецификации и так далее. Команды у которых не было код ревью, оставили после себя сервисы, которые невозможно допиливать и бизнес это наглядно видит. Такой вот банальный ответ.

а шо за домейн?

можно увидеть фото?

Если вообще нет практик работы с качеством - то конечно будет плохо.
Code review - просто далеко не лучшая из этих практик, но лучше их полного отсутствия.
Ну и, похоже, развитием команд никто не занимается и с сильными техлидами проблема. В таком случае да - лучше надеятся на формальные требования, вдруг помогут. Но это, конечно, дорого.

А, и похоже с тестами все не очень хорошо (

а у кого-то есть практика код ревью до стадии тестирования, чтоб пока не прошло код ревью в тесты не отдавалось?

Платежки для такси, доставки еды и еще пары сервисов. Где-то 10 бекендеров вполне справляются с поддержкой. Он не очень большой по фичам, по траффику тоже небольшой

а сколько микросервисей?

Ну, 10 бэкендеров - это достаточно для полноценной платежной системы )

И не про поддержку, а про разработку и активное развитие.

Code review лучшая практика. Она у нас поверх тестов и все остального. Особенно для новичков, которых мы онбордим. Они привыкли антипаттерны писать, а им где-то месяц реджекты ставят на код ревью- сильно улучшает качество кода в итогеz

Эээ, пока я вижу у вас, извини, сплошные антипаттерны в работе

Онбордить через code review - это полный кошмар же для всех участников.

Зато тимлид при деле, все время ревьювит

У нас ревью на дизайн документа. А вот тесты обязательно должны быть в merge request, без этого я смотреть не буду;)

испанский сапог только первый раз всем не по размеру

я имел ввиду стадию тестирования - QA

а если я ридмишку обновил)))

Почему? даешь челику задачку, объясняешь домейн, далешь для него дизайн документ (вот структора таблиц, вот апи, вот общая система вызовов). Он пишет. Код проверяется. Потом еще раз. потом он сам предлагает дизайн документ. и где-то через месяц он уже разбирается в нескольких сервисах и почти полностью автономно может деливерить фичи. А как вы предлагаете онбордить? learn by doing самый лучший же подход нет?