Когда BIG Rewrite ответ?

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

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

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

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

258 голосов | спросил 5 revs, 4 users 48%
Jonn
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

24 ответа


298

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

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

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

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

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

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

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

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

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

  • Если вы это сделаете, не пытайтесь преобразовать существующиекод. Создайте систему с нуля. В противном случае вы тратите свое время. Я никогда не видел и не слышал о проекте «конверсии», который не оказался в ужасе.
  • Перенос пользователей в новую систему за одну команду. Определите команды, у которых боль БОЛЕЕ БОЛЬШОЙ с существующей системой, и перенесите их сначала. Пусть они распространяют благую весть из уст в уста. Таким образом, ваша новая система будет продана изнутри.
  • Создайте свою инфраструктуру по своему усмотрению. Не начинайте с какой-то I-потраченной-6-месячной сборки - этой структуры, которая никогда не видела реального кода.
  • Храните свой стек технологий как можно меньше. Не перепроектируйте. Вы можете добавлять технологии по мере необходимости, но их вынимать сложно. Кроме того, чем больше слоев у вас есть, тем больше работы разработчикам делать. Не затрудняйте работу.
  • Привлекайте пользователей непосредственно к процессу разработки, но не позволяйте им диктовать , как сделать это. Заработайте их доверие, показывая им, что вы можете дать им то, что они хотят лучше, если вы будете следовать хорошим принципам дизайна.
ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
102

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

Есть несколько подводных камней:

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

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

Ошибки могут быть ответом, если:

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

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
66

Пришло время перезаписи, когда:

Стоимость перезаписывания приложения + сохранение перезаписанного приложения меньше затрат на поддержание текущей системы с течением времени.

Некоторые факторы, которые делают поддержание текущего более дорогостоящим:

  • Язык настолько стар, что вы должны платить людям, которые знают, что им нужно много денег для программирования (COBOL).
  • (по опыту, к сожалению). Система находится на старой архитектуре оборудования, которая должна очищать части Ebay и COLLECT, чтобы добавить к машине, на которой она работает, потому что они больше не сделаны. Это называется «аппаратная поддержка жизни» и дорого, потому что, поскольку части становятся более скудными, они (могут) подорожают, или они (абсолютно) в конечном итоге исчерпаются.
  • Он стал настолько сложным, что комментарий //Here be dragons. по всему вашему коду.
  • Вы не можете писать какие-либо другие проекты и добавлять новое значение для компании, потому что вы всегда исправляете этот уродливый зверь.
ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
16

Если вам требуется фундаментальное изменение в архитектуре проекта, время возможно запуститься заново.

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

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

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
12

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

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
11

Стоп! Перезапись почти never ответ. Чаще всего рефакторинг - лучшая ставка.


Конечно, там есть раз, когда переписывание оправдано:

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

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

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

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

Большие преимущества рефакторинга заключаются в следующем:

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

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
9

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

введите описание изображения здесь>> </p>

<p> График претендует на роль руководства, когда оправдана реорганизация устаревшего программного обеспечения, а когда нет. Например, если программное обеспечение имеет высокую бизнес-ценность и качество кода плохое, то реорганизация оправдана. </p></body></html>

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
7

Я работал в небольшой компании-разработчике программного обеспечения, в которой было несколько приложений DOS, которые были обновлены для обработки Y2K, переписаны как 16-битное приложение Windows, а затем полностью переписаны как 32-битное приложение с одной дополнительной «небольшой» функцией (в конечном счете только один клиент), которые повлияли на всю структуру.

Перемещение 16-битного кода на 32 может быть выполнено в течение месяца одним человеком, но NOOOOOOOOO, нам пришлось переписать его, чтобы сделать Soooooooooo намного лучше. Эта вещь может быть адаптирована для других отраслей промышленности, будет иметь полные спецификации и psuedo-код, прежде чем они даже начнутся. Спецификации были созданы, но потребовалось так много времени, чтобы писать реальный код. Он был выпущен поздно, с большим количеством ошибок, чем 16-битный «начался» с (он был на v.3.0 и, наконец, до того момента, когда мы почти сделали его неделю без сообщения о новой ошибке).

