Предположим есть код, переданный в наследство, который нужно дорабатывать. Написан запутанно, низкоуровневые операции с многопоточностью, длина черти какая, усложнено на ровном месте.
Тестировался полгода грубо говоря, за полгода на конкретном стенде проблем выявлено не было. Соответственно если туда не лазить, и считать это худшим местом проекта — то вроде как и не страшно.
И вот, уже на финальном тестировании уже у заказчика выясняются проблемы, связанные со спецификой стенда, запускают на сверхнагруженном стенде (на нем делается куча другой работы, например 10 бекапов параллельно, антивирус, сторонние приложение съедают всю память и 99 процентов времени стенд занимается тем что в своп загружает и выгружает, короче по ощущением на 386 машине это все запустили), что аж видно как окошки перерисовываются, и в таких условиях начинают всплывать все возможные race condition и вообще.
И уже приходится для фикса лезть в этот код, который по хорошему нужно было переписать полгода назад, сразу же.
Итого вопрос, как делать оптимальнее — сразу же в начале работы над проектом все непонятные неочевидные запутанные моменты убирать и переписывать заново, или блин пока гром не грянет, не трогать?
Если знать заранее результат, то нужно было бы переписывать. Но результат не знаешь, и без этого задач хватает. Кто как делает?
