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

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

Так я же за, не против. Т.е. Дизайн сессия -> парное программирование -> code review 🤪

а работать когда? )

В выходные (шутка)

шутка? )

Ну про это я и говорю:)

чем А лучше Б к счастью легко решается.

любая архитектура оптимизированна под что-то: тестируемость, скорость разработки, стоимость разработки, operations и тд.

если вначале процесса договорились под что оптимизируем (вообще это решение которые принимают люди на уровнях выше вашего) то ответ чем А лучше Б должен быть очевиден

И тут ты тоже прав, суть этого диалога в том, чтоб читающий задумался о надобности код ревью и ответе на вопрос, а какую именно функцию он у вас выполняет и как можно это сделать подругому

Есть ещё цели бизнеса, краткосрочные и долгосрочные, и это одна из метрик того, какое из решений лучше подходит. И я тут не о "заработать больше денег", а о нормально прописанных целях

вообще code review это дорого. один ждет code review и ничего не делает, другая выключается из текущего контекста и переключается в review, а затем обратно… теряем несколько человеко-часа на ровном месте с очень туманными перспективами… я не понимаю какие риски у команд которые проводят code review абсолютно всему. если это команда боинга, то скорее всего это карго культ

Я бы сказал 1) команды где большая разница senior / junior в количестве, хотя даже пара человек все испортит (но тут можно решить парным программированием, но потери будут те же 2) плохо сформированная задача (таких к сожалению много, в моем мире) 3) требование complaince

В пункте 2 ещё вариативность решения, которую можно решать либо парным программированием либо обсуждением с лидом решения

Да можно и курл дернуть в цикле, только лучше еще юзерагент менять и прокси перебирать:)

имхо code review необходим когда у тебя меняется домен, структура данных или выходишь за пределы границы дозволенного.

junior работает в своей песочнице (класс, метод, функция, компонент), они не дизайнят ничего нового и риск того что они что-то сломают минимальный. в своей функции они могут делать все что они хотят. проверять их надо в первую очередь линтером и sonar qube с default quality gate. у джуниора есть тимлид который следит за тем, что джуниор пишет. джуниору можно позвонить в любой момент и попросить расшарить скрин. пропускать джуна через целый code review процесс не нужно.

плохо сформулированная задача решается методом review before code

требования complience - у каждого свое понимание как этим требованиям соотвествовать, н о это не должно сильно бить по экономике (code review бьет сильно).

Тут на конференции по посгресу показали "NORM - фреймворк без ORM". Мы тут все угорали с лингвалео, так там какой-то лютейший микс лингвалео и монго дб:

select * from account_update($${
  "phones":[{"phone_id":"4", "phone":"3123334557"}]}
$$::json, 4);

В уведомлениях и отключаются:) С телеграмом они как-то странно стали работать. Несколько месяцев назад нормально все было

select * from account_update($${
  "phones":[{"phone_id":"4", "phone":"3123334557"}]}
$$::json, 4);

Лингвалео это которые бизнес логику в postgres утащили?

select * from account_update($${
  "phones":[{"phone_id":"4", "phone":"3123334557"}]}
$$::json, 4);

что за треш?

спасибо, вроде полечил 🙂 Просто оно как-то не тривиально вырубалось, не сразу нашел как.