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

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

Такую глубокую перестройку IT-специалисты называют рефакторингом.

Рефакторинг проекта может оказаться неизбежен, например, из-за смены команды разработки. Допустим, прежняя команда, профессиональные качества которой оказались, скажем так, несколько переоценены, сдает проект с заглушками вместо функциональных блоков. Заглушки эти способны корректно отрабатывать пару-тройку стандартных тестов, но выдают отказ на всех нестандартных. Обмануть невнимательного заказчика такими ухищрениями можно, но заинтересованного пользователя - никогда. Для исправления таких артефактов разработки приглашается новая команда (потому что старой-то уже веры нет), которая может прийти к выводу: для спасения ситуации проект придется перестраивать настолько глубоко, что, возможно, проще будет создать новый на принципиально других основаниях. Потому что не могут по-настоящему надежные конструкции опираться на труху и разруху...

Разблокируйте чтобы читать дальше
Чтобы прочитать этот текст, пожалуйста, оформите подписку