Это я у вас спрашиваю )))

Вы как считаете?

Я уточнил, это ли вы спрашиваете. Мне просто ваши вопросы не очень понятны, поэтому я решил своими словами сформулировать то, что я понял.

Я могу предположить, что, наверное, это были очень простые задачи. Типа "переименовать файл, на который есть ссылка из одного места в коде".

Я говорю так: у вас есть новенький, вы ему дали задачу 1 и посмотрели результат, все понятно, потом выдали ему задачу 2 проверили и все понятно, потом задачу 3 и опять все понятно. Зачем смотреть задачу 4? Чтобы что?

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

Мы же про читаемость кода начали говорить, а не про качество решения. Давайте не смешивать все в кучу

Я не понял вопрос

Вопрос в том, как сохранять качество этого часто изменяемого куска постоянно, а не бросаться переписывать тогда, когда уже без поллитра не разобраться

Потому что до любой задачи, простите, можно доебаться при желании? Если не получилось, значит задача маленькая?

В этой формулировке я считаю, что да, конечно есть необходимость смотреть.

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

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

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

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

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

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

Попробуйте задать этот вопрос в менее провокационном тоне. Если вам, конечно, интересен ответ, а не вставить свою реплику.

код ревью, как процесс разработки - не нужно, я за эту сторону)

Смысла реально нет, потому что одна сторона уже это переросла а другая еще нет. Тут же не вопрос А или Б. Речь об опыте. Кто-то не доходит до код-ревью, кто-то доходит до код-ревью, кто-то идет дальше, кто-то останавливается на месте.

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

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

Аргументы же за код ревью нужны. Я пытаюсь подвергнуть критике свою гипотезу "кодревью не нужен" ))

Я не так написал