Всем привет! Есть команда FE-девов в 6 человек. Есть проблема того,

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

К примеру, выделять 1-2 человек на день кто будет ревьювить все ПРы, при этом эти люди будут меняться день ко дню

Начать писать тесты покрывая ими каждую фичу и не кидать пр пока все тесты (включая не относящиеся к задаче) не будут покрыты на 100% Ну и если прям все так запущено то намарафетить воркспейс с линтером и строгими правилами что сэкономит 50% времени ревьюверам Ну и никто не отменяет факт что разрабы говнокодят, но это уже не лечится ревьюверами так легко

Линтеры есть, тесты никак не можем продать менеджерам, а им впадлу тратить деньги на тесты, это ж аутсорс. Лучше баги пофиксить еще годик (на деле нихрена, проект фикс-прайс и уже пол года как проект в минуса идет) Проблема скорее именно в том, что разработчики не могу acceptable criteria все прочитать и выполнить. В итоге пока сам не проверишь, не можешь бы ть уверен. Я бы за такое просто увольнял, но не я решаю Потому кроме как долгое ревью не могу найти вариант получше :с А долгое ревью это минус куча времени

Тогда менять компанию

Это я и так делаю 🙂 Но интересный вызов как-то улучшить эту ситуацию, просто полезно для опыта будет Вот и ищу мб какие-то варианты дополнительные Пока что додумался лишь до графика ревьюверов 😄 Мол сегодня одна парочка человек ревьювит, завтра другая и тд Но звучит очень банально и навряд будет решать проблему. Просто эти два человека будут выпадать из процесса разработки

Повышать скилы фронтов в разработке для уменьшения кол-ва багов и повышения качества Как это уже другой вопрос

Постоянные рецензенты лучше переменеых, учитывая что ниже Вы сказали, что разработчики слабые. + Бо‘льшая концентрация на рецензировании. + Накопится больший опыт рецензирования. + Скорее всего найдётся человек, который любит именно наводить «порядок» в коде (вряд ли все в команде любят рецензировать). - Если человек будет только рецензировать долгое время, то у него временно понизится навык написания кода. P.S. Пусть выпадает, его основная задача – рецензирование.

Есть люди, ответственные за отдельные фичи и ценности? Или все отвечают за всё и каждый ни за что?

А вот это проблема аутсорса Отсутствие шеринга знаний и боязнь создания доменных областей для разработчика А вдруг человек уйдет, и больше никто не знает как быстро пилить эту часть кода (с) А то, что в итоге вся команда знает всё и одновременно ничего, ибо тяжело запомнить ВСЕ фичи, никого не волнует :0

Увы, пиление фич более важно чем проверка их на работоспособность 🙂 У нас даже тимлида нету, ибо негоже одного человека выделять на более менеджерскую часть. Лучше иметь 3 барана-менеджера и кучу девелоперов, и всё это микроменеджить 🙂

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

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

Так это единственный путь. Либо ты берешь на себя, либо остаётся по-старому :)

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

Так наоборот менеджмент не хочет чтоб только один это делал, иначе я перестану писать заветные строки кода))) А то что в итоге разгрузится 3 тестировщика и разработчики перестанут реопены фиксить, никого не волнует

Вот и выбирайте лучший из вариантов и всё.