Привет! Меня зовут Дмитрий Панькин, я основатель компании, которая создает сложные ИТ-продукты для клиентов: сайты маркетплейсов, B2B-порталы, личные кабинеты, приложения, кастомные CRM- и ERP-системы.

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

В этой статье я расскажу, почему чаще всего не стоит строить ИТ-систему с нуля и лучше поэтапно модернизировать то, что есть. А также объясню, из-за чего большинство разработчиков будут доказывать вам обратное ????

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

Когда пора обновлять сервис или систему

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

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

  • не используют автоматизированные тесты;

  • не строят устойчивую архитектуру;

  • не проводят перекрестное код-ревью; 

  • не следят за чистотой кода.

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

Технологии устарели. С момента написания ИТ-системы может выйти несколько новых версий языка программирования — в итоге ваша версия устареет и окажется без официальной поддержки.

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

Мы в Resolventa используем PHP, поэтому в статье будем говорить именно о нем. Например, мы настоятельно рекомендуем обновить сервис, если версия PHP ниже, чем 7.0. То же касается устаревших фреймворков, например: Yii, CodeIgniter, CakePHP, Symfony 2.0.

Чтобы понять, поддерживается ли версия языка, которую вы используете, загляните в список релизов на официальном сайте. В случае с PHP нужно зайти на php.net, а для фреймворка Symfony — на symfony.com.

На скриншоте пример того, как мы обновили версию PHP при модернизации одного из проектов. В результате сайт стал загружаться в 2,5 раза быстрее
На скриншоте пример того, как мы обновили версию PHP при модернизации одного из проектов. В результате сайт стал загружаться в 2,5 раза быстрее

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

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

Итак, если что-то из перечисленного выше про ваш сервис, значит, его нужно обновить.

Почему разработчики иногда дают вредные советы

Когда руководитель бизнеса обращается к программистам, чтобы обновить ИТ-систему, он часто слышит, что переписать сервис с нуля — это единственное правильное решение. Я даже знаю, откуда взялось это утверждение.

У каждой компании свой технологический стек: одно агентство специализируется на PHP, другое — на Python, третье — на Node.js. Если у заказчика другой стек, разработчики просто не могут погрузиться в чужой проект, потому что у команды нет специалистов, которые работают на этом языке программирования.

Скриншот с сайта компании «Резольвента», на котором показан стек наших специалистов. Вы можете найти подобный список на сайте любой ИТ-компании. Это поможет узнать, работают ли они с теми же технологиями, что и ваши разработчики
Скриншот с сайта компании «Резольвента», на котором показан стек наших специалистов. Вы можете найти подобный список на сайте любой ИТ-компании. Это поможет узнать, работают ли они с теми же технологиями, что и ваши разработчики

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

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

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

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

Почему писать сервис с нуля — плохая идея в 99% случаев

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

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

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

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

Когда писать с нуля все-таки нужно

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

Используемые технологии безнадежно устарели. Проект придется создавать заново, если технологии не просто морально устарели, а умерли. Так бывает, если версия языка, на котором написан ваш сервис, уже давно не поддерживается. Например, когда продукт написан на PHP 5.0, который устарел еще в 2008 году.

<!DOCTYPE html>
<html>
<head>
    <title>Блочная верстка</title>
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>
<div id="container">
	<?php include ("blocks/header.php");?>
	<?php include ("blocks/navigation.php");?>
	<?php include ("blocks/sidebar.php");?>
	<div id="content">
	<h2>Основной контент страницы</h2>
	</div>
		 
	<?php include ("blocks/footer.php");?>

</div>
</body>
</html>

Если код вашего сервиса выглядит так — модернизировать его не стоит. Лучше похоронить и писать с нуля

Использованы CMS. Такие конструкторы, как WordPress и Bitrix, хороши для небольших или типовых интернет-магазинов и других несложных ИТ-систем. Если бизнес растет, со временем ему потребуются новые индивидуальные решения, которые невозможно реализовать на CMS.

Увы, модернизировать сервис, изначально написанный на CMS, невероятно дорого и сложно. Для этого нужно знать устройство конкретной CMS изнутри и не просто конфигурировать ее, а уметь переписывать важные части исходного кода. На рынке таких специалистов очень мало.

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

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


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

Сайт создавался больше 20 лет назад, и все это время его дорабатывали и развивали разные разработчики. В итоге заказчики решили перезапустить проект.

Сервис можно было только написать с нуля, и вот почему:

  • Некоторые разделы были отдельными сайтами — пользователям надо было даже заново регистрироваться.

  • Проект написан неоднородно. Одни разделы — на чистом PHP без фреймворков, другие — с помощью WordPress.

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

  • Данные копились в проекте с 1998 года, таблицы и поля в них тоже заполняли на двух иностранных языках вперемешку.

Что мы сделали. Разработали новый портал с нуля с помощью современного фреймворка Laravel. Для клиента было важно полностью сохранить всю базу данных — мы изучили 172 таблицы и перенесли информацию на новый портал.

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

Результат. Мы полностью переработали архитектуру и с нуля написали платформу. Код проекта теперь написан понятно, в едином стиле, с комментариями на английском языке там, где они необходимы.

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


Почему поэтапно модернизировать старый сервис — лучшее решение для бизнеса

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

Если руководство выбирает тактику поэтапного восстановления, можно будет расширять и наращивать эффективность бизнеса параллельно с воссозданием ИТ-системы. Не придется ставить процессы на паузу на пару лет, пока пишется новая программная платформа для компании.

Руководству бизнеса может показаться, что модернизировать сервис дороже, чем разработать заново. Это не всегда так. На окончательную цену влияют несколько факторов. Рассмотрим сначала те, что повышают цену поэтапного восстановления:

  • Оплата квалифицированных кадров. Модернизация — более сложная работа по сравнению с созданием проекта заново, поэтому здесь требуются специалисты более высокого уровня. Их стоимость выше, поэтому зарплаты могут увеличить бюджет.

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

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

Но есть моменты, которые снижают цену работ по модернизации:

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

  • Работа всего одной команды. Нет необходимости держать отдельных разработчиков для поддержки старого сервиса и создания нового, вы не раздуваете штат программистов.

Чтобы точно определиться, какой вариант оптимален для бизнеса, я рекомендую провести квалифицированный внешний ИТ-аудит. Специалисты посмотрят, в каком состоянии находится ваш сервис, подсчитают затраты на написание с нуля и на модернизацию и помогут сделать вывод.

В нашей практике много примеров, когда модернизация спасала компанию от простоя и помогала активно развиваться параллельно со всеми доработками.


Пример из практики. Сайт FishingSib создали в 2000-е как форум для рыбаков-любителей. Сейчас он насчитывает 10 тысяч посетителей ежедневно. На портале есть доска объявлений, новостная лента, карта рыбных мест, персональные блоги и другие разделы.

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

Что мы сделали. Плавно модернизировали сервис и перенесли его на современный фреймворк Symfony. Для этого мы сделали следующее:

  1. Написали более 150 автотестов для старого кода, чтобы ничего не сломать в процессе модернизации, — ведь сайтом ежедневно пользуются тысячи людей, и это важно.

  2. Добавили слой с промежуточными обработчиками Middlewares. Они использовались и для старой, и для новой версии сайта одновременно. Например, выполняли переадресацию или проверяли авторизацию.

  3. Настроили связь между фреймворками CakePHP и Symfony. Без нее было невозможно наладить одновременную работу разделов сайта, которые были написаны с разницей почти в 10 лет. Разработчики писали функции так, чтобы при необходимости можно было выполнить блок кода из CakePHP в Symfony и наоборот.

  4. Поочередно перенесли все разделы сайта на Symfony так, чтобы сайт не переставал работать. На этом этапе, если появлялся запрос от клиента, также создавали новые функции, не дожидаясь полного переноса.

Завершили всё уборкой — удалили старый сайт на CakePHP, поскольку вся нужная нам логика уже появилась в новом сервисе. Модернизация заняла три года, но бизнес не простаивал все это время и не терял прибыль.

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

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

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


Итоги: что делать с устаревшим сервисом

  • Обновляйте сервис, если бизнес сильно вырос или изменился, технологии морально устарели или, например, прошло 10 лет с последней модернизации.

  • Поэтапно модернизировать проект — самое выгодное решение для компании в большинстве случаев. Так вам не придется удваивать расходы, терять прибыль и клиентов, а также замораживать рост бизнеса.

  • Переписывайте сервис с нуля, если он сделан на PHP 5.0 и более ранних версиях или написан с помощью CMS. В этих случаях модернизировать сервис будет сложнее, чем писать заново, — а значит, это займет много часов у программистов и обойдется чересчур дорого.

Комментарии (20)


  1. Sap_ru
    00.00.0000 00:00
    +17

    Есть мнение, что бизнес склонен полностью игнорировать накапливающийся технический долг, моральное устаревание системы и тот факт, что с какого-то момента расходы не её развитие начинают расти экспоненциально. В результате бизнес получает свои доходы с устаревающей системы, но эти доходы непрерывно падают, а потом оказывается, что у бизнеса уже нет денег на переход на новую систему. А всё потому, что на падение доходов бизнес отвечал ростом скидок, увеличением рекламных расходов, расширением штата продажников при уменьшении расходов на разработку и прочими не техническими мерами. Но так как продукт не совершенствуется, то клиентская база всё равно падает. А потому примерно совершенно всегда через условные пять лет оказывается, что денег и времени на разработку с ноля нет, так как текущие совершенно фантастические (иногда даже растущие) обороты уходят на то, чтобы вывести имеющееся старьё хотя бы в безубыток. В результате проект хиреет и медленно умирает. А на его место приходят те, кто написан аналог с ноля, использовав при этом 10% годового бюджета обанкротившегося конкурента. И все очень сильно удивляются, что стартап похоронил очередного мамонта.
    Короче, бизнес не хочет вникать в техническую часть, неверно оценивает перспективы и совершенно всегда предпочитает реагировать на изменения нетехническими бизнес-мерами, котороые только ухудшают ситуацию.
    И ещё бизнес очень не любит думать о том, откуда вообще берутся новые лидеры рынка, если ещё недавно на их месте были монстры с огромными бюджетами, которые с точки бизнеса всё делали совершено правильно. Последний момент особенно забавен, так если менеджерам и управленцам показывать историю развития любого из ушедших лидеров, то они с точки зрения бизнеса одобрят каждый сделанный шак и каждое принятое решение. Но если потом показать, что в результате компания тихо мирно умерла и ушла с рынка, то будет некоторый шок. Но выводов сделано не будет, так как техническая часть, являвшаяся источником проблемы, лежит вне понимания принимающих решения.


    1. dmtr81 Автор
      00.00.0000 00:00
      +2

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


      1. Sap_ru
        00.00.0000 00:00
        +4

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


    1. Apoheliy
      00.00.0000 00:00
      +1

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

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


    1. PuerteMuerte
      00.00.0000 00:00
      +2

      моральное устаревание системы и тот факт, что с какого-то момента расходы не её развитие начинают расти экспоненциально

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


      И ещё бизнес очень не любит думать о том, откуда вообще берутся новые лидеры рынка,

      99% бизнеса — это нифига не ИТ-компании, не финтех и не поставщики контента. У них нет такой проблемы, что в один прекрасный момент просыпается молодой стартап и всех стариков съедает.


    1. Ant80
      00.00.0000 00:00

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


  1. muskratrun
    00.00.0000 00:00
    +3

    Согласна. А еще если переписывать с нуля, то где гарантия, что не налепят такую же фигню, как в первый раз :)) так можно бесконечно переписывать и денежки отстегивать


    1. Refridgerator
      00.00.0000 00:00

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


  1. alexander222
    00.00.0000 00:00
    +4

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


  1. Agel_Nash
    00.00.0000 00:00
    +1

    В статье не хватает опроса как минимум с такими вариантами

    • Начать с нуля (на любом языке) не взирая ни на что

    • Начать с нуля если проект на CMS или мамонт на PHP < 5.0

    • Покрытие тестами и последующая модернизация

    • Модернизация с последующим покрытием тестами

    • Багфиксы пока проект не умрет


  1. SamOwaR
    00.00.0000 00:00
    +1

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

    Откуда взята такая информация? По своему опыту скажу, что даже та же самая команда, напишет код второй раз быстрее и "чище". Если отдавать новой команде - то зависит от квалификации. Но опять таки, новой команде будет легче, так как система уже устоявшаяся (не нужно будет в процессе разработки что-то кардинально менять), процессы понятные, на что приходится наибольшая нагрузка - тоже примерно ясно.


    1. Agel_Nash
      00.00.0000 00:00

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

      Лучшее решение, которое я только встречал, это переписывание проекта по эндпоинтам (первые итерации долгие, но дальше легче) и точечное переключение ендпоинтов на новый код средствами веб-сервера


    1. Apoheliy
      00.00.0000 00:00

      "Чище" - обычно да. "Быстрее" - бывает по-разному: они же не то же самое пишут, а нечто новое с учётом своих знаний. А когда пишут нечто новое всегда есть соблазн втопить новый стэк, новые плюшки и т.д. И это явно не способствует "быстрее".


    1. dmtr81 Автор
      00.00.0000 00:00

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

      В общем, конечно, оценка очень приблизительная и в первую очередь дана для ориентира менеджерам, а не разработчикам.


  1. Apoheliy
    00.00.0000 00:00

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


  1. Travisw
    00.00.0000 00:00

    Я вот написал свои пет проект на api 1990х годов, узнал об этом в прошлом году - теперь надо переписывать на свежак хотя 10х годов. Я в ауте от самого себя и того что весь отпуск месячный мне придется читать новое апи и гуглить его ошибки и переписывать. Хотя если не парится о коде то проект вполне mvp


  1. hVostt
    00.00.0000 00:00
    +4

    Переписывание проекта это не только обновление технологий, но и переосмысление. Из практики, переписывание старого проекта практически с нуля, привело к тому, что почти половина (а то и больше) функционала просто были удалены, или консолидированы. Также были исправлены бизнес-сценарии, которые раньше просто нельзя было сделать "по техническим причинам". Очевидно, что с технической стороны всё было актуализировано: удалены больше не поддерживаемые библиотеки и решения, обновление протоколов взаимодействия. Прирост производительности, понятно, но это не главное. Главное -- это мониторинг, которого в легаси проектах обычно отродясь не бывает, или он очень плохо совместим с современными инструментами. Что по срокам? Проект, который пилили 2 года, переписан за 2 месяца.

    Это я взял один конкретный пример из практики. Понятно, что он не экстраполируется. Но, всё зависит от подхода, компетенций и команды.

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


    1. dmtr81 Автор
      00.00.0000 00:00

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


  1. koreychenko
    00.00.0000 00:00
    +1

    Несколько примеров "почему":

    1. Выходят новые версии языка, которые приносят кучу новых фич. Например, когда проект начинался был ПХП 5.7 а сейчас уже 8.1 со всеми прелестями.

    2. Проект начинался на Zend, тупо потому что ничего другого раньше не было. Хочется переписать на Symfony, потому что зенд это каждый раз боль и постоянно что-то не поддерживается.


  1. Blacker
    00.00.0000 00:00

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

    Бизнес и технари со своим техдолгом — это как человек и ЗОЖ. Все бы хотели "пить, гулять и веселиться", но мы знаем, к чему это приводит рано или поздно (скорее рано). Если говоря с бизнесом, вы чувствуете, что перед вами не "ЗОЖник", а тот, кто при возможности предпочёл бы "гулять и кутить", скорее всего он предпочтёт экономить на технических вопросах в интересах прибыли. Не тратьте на таких свою жизнь — оставьте их со своим "гедонизмом" наедине. Ищите "ЗОЖников".