Но мы так не умеем, нам прежде чем тесты писать, нужно все узнать про код, что не только не помогает сделать хорошее решение, но ещё и сильно мешает.

Зная что ошибки будут 100% не работать над процессом предполагающим их минимизацию, а пытаться "не пропустить их в прод"

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

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

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

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

Мне это высказывание кажется постановкой диагноза по аватарке. Если вы не узнали цитату из анекдота - извините, я её специально в кавычки взял.

TDD это не про фикс багов и не про тесты вообще. Все кто утверждают обратное его не пробовали. TDD - это про дизайн кода, а не про тестирование.

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

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

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

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

Тут у меня вообще ломается мозг. Если код пишется заведомо быстро для проверки гипотез (как правило это делают специально костыльно чтобы минимизировать время и как можно раньше гипотезу проверить/опровергнуть), какой смысл в этом случае в код-ревью? Он же во первых замедляет проверку гипотезы в разы (например может до 2 недель задача находится на ревью), а во вторых если гипотеза не подтвердится, код будет удален. Зачем тратить столько времени и денег?

А вдруг гипотеза подтвердится? 🤣

Спасибо, попробую.

По мне так в таком случае имея какашку на коленке набросанную можно нормально сесть и переписать с нуля. Причем за меньшее время чем будут ревьювить. Со всеми нужными тестами.

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

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

Поскольку системы социально-технические, то мы вынуждены рассматривать хуманов как часть информационной системы.

А ты выключи социальную

Автоматизируй ту часть которая называется человеческий фактор

А тогда никаких ИС не будет, хуманы часть системы

Пока мы так не умеем

Пусть хуманы будут ревизорро