История изменений

Когда код изначально пишется как многопоточный, конечно.

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

В итоге имеем редкий плавающий баг, который в большой кодовой базе трудно локализовать.

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

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

Глобальный изменяемый стейт — это вообще страшная дичь, но такое в ынтырпрайзах сплошь и рядом.

Когда код изначально пишется как многопоточный, конечно.

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

В итоге имеем редкий плавающий баг, который в большой кодовой базе трудно локализовать.

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

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