Вы думаете, что переписывание одного и того же приложения 3-4 раза приведет к некоторым улучшениям, но я просто не думаю, что интерфейс интерфейса GUI может быть оправдан настолько.

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
7

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

Слияние компаний, огромное перекрытие в функциональности систем. Многие, многие системы были объединены и удалены, а другие все еще находятся в процессе.

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

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
5

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

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

Мы никогда не переписывали все это. Однако мы перестали использовать эту платформу для новой работы и создали новую новую платформу для большого нового проекта. Это было одобрено, и мы доставили отличный продукт за разумное время.

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
5

Итак, вот я сижу за своим столом, я начал переписывать код для этого абсолютного беспорядка одного большого файла aspx, базы данных позади него и замены интерфейса MS Access на MsSQL.

Эта программа asp заполняется такими вещами, как

  • include(close.aspx), внутри которого есть одна строка кода, которая закрывает последнее открытое соединение с базой данных.
  • Устаревший код просто закомментирован случайно
  • Без учета безопасности
  • Код спагетти, тысячи его строк. Все в одном файле.
  • Функции и переменные без четкого значения за их именами

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

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

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
4

У Джоэла Спольского есть отличная статья по этому поводу: Вещи, которые вы не должны делать, часть I

Из названия вы можете сказать, его односторонний (он говорит о том, почему вы никогда не должны бросать код) IMO, есть много правды, я недавно увидел видеоролик channel9 в 25-й годовщине Excel, где некоторые разработчики сказал, что даже сегодня, если вы заглянули в источник, вы проверите ревизию и вернетесь к коду, который использовал excel, который был написан 20 лет назад.

Вы не можете быть на 100% уверенным (когда даже Netscape делает ошибки (из статьи Джоэлса)), I чувствовал, что статья Джоэла была отправлена ​​Богом, потому что я могу быть пессимистичной и люблю выбрасывать кодовое мышление Я всегда могу лучше писать его во второй раз, но я понял только сейчас, это просто дорого стоит .

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

Мой реальный мир: приложение Silverlight. Я развиваю v0.6 до сих пор беспорядок асинхронных вызовов, которые делают код настолько запутанным. Поскольку на этой неделе я обнаружил Reactive Extensions , я действительно хочу переписать кода, но теперь, что я скажу своему клиенту? Программа работает отлично (с некоторыми утечками памяти tho), но они не заботятся? Я не могу сказать им, О, я занимаю еще 2-3 недели, потому что я хочу что-то повторить. Тем не менее, я собираюсь передать код и переписать /играть с ним в мое свободное время.

Просто мои 2 цента в порядке!?

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
3

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

Если вы не хотите менять технологию, код не имеет какой-либо структуры (я видел его очень давно на каком-то веб-сайте PHP, автор просто копировал /вставлял спахетти вместо include /class /function), или вы что-то взяли с другой человек, который очень плохо написан.

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
3

существующее решение не масштабируется.

Я смотрю на вас, MS Access.

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
3

Согласно Джоэлю, большие перезаписи - это одна худшая стратегическая ошибка , которую компания может сделать:

Вещи, которые вы не должны делать, часть I

  

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

     

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
2

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
2

Есть классическая шутка о том, «если я собираюсь в X, я бы не начал здесь».

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

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

  • слишком мало возможностей в отделе,

  • слишком мало бай-ин от клиентов или управления для дополнительной работы,

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

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
2

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

Вместо этого часто возникают перезаписи, чтобы облегчить беспокойство руководства:

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

Большинство этих забот не материализуются, и если бы они это сделали, их можно было бы обработать. Но последнее, самое худшее. Это по существу: у нас нет причины.

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

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

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
0

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

Причина, по которой это так сложно, заключается в том, что вы делаете точную оценку скорости развития команды в новом проекте, пока вы ее не начнете. Тем не менее, если, используя ОЧЕНЬ консервативную оценку скорости развития нового проекта, проект оценивает рентабельность инвестиций, тогда у вас есть бизнес-сценарий для начала заново.

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
0

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

  1. После перезаписывания новых функций будет легче /быстрее /меньше багги для записи
  2. Переписывание займет меньше или равно времени, чем добавление текущей новой функции.

Даже тогда вы хотите ограничить область своей перезаписи. Например, у нас было некоторое унаследованное программное обеспечение в компании, которая была написана на C ++ с мышлением программиста на C, который не знал о модульности. Конечным результатом был код speghetti в виде конечного конечного автомата, который охватывал несколько классов и библиотеки DLL. У нас появилось новое требование, которое сильно отличалось от предположений, встроенных в код, и должно было стать частью запатентованной стоимости продукта для своих клиентов.

Проведя время с помощью кода, реализующего другие функции, у меня было действительно хорошее представление о том, сколько времени потребуется, чтобы выяснить, какие из нескольких операторов switch мне нужно изменить и т. д. Мое предложение состояло в том, чтобы переписать раздел код, который был огромным конечным автоматом - мне нужно меньше времени, чем расширение существующего кода. Я смог объединить в одну DLL то, что раньше было три, и обеспечить гораздо более объектно-ориентированную структуру, которая упростит выполнение критически важных новых функций, а также упростит добавление новых функций.

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
0

При переходе на совершенно новую технологию необходимо обеспечить желаемую функциональность.

«Совершенно новый»: если вы планируете переписывать, но использовать ту же платформу, то рефакторинг и разумная реструктуризация - это, безусловно, лучшее решение. «Платформа», как используется здесь, несколько расплывчата: считайте, что она включает язык, и, возможно, OS (от Linux до Windows или наоборот), но, вероятно, не является каркасом (например, заменяет Struts на Spring).

«Требуется предоставить желаемые функции»: около 2000 года я инициировал проект для перезаписи основного серверного компонента в Java с C ++, чтобы включить поточную обработку потока, кеш-объект и транзакции, контролируемые клиентами. В то время для C ++ было много библиотек для потоковой передачи, которые нам пришлось бы поддерживать, а потоковая поддержка большинства наших кодов базы данных потребовала бы почти полного переписывания. Что касается транзакций, контролируемых клиентами ... не будет со старой архитектурой.

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
0

OP не указывает область действия проекта, но основной ключ, который я взял, был «написан на старом [языке /диалекте] с использованием старых [libs]», которые для меня являются основными драйверами перезаписи. Фактически, большинство проектов, которые я пережил на любом значительном долговечном рынке, в конечном итоге осознают, что размещение обновлений для компиляторов /интерпретаторов /операционных систем является важной задачей при сохранении базы кода.

Короче говоря, я бы планировал переписывать поэтапно, уделяя первостепенное внимание обновлению в библиотеках. Возможно, на этом пути вы можете прокрасться в другие оптимизации, но тот факт, что вы планируете отложить некоторые изменения на более позднем этапе, может стать отличным способом остаться в графике и не «застревать».

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
0

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

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

== Рефакторинг на месте для большего блага и прочее ==

Рефакторинг устаревшего кода с обычным старым инкрементным подходом,

  1. Если у вас есть шанс конвертировать в UML и документировать, какая небольшая дрянная архитектура есть.
  2. Если вы используете контроль над версиями, посмотрите на создание отчетов о сбое кода и выясните, какие файлы и разделы файлов были изменены чаще всего. Запишите их, поскольку они, скорее всего, будут областями, с которыми вы захотите иметь дело в первую очередь.
  3. Перед тем, как вы измените какой-либо код, всегда старайтесь добавить какое-то покрытие (даже уродливые полные функциональные тесты стека). Если вы имеете дело с большой беспорядочной процедурной логикой извлечения логического кода, вы намерены перейти на какой-то разумно названный метод или функцию и, если возможно, добавить несколько тестовых примеров, которые подтверждают ваш новый метод. сделайте все, что вам нужно, и, если возможно, переоцените это изменение, если это что-то обычно подстраивается под ширину поля или титул, поэтому в следующий раз он будет немного более прямым.
  4. Используйте шаблон адаптера и отработайте его, спрятав куски устаревшего кода под ковром логически названных классов и методов, чтобы для большинства обычных задач, которые вы и другие разработчики вам не нужны, вам не нужно беспокоиться о страшных битах, которые продолжая за вашей спиной позади этих хороших маленьких чистых методов и классов, которые вы скрыли, что старый код позади - как те славные семьи, которые держат деформированных убийственных зомби бывших членов семьи в амбарах, чтобы они не портили день за днем, на ферме. , , как обычно.
  5. По мере того, как вы продолжаете стирать и очищать разделы кода, продолжайте увеличивать охват вашего теста. Теперь вы можете выкапывать еще глубже и «переписывать» еще больше кода при необходимости /желании с все возрастающей уверенностью.
  6. Повторите или примените дополнительные подходы к рефакторингу, чтобы продолжать улучшать вашу кодовую базу.

Ветвление по абстракции

  1. Определите место проблемы в коде, который вы хотите удалить (уровень сохранения, генератор pdf, механизм счета-фактуры, генератор виджетов и т. д.).
  2. запустите (напишите, если необходимо) некоторые функциональные тестовые примеры (автоматические или ручные, но вы знаете автоматизированы) против базы кода, которая предназначена для этой функции наряду с общим поведением.
  3. Извлечь логику, связанную с этим компонентом из существующей базы данных, в класс с некоторым разумным интерфейсом.
  4. Убедитесь, что весь код теперь использует новый интерфейс для выполнения операции X, которая ранее была распределена случайным образом по всему коду (Grep, база кода, добавьте трассировку в новый класс и проверьте страницы, которые должны вызывать ее, и т. д.). , и вы можете контролировать, какая реализация будет использоваться путем изменения одного файла. (реестр объектов, фабричный класс, любой IActivityXClass = Settings.AcitivtyXImplementer ();)
  5. повторные функциональные тестовые примеры, которые подтверждают, что все все еще функционирует со всем действием X throwin в ваш новый класс.
  6. Записывайте, по возможности, единичные тесты вокруг нового класса X-оболочки.
  7. реализовать новый класс с менее безумной логикой спагетти, чем прежняя реализация, которая придерживается того же интерфейса, что и унаследованный класс.
  8. убедитесь, что новый класс передает модульные тесты, которые вы написали для унаследованного класса.
  9. обновите свой код, изменив параметр registry /factorymethod /what, чтобы использовать новый класс вместо старого класса.
  10. убедитесь, что ваши функциональные тесты все еще проходят.

Открытый закрытый принцип и общая бизнес-логика /уровень сохранения

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

  • Как минимум отдельный слой презентацииот уровня бизнеса и настойчивости.
  • реализовать новый ui и улучшенный уровень представления, который использует один и тот же общий уровень работы и сохранения.
  • Убедитесь, что данные, созданные с помощью нового ui, не разбивают старый ui. (вы будете в горячей воде, если пользователи нового инструмента прервут пользователей старого инструмента). Если вы стремитесь к полной обратной совместимости, вы должны сохранять все на одинаковые уровни персистентности. Если вам просто нужна передовая совместимость в новом инструменте, используйте новую базу данных и новые таблицы или таблицы расширений для отслеживания данных, не находящихся в устаревшей системе.
  • Для новых уровней функциональности и уровня персистентности новые таблицы и методы не изменяют существующую устаревшую логику или добавляют столбцы, ограничения для существующих таблиц. например если вам нужно начать отслеживать контакты экстренного контакта работодателей, а некоторые другие поля не изменяют существующую таблицу сотрудников (мы не имеем представления о том, какие предположения содержат устаревшие данные о этой таблице), добавьте таблицу расширений employee_ext id, employee_id, emergency_contact_id и т. д.
  • Медленно переносите пользователей на новую систему. если возможно, ставьте устаревшую систему в режим только для чтения или просто добавьте некоторые предупреждающие пользователи, которые больше не будут доступны после даты X.
  • реализовать любую приветствуемую упущенную функциональность или бизнес-требования в новом ui
  • перелистывать базу пользователей.
  • продолжить очистку бизнес-логики и пользователей уровня упорства другими методами рефакторинга.
ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57
-2

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

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

Но на самом деле это не «переписывание» оригинала в том смысле, что вы пытаетесь достичь четности функции.

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132