Техдизайн не отменяет кодревью. Это разные, дополняющие друг друга инструменты 😅

Я бы разделял оценку (которая обычно нужна грубая и как можно раньше) и техдизайн. А уровень детализации сильно зависит от проекта, разработчика, задачи. Иногда до классов нужно дойти, иногда работает 'как в задаче такой-то'.

Конкретно в том случае мы попрощались с человеком.
А так регламенты, которые потихоньку обмазывать автоматикой по возможности. Ну и конечно же постоянная пропаганда и взращивание в людях любви к продукту, уважению коллег и личной ответственности

А почему ты решил, что это только поиск багов?

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

Частенько нахожу. Бывает, что и в своем коде на следующий день 😔

А какие варианты peer review используешь?

то есть есть регламенты о которых узнают когда?

Угу. Согласен. Изначально мы такой деталезированной оценкой боролись с сильными промахами по оценке. Доходило до х10-х20 от изначальной оценки. А потом узнали про дизайн ревью и поняли что оно у нас уже есть как сайд-эффект, но хочется делать его правильно, а не через боль дробления оценки по классам

А там глядишь и оценка будет примерно попадать, когда человек подумал заранее

В ПР попадает уж все после линтеров/анализаторов. И с тестами. Дизайн ревью для задач среднего уровня и выше. Или если Джун или новичок на проекте. ПР делается двумя другими коллегами.

Ну то есть почти никакие. Тогда ответ не показателен.

А что ты подразумеваешь конкретно? По ходу выполнения, конечно, бывает контроль.

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

при этом
1) если фича бизнесу нужна, то усилия всё равно будут затрачены, хоть бы и 10х
2) оверхед на предварительную оценку и подсчёт реальных затрат ненулевой, но по сути это карго-культ

поэтому единственное что имеет смысл - прозрачное обсуждение с бизнесом реальных внешних дедлайнов ("регулятор сказал с 1 августа должно быть или сильно оштрафуем/закроем", "к 1 ноября должно быть потому что иначе потеряем оборот на рождественских распродажах") и фокус на них, за счёт менее приоритетных задач

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

Посмотри доклад )

я уже смотрел какие-то ваши доклады на эту тему  - насчет противопоставления код ревью и дизайн ревью я все равно не соглушась 🤷‍♂️
для меня эти оба инструмента - ок, они дополняют друг друга

@dphil Здравствуйте. Скажите, а чеклисты, про которые вы упоминали на сессии Подлодки вы шарили где нибудь?

Конкретно интересует чек лист для дизайн ревью

Ну, вообще на эту тему докладов к меня не было. Было обсуждение-семинар, но это не совсем то.

Нет, но я понял, что надо пошарить несколько. Хотя это все тоже каргокульты )