Разработчикам лень работать: как компании выворачивают карманы за пересоздание своей ИТ-системы
Когда компания хочет обновить свою ИТ-систему, ее ждет куча вредных советов от программистов: удалить, выкинуть, написать заново на другом языке. Этот подход в 99% выгоден только самим разработчикам, бизнесы из-за него разоряются. А теперь подробнее.
Все это очень спорно и полемично.
Но я попробую придраться к итогам.
"Обновляйте сервис, если бизнес сильно вырос или изменился, технологии морально устарели."
Зачем? Зачем, ломать и перестраивать то, что работает?
Если калькулятор на столе у бухгалтера работает уже 10 лет, значит ли это что его надо поменять? Ведь и элементная база старая, и морально он устарел. Новые калькуляторы намного красивее и считают быстрее на 0,2 секунды!
Может все-таки стоит исходить от изменений бизнеса, новых потребностей?
"Поэтапно модернизировать проект — самое выгодное решение для компании в большинстве случаев"
Тут есть оговорка "в большинстве", уже хорошо )
Но эта фраза вытекает из теоремы что "писать сервис с нуля — плохая идея в 99% случаев", которую доказывается утверждением:
"На разработку сервиса с нуля обычно уходит примерно столько же времени, сколько было потрачено на его создание в первый раз."
Что собственно, на мой взгляд, является безосновательным.
Почему столько же времени?
Идея уже имеется, бизнес-логика проработана, даже интерфейс нарисован.. Почему столько же времени то?
И поэтапная модернизация, опять же на мой взгляд, самое дорогое решение.
И как раз вот это "Использование готовых частей кода", является одним из самых дорогих решений.
Так как:
-многократно используемые компоненты в три раза более трудоемки, чем одноразовые компоненты;
-Модификация повторно используемого кода крайне чревата ошибками. Если надо изменить более 20-25% кода компонента, то лучше переписать его с самого начала.
Ну и под "коду":
Стоимость сопровождения обычно составляет от 40 до 80% (в среднем 60%) стоимости ПО. Следовательно, эта фаза его жизненного цикла, возможно, самая важная. Примерно 60% расходов на сопровождение приходится на улучшение кода и около 17% – на исправление ошибок. Таким образом, в основном сопровождение и поддержка ПО заключается в добавлении в него новых возможностей, а не в его исправлении.
Спасибо, что так подробно!))
Илья, мне кажется, что вы в своих рассуждениях упустили самое главное - постоянные изменения в бизнесе, которые за собой тянут такие же постоянные изменения в приложении. Очень редкая ситуация, когда приложение создали и дальше пользуются им годами без каких-то изменений. Ваш пример с калькулятором именно про это. Бухгалтеру через 10 лет уже не калькулятор нужен, а планшет с самой свежей версией его бухгалтерской программы, а вы его калькулятором заставляете пользоваться...
Вопрос в том, изменились ли потребности бизнеса.
У одного старого заказчика до сих пор крутится код, который я написал в 2003-м году (выглядит ещё хуже, чем в примере в статье ;). Писалось это на php4, на 5.3 работает, дальше уже нужны существенные изменения. Ничего, в максимально изолированной виртуалке с бэкпортом php 5.3 на современный Debian работает - и нормально, та функциональность до сих пор устраивает.
А вот что-то там (кроме совсем мелочей) пытаться менять точно бесполезно, проще переписать с нуля.