Когда БОЛЬШОЙ переписать ответ?

Когда БОЛЬШОЙ переписать ответ?
Когда БОЛЬШОЙ переписать ответ? - martinbennie @ Unsplash

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

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

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

TL;DR Когда большой переписать ответ и какие аргументы вы можете использовать в его поддержку?

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

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

  • Время разгона разработчика очень велико. Если для подготовки нового разработчика требуется больше времени, чем указано ниже (по уровню опыта), значит, систему необходимо перепроектировать. Под временем разгона я имею в виду количество времени до того, как новый разработчик будет готов сделать свою первую фиксацию (для небольшой функции).
    • Только что из колледжа - 1,5 месяца
    • Еще зеленый, но уже работал над другими проектами - 1 месяц
    • Средний уровень - 2 недели
    • Опыт - 1 неделя
    • Старший уровень - 1 день
  • Развертывание не может быть автоматизировано из-за сложности существующей архитектуры
  • Даже простые исправления ошибок занимают слишком много времени из-за сложности существующего кода.
  • Новые функции занимают слишком много времени и стоят слишком дорого из-за взаимозависимости кодовой базы (новые функции не могут быть изолированы и, следовательно, влияют на существующие функции).
  • Формальный цикл тестирования занимает слишком много времени из-за взаимозависимости существующей кодовой базы.
  • Слишком много вариантов использования выполняется на слишком малом количестве экранов. Это вызывает проблемы с обучением пользователей и разработчиков.
  • Технология, в которой находится нынешняя система, требует этого.
    • Качественных разработчиков с опытом работы с технологиями очень сложно найти
    • Он устарел (его нельзя обновить для поддержки новых платформ/функций)
    • Просто доступна гораздо более выразительная технология более высокого уровня.
    • Стоимость содержания инфраструктуры старой технологии слишком высока

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

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

  • Технические
    • Связь компонентов настолько высока, что изменения в одном компоненте невозможно изолировать от других компонентов. Редизайн одного компонента приводит к каскаду изменений не только в соседних компонентах, но и косвенно во всех компонентах.
    • Стек технологий настолько сложен, что проектирование будущего состояния требует многочисленных изменений инфраструктуры. Это было бы необходимо и при полном переписывании, но если это требуется при поэтапном редизайне, то вы теряете это преимущество.
    • Перепроектирование компонента в любом случае приводит к полной перезаписи этого компонента, потому что существующий дизайн настолько бесполезен, что нет ничего, что стоило бы сохранять. Опять же, вы теряете преимущество, если это так.
  • политический
    • Спонсоров нельзя заставить понять, что поэтапный редизайн требует долгосрочной приверженности проекту. Неизбежно, что большинство организаций теряют аппетит к продолжающемуся оттоку бюджета, который создает постепенная модернизация. Эта потеря аппетита неизбежна и при переписывании, но спонсоры будут более склонны продолжать, потому что они не хотят быть разделенными между частично завершенной новой системой и частично устаревшей старой системой.
    • Пользователи системы слишком привязаны к своим «текущим экранам». Если это так, у вас не будет лицензии на улучшение жизненно важной части системы (внешней части). Редизайн позволяет обойти эту проблему, поскольку они начинают с чего-то нового. Они по-прежнему будут настаивать на том, чтобы получить «те же самые экраны», но у вас есть немного больше возможностей для отпора.

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

Делайте это только в том случае, если вы можете быть уверены, что есть политическая воля довести дело до конца. Это означает участие как руководителей, так и конечных пользователей. Без этого вы потерпите неудачу. Я предполагаю, что именно поэтому Джоэл говорит, что это плохая идея. Участие руководителей и конечных пользователей многим архитекторам кажется двуглавым единорогом. Вы должны агрессивно продавать его и непрерывно проводить кампанию за его продолжение, пока оно не будет завершено. Это сложно, и вы говорите о том, чтобы поставить свою репутацию на что-то, что некоторые не захотят видеть успешным.

Некоторые стратегии успеха:

  • Однако если вы это сделаете, не пытайтесь преобразовать существующий код. Спроектируйте систему с нуля. В противном случае вы зря теряете время. Я никогда не видел и не слышал о проекте «конверсии», который не закончился бы плачевно.
  • Переносите пользователей в новую систему по одной команде за раз. Определите группы, у которых САМАЯ большая проблема с существующей системой, и перенастройте их в первую очередь. Пусть они распространяют благую весть из уст в уста. Таким образом, ваша новая система будет продаваться изнутри.
  • Создайте свой фреймворк так, как вам нужно. Не начинайте с какого-то фреймворка, на создание которого я потратил 6 месяцев и который никогда не видел реального кода.
  • Старайтесь, чтобы ваш технологический стек был как можно меньше. Не переусердствуйте с дизайном. Вы можете добавлять технологии по мере необходимости, но убрать их сложно. Кроме того, чем больше слоев у вас есть, тем больше работы требуется разработчикам. Не усложняйте задачу с самого начала.
  • Вовлекайте пользователей непосредственно в процесс проектирования, но не позволяйте им диктовать, как это делать. Завоюйте их доверие, показав им, что вы можете дать им то, что они хотят, лучше, если будете следовать хорошим принципам дизайна.

LetsCodeIt, 19 мая 2023 г., 15:20