Просто прочитайте вопрос о Больших Переписываниях, и я вспомнил вопрос, на который я так хотел ответить.
Мне передали ужасный проект, написанный на старой Java, с использованием Struts 1.0, таблиц с несовместимыми отношениями или вообще без отношений, и даже таблиц без первичных ключей или полей, которые должны быть первичными ключами, но вовсе не уникальны. Почему-то большая часть приложения «просто работает». Большинство страниц используются повторно (скопированный код) и жестко закодированы. Каждый, кто когда-либо работал над проектом, проклинал его в той или иной форме.
Теперь я долго думал, что предложить высшему руководству полностью переписать это ужасное приложение. Я медленно пытаюсь использовать личное время, но я действительно чувствую, что это заслуживает некоторых выделенных ресурсов, чтобы это произошло. Прочитав статьи на большие переписывает, у меня есть вторые мысли. И это нехорошо, когда я хочу убедить своих начальников поддержать мою переписку. (Я работаю в довольно небольшой компании, поэтому предложение может быть одобрено)
TL; DR Когда большой переписать ответ и какие аргументы вы можете использовать, чтобы поддержать его?
источник
Ответы:
Извините, это будет долго, но оно основано на личном опыте как архитектора, так и разработчика в нескольких проектах переписывания.
Следующие условия должны заставить вас задуматься о переписывании. Я расскажу о том, как решить, что делать после этого.
Эти вещи довольно очевидны. Когда принимать решение о полном переписывании по сравнению с инкрементным перестраиванием, является более субъективным и, следовательно, более политически заряженным. С уверенностью могу сказать, что категорически утверждать, что это никогда не является хорошей идеей, неправильно.
Если систему можно постепенно модернизировать, и у вас есть полная поддержка спонсорства проекта для этого, тогда вам следует это сделать. Здесь проблема, однако. Многие системы не могут быть постепенно перепроектированы. Вот некоторые из причин, с которыми я столкнулся, которые препятствуют этому (как технические, так и политические).
Имейте в виду, что общая стоимость повторного изменения значения всегда выше, чем полное переписывание, но влияние на организацию, как правило, меньше. На мой взгляд, если вы можете оправдать переписывание, и у вас есть разработчики суперзвезд, то сделайте это.
Делайте это только в том случае, если вы уверены, что есть политическая воля, чтобы довести дело до конца. Это означает как вступительный, так и конечный пользователь. Без этого у вас ничего не получится. Я предполагаю, что именно поэтому Джоэл говорит, что это плохая идея. Бай-ин для руководителей и конечных пользователей выглядит многогранным единорогом для многих архитекторов. Вы должны агрессивно продавать его и проводить кампанию за его продолжение до тех пор, пока оно не будет завершено. Это сложно, и вы говорите о том, чтобы поставить свою репутацию на что-то, что некоторые не захотят видеть успешным.
Некоторые стратегии успеха:
источник
Я участвовал в двух больших переписываниях. Сначала был небольшой проект. Второй был основным продуктом софтверной компании.
Есть несколько подводных камней:
Переписывание редко является реальным ответом. Вы можете реорганизовать большую часть кода, не теряя ничего и не рискуя.
Переписать может быть ответом, если:
Но я настоятельно рекомендую медленный подход с использованием рефакторинга. Это менее рискованно, и вы делаете своих клиентов счастливыми.
источник
Пришло время для переписывания, когда:
Стоимость переписывания приложения + обслуживания переписанного приложения меньше стоимости обслуживания текущей системы с течением времени.
Некоторые факторы, которые делают поддержание текущего более дорогим:
//Here be dragons.
комментарий во всем вашем коде.источник
Если вам требуется фундаментальное изменение архитектуры проекта, возможно , пришло время начать все заново.
Несмотря на это, в вашем новом проекте потенциально могут быть большие объемы кода, которые все еще стоит использовать повторно.
Обратите внимание на справедливое предупреждение. В текущем проекте будут проверены и уточнены его бизнес-правила с бесчисленным количеством человеко-часов фактического использования, чего нельзя сказать о проекте, начатом с нуля.
Я сомневаюсь, что временные рамки или интуитивное чувство являются подходящей мерой такой решительной меры. У вас должны быть четкие , оправданные и хорошо понятные причины для участия в этом процессе.
источник
Хотя я согласен с ответом Крамия и мнением Джоэла, бывают случаи, когда уместно сделать переписывание. В долгоживущих приложениях (я говорю о 10-20 лет или более), обслуживание становится все дороже со временем. Это связано с тем, что код становится все более и более спагеттизным, поскольку исходная архитектура жертвуется ради быстрых исправлений. Также разработчики старых технологий становятся все более редкими и дорогими. Наконец, аппаратное обеспечение начинает стареть, и становится все труднее находить новое оборудование, операционные системы, платформы и т. Д. Для запуска старого приложения поверх. Кроме того, бизнес развивается, и, скорее всего, старая система не будет отвечать бизнес-потребностям организации, как это могла бы сделать новая система.
Таким образом, вы должны взвесить все текущие расходы на техническое обслуживание, а также потенциальные преимущества новой системы для бизнеса и стоимость переписывания этой вещи с нуля. Будьте очень пессимистичны в своих оценках стоимости переписывания. Это почти всегда стоит больше и занимает больше времени, чем вы думаете.
источник
Стоп! Переписывание почти никогда не является ответом. Чаще всего рефакторинг - лучшая ставка.
Конечно, бывают случаи, когда перезапись оправдана:
Чтобы понять, почему я рекомендую рефакторинг, а не переписывание, рассмотрим, что входит в переписывание. Ты должен:
Понять нюансы того, что делает существующее приложение. Обычно это не тривиально, если принять во внимание все тонкие бизнес-правила, которые он инкапсулирует, среду (как человеческую, так и техническую), в которой он работает, а также преимущества и недостатки текущего решения. Чаще всего единственное место, где эта информация существует (если где-либо), находится в исходном коде существующего приложения. К сожалению, одна из основных причин переписывания заключается в том, что существующий код трудно понять и поддерживать.
Воспроизведите эту функцию (или обновленную версию) в новом испытанном и надежном приложении. Существующий код не может быть понят разработчиками, но обычно хорошо понимается его пользователями. Это может не соответствовать их текущим потребностям бизнеса, но они могут по крайней мере сказать вам, что приложение делает при различных обстоятельствах.
Большие преимущества рефакторинга таковы:
Помните также, что если вы сделаете переписывание, вы гарантированно добавите много новых ошибок и добавите новую базу кода.
источник
Может помочь эта графика, она зависит от качества кода и бизнес-ценности приложения:
Диаграмма претендует на роль руководства, когда реинжиниринг устаревшего программного обеспечения оправдан, а когда нет. Например, если программное обеспечение имеет высокую ценность для бизнеса, а качество кода низкое, то реорганизация оправдана.
источник
Я думаю, что я нахожусь в единственной ситуации в моей карьере, где большая переписка является ответом:
Слияние компаний, огромное совпадение в функциональности систем. Многие, многие системы были объединены и удалены, а другие еще находятся в процессе.
Я унаследовал систему от другой компании, которая все еще живет. У него огромная кодовая база, которая поддерживала несколько отделов, очень похожих на наши, но с совершенно другим дизайном и фреймворками. Остался только один бизнес-сектор, использующий его, который зарабатывает достаточно денег, чтобы поддерживать эту вещь в состоянии зомби. Все старые экспертизы ушли, документации нет. Бремя поддержки велико, с отказами каждую неделю. Он не был объединен с системами наших компаний, потому что наша компания никогда не поддерживала этот конкретный сектор бизнеса, поэтому у нас нет функциональности или опыта.
Похоже, что это единственный случай, когда необходимо переписать. Похоже, мне придется разобраться с этим чудовищем, вытащить кусочки функциональности, предназначенные для этого бизнеса, и переписать кусочки, которые необходимо добавить в наши существующие системы. Как только это будет сделано, наши существующие системы смогут поддерживать этот новый сектор, и этого зверя можно избавить от страданий. Иначе я потеряю здравомыслие.
источник
Я работал в небольшой софтверной компании, у которой было несколько приложений DOS, которые были модернизированы для работы с Y2K, переписаны как 16-битное приложение Windows, а затем полностью переписаны как 32-битное приложение с одной дополнительной «маленькой» функцией (в конечном счете, используемой только один клиент), что повлияло на всю структуру.
Перенос 16-битного кода на 32 мог бы быть выполнен за месяц одним человеком, но NOOOOOOOOO, нам пришлось переписать его, чтобы Soooooooooo намного лучше. Эта вещь может быть адаптирована для других отраслей, будет иметь полные спецификации и псевдо-код, прежде чем они даже начали. Спецификации были созданы, но это заняло так много времени, что даже не было времени, чтобы написать настоящий код. Он был выпущен поздно, с большим количеством ошибок, чем «началось» с 16-битной версией (это было на v.3.0 и, наконец, до такой степени, что мы почти сделали это за неделю, и никто не сообщил о новой ошибке).
Можно подумать, что переписывание одного и того же приложения 3-4 раза приведет к некоторым улучшениям, но я просто не думаю, что интерфейс GUI можно оправдать так сильно.
Это была моя первая работа в сфере ИТ в качестве руководителя службы технической поддержки. Я должен написать книгу о том, как не разрабатывать программное обеспечение для распространения. Очевидно, мы допустили много ошибок, но тот факт, что мы продолжали переписывать приложения, усугублял несовместимость.
источник
У меня был случай, очень похожий на ваш, только код даже не использовал Struts. Вместо этого я нацелился на области, которые были особенно дрянными и вызывали много проблем. Этот целевой подход постепенно улучшал нас.
В течение 2-х лет мы работали над рефакторингом кусков и деталей наряду с работой по улучшению. Мы всегда работали над «Укреплением» в плане проекта. Сосредоточив внимание на конкретных областях, которые не работали хорошо, мы получили максимальную отдачу. Материал, который работал, мы оставили в покое. Также важно то, что эта работа была сделана в ходе обычной разработки и была выпущена. Проблема с большим переписыванием: вы уходите на год или больше, а потом, когда вы возвращаетесь, все вещи все равно меняются, и некоторые неприятные ошибки сглаживаются, и вы теряете ROI.
Мы никогда не переписывали все это. Мы прекратили использовать эту платформу для новой работы и создали новую свежую платформу для большого нового проекта. Это было одобрено, и мы доставили отличный продукт в разумные сроки.
источник
Итак, вот я сижу за своим столом, я начал переписывать код для этого абсолютного беспорядка одного большого файла aspx, базы данных за ним и заменять интерфейс MS Access на MsSQL.
Эта программа asp изобилует такими вещами, как
include(close.aspx)
который внутри имеет одну строку кода, которая закрывает последнее открытое соединение с базой данных.Если нам когда-нибудь понадобится внести небольшие изменения, это все равно что сыграть пять одновременных игр кал-тох в режиме кошмара.
Я был нанят для репликации функциональности и создания продукта, который можно настраивать и продавать другим в отрасли. Проблема в том, что эта штука была написана за последние 10 лет, чтобы удовлетворить все потребности бизнеса (ну, я бы сказал, пять или шесть сигма из них в любом случае).
Если бы мы не хотели продавать продукт, им, вероятно, не потребовалось бы переписывать текст, поскольку он делает большую часть того, что они хотят - возможно, не элегантно, но не было разумно тратить деньги на создание хорошего кода «сделать то же самое».
источник
У Джоэла Спольски есть отличная статья на эту тему: То, чего никогда не следует делать, часть I
Из названия, которое вы можете сказать, это своего рода односторонность (он говорит о том, почему вы никогда не должны бросать код) IMO, в этом много правды, я недавно видел видео на канале 9 на 25-й годовщине Excel, где некоторые разработчики говорили, как даже сегодня, если вы заглянете в исходный код, вы проверите ревизию и в конечном итоге вернетесь к коду, который использовался в Excel и был написан 20 лет назад.
Вы не можете быть на 100% уверены (когда даже Netscape делает ошибки (из статьи Джоэлса)), я чувствовал, что статья Джоэла была посланна Богом, потому что я могу быть пессимистичен и люблю выбрасывать код, думая, что всегда могу написать лучше время, но я понял только сейчас, это просто стоит дорого .
Чтобы дать конкретный ответ, я бы просто сказал, что вам необходимо провести тщательный анализ затрат и стоимости .
Мой реальный мир: приложение silverlight, которое я сейчас разрабатываю в версии 0.6, имеет множество асинхронных вызовов, которые делают код настолько запутанным. С тех пор как я обнаружил Reactive Extensions на этой неделе, я действительно хочу переписать большую часть кода, но что теперь я скажу своему клиенту? Программа работает отлично (с некоторыми утечками памяти), но им все равно? Я не могу сказать им, что у меня еще 2-3 недели, потому что я хочу что-то сделать заново. Я, однако, собираюсь разветвить код и переписать / поиграть с ним в свободное время.
Просто мои 2 цента хорошо !?
источник
Существующее решение не масштабируется.
Я смотрю на тебя, MS Access.
источник
По словам Джоэла, большие изменения - это единственная худшая стратегическая ошибка, которую может совершить компания:
Вещи, которые вы никогда не должны делать, часть I
источник
Никогда, всегда рефакторинг - правда в том, что если код был написан вами - вы не сможете добиться большего успеха.
Если вы не хотите менять технологию, в коде отсутствует какая-либо структура (я видел это очень давно на каком-то PHP-сайте, автор просто скопировал / вставил spahgetti вместо include / class / function) или вы взяли что-то у другого человека, который очень плохо написано.
Все должно быть оформлено как черный ящик. Модульный, простой API, что внутри ... это менее важно :) Если у вас есть спагетти, вы можете закрыть его внутри черного ящика, чтобы он не загрязнил хороший код.
источник
Я думаю, что основной причиной, которая оправдывает переписывание, являются изменения платформы. Например, если у вас есть приложение с графическим интерфейсом Windows для настольного компьютера, и владелец компании решает, что следующей версией будет веб-приложение. Хотя не всегда, по моему опыту, в большинстве случаев это потребует переписывания, если только разработчики оригинала не написали очень модульный и многократно используемый код (вряд ли это произойдет).
источник
Есть классическая шутка о том, что «если бы я собирался в XI, я бы не начал отсюда».
Однажды я устроился на работу, где основной мотивацией работодателя было привлечение талантов на борт для запуска давно назревшего переписывания критически важного для бизнеса приложения. Вопрос, который я не смог задать, заключался в том, почему вы оказались в этой ситуации в первую очередь? Это должен был быть красный флаг, была ли причина
слишком большое давление, чтобы добавить функциональность для поддержания и постепенного рефакторинга зверя,
слишком мало способностей в отделе,
слишком мало взносов от клиентов или руководства для дополнительной работы,
или что-то еще, и это вызывает гноение, пока проблема не достигнет невыносимого уровня.
Поэтому я согласен с Джоэлом в том, что массовое переписывание, вероятно, очень плохая идея - если у вас нет убедительных доказательств того, что все основные причины, по которым основное переписывание кажется столь необходимым, были устранены , вы, по всей вероятности, собираюсь повторить проблему в свое время.
источник
Это ответ, когда переписывание позволяет организации следовать стратегии, которая дает конкурентное преимущество или позволяет ей лучше обслуживать своих клиентов таким образом, который не может вместить текущая архитектура.
Вместо этого переписывание часто случается, чтобы облегчить проблемы управления:
Большинство из этих опасений не осуществятся, и, если они это сделают, с ними можно справиться. Этот последний, однако, является худшим. Это по сути: у нас нет причины.
Да, как автомобиль, система начнет показывать признаки износа. Это может быть облегчено обычным обслуживанием. Вы знаете, что они говорят о том, как небольшое профилактическое обслуживание проходит долгий путь. В качестве инвестиций рутинное обслуживание (т.е. рефакторинг и стандартизация) почти всегда будет стоить меньше затрат, чем переписывание.
Тем не менее, мы должны ожидать, что переписывание в конечном итоге будет необходимо. Установите даты и ориентировочно запланируйте это, но поскольку дата приближается к задержке в пользу реализации других стратегических целей, пока у вас не будет веской причины, как ...
В последние годы мы потеряли возможность выигрывать большие счета, потому что не могли своевременно или дорого удовлетворить их потребности. Наша система будет переписана с использованием расширяемой архитектуры, которая позволяет подключать настройки (а не жестко, как мы это делаем в настоящее время). Это значительно сократит время и стоимость размещения клиентов с особыми потребностями. Мы выиграем больше аккаунтов и будем лучше удовлетворять потребности наших текущих клиентов.
источник
При переходе на совершенно новую технологию необходимо обеспечить желаемую функциональность.
«Абсолютно новый»: если вы планируете переписать, но использовать ту же платформу, то рефакторинг и разумная реструктуризация почти наверняка являются лучшим решением. Термин «платформа», как он используется здесь, несколько расплывчатый - он может включать в себя язык и, возможно, операционную систему (на ум приходит расширение от Linux до Windows или наоборот), но, вероятно, не каркас (например, замена Struts на Spring).
«Требуется обеспечить желаемую функциональность»: примерно в 2000 году я инициировал проект по переписыванию основного компонента сервера в Java с C ++, чтобы включить готовые потоки, кэш объектов и транзакции, управляемые клиентом. В то время существовало несколько библиотек многопоточности для C ++, которые мы должны были бы поддерживать, и для обеспечения многопоточности большая часть кода нашей базы данных требовала бы почти полного переписывания. Что касается контролируемых клиентом транзакций ... не случится со старой архитектурой.
Даже тогда я не уверен, что сделал бы переписывание, за исключением того, что у меня было детальное знание поведения текущей системы, и это был относительно чистый код, который не развил очень много бородавок за 11 лет своей жизни.
источник
Чтобы определить момент, с которого вы должны начать все сначала, вам нужно разобраться, когда значение продолжения в вашем текущем проекте не соответствует значению начала заново.
Причина, по которой это так сложно, состоит в том, что вы делаете точную оценку скорости разработки команды в новом проекте, пока вы фактически не запустите его. Тем не менее, если, используя ОЧЕНЬ консервативную оценку скорости вашего развития для нового проекта, проект, по оценкам, даст достойную отдачу от инвестиций, то у вас есть экономическое обоснование для начала заново.
источник
С моей метрикой вы должны выполнить два условия, чтобы оправдать переписывание:
Даже тогда вы хотите ограничить объем вашей переписать. Например, у нас было какое-то устаревшее программное обеспечение в компании, написанное на C ++ с мышлением программиста на C, который не знал о модульности. Конечным результатом был код спегетти в форме конечного автомата, который охватывал несколько классов и библиотек DLL. У нас было новое требование, которое сильно отличалось от предположений, встроенных в код, и собиралось стать частью запатентованной добавочной стоимости компании для ее клиентов.
Проведя время с кодом, реализующим другие функции, у меня было действительно хорошее представление о том, сколько времени потребуется, чтобы выяснить, какой из нескольких операторов switch мне нужно изменить, и т. Д. Я предложил переписать часть кода, которая была огромный конечный автомат - это займет у меня меньше времени, чем расширение существующего кода. Мне удалось объединить в одну DLL, которая раньше составляла три, и предоставить гораздо более объектно-ориентированную структуру, которая облегчила бы создание критически новых функциональных возможностей наряду с упрощением добавления новых функциональных возможностей.
Было три других приложения, использующих библиотеки, которые нуждались в переписывании, поэтому я не хотел полностью переписывать эти программы. Область действия была ограничена библиотекой и тем, что было необходимо для привязки библиотеки к существующему программному обеспечению. Мои оценки не были далеко, и работа окупилась. Вскоре после редизайна мне было поручено добавить новую функцию. То, что заняло бы у меня неделю со старой структурой, заняло у меня целый день с новой структурой.
источник
ОП не указывает на масштабы проекта, но основная подсказка, которую я принял, была «написана на старом [language / dialect] с использованием старых [libs]», которые для меня являются основными драйверами переписывания. Фактически, большинство проектов, в которых я принимал участие в какой-либо значительной долговечности рынка, в конечном итоге осознают, что размещение обновлений для компиляторов / интерпретаторов / операционных систем является важной задачей для поддержки базы кода.
Короче говоря, я планировал бы переписывать поэтапно, отдавая приоритет обновлению в библиотеках. Может случиться так, что по пути вы можете проникнуть в другие оптимизации, но тот факт, что вы планируете отложить некоторые изменения на более поздний этап, может быть отличным способом остаться в графике и избежать «застрять».
источник
Ну, я могу представить себе гипотетические сценарии, в которых я мог бы просто выбросить существующую кодовую базу (гипотетические ситуации, когда выпуклые шары имеют нулевой вес и объем, когда никому нет дела, если мы теряем недели или месяцы производительности, когда мы пытаемся добавить упущенные возможности и ошибки исправления в системе, и там, где система настолько тривиальна и ненавистна для организации, что я могу заменить все это и целую армию серверов на notepad ++ и нетбук за десять минут и повысить производительность и моральный дух каждого.)
Для почти любого реального сценария, хотя я бы просто рекомендовал рефакторинг на месте. ^ _ ^. Как правило, слишком много скрытых непредвиденных расходов приходится переписывать, когда появляются недокументированные юридические и бизнес-требования, и в последнюю минуту начинаются взломы.
== Рефакторинг на месте для большего блага и прочее ==
Рефакторинг унаследованного кода обычным старым инкрементным подходом,
Ветвление по абстракции
Открытый Закрытый Принцип и Общая Бизнес-логика / Уровень Постоянства
В какой-то степени вам, возможно, удастся отделить вашу презентацию, бизнес-уровень и уровень персистентности и написать новое приложение, полностью обратно совместимое с унаследованным решением, или, как минимум, все еще обрабатывать данные, введенные унаследованным решением. Я бы, вероятно, не рекомендовал бы такой подход, но иногда это разумный компромисс времени / графика / ресурсов / требуемой новой функциональности.
источник
Я бы сказал, что есть третья категория в пространстве Refactor vs Rewrite ... И это обновляет ваши языковые версии, компиляторы и библиотеки ... Иногда просто принятие современных методов кодирования приносит большую пользу.
Возьмем, например, C #, код v7 пишет намного чище, безопаснее и лаконичнее, чем v2. Такие вещи, как Elvis и оператор объединения нулей, помогают на тонну.
Переключение компиляторов также может вдохнуть новую жизнь в старый код. Так что, возможно, появятся новые библиотеки, с которыми будет легче работать и реализовывать ... Сетевое взаимодействие - отличный пример целого ряда трудностей с реализацией.
Также - встроенные системы Linux ... Подумайте об установке новых инструментов - переключитесь на git из svn или добавить Vi в вашу систему и т. д.
Это не всегда должен быть рефакторинг против переписывания. Возможно, ваша архитектура нуждается в улучшении, но это работает ... возможно, вам просто нужно подумать о том, как написан ваш код и т. Д.
источник
Я не думаю, что когда-либо видел людей, переписывающих устаревшее приложение.
Происходит то, что люди пишут совершенно новые приложения с другой архитектурой, технологиями и т. Д., Которые имеют некоторые общие черты с предыдущим поколением. И оно называется app 2.0, но на самом деле у него очень мало общего с оригиналом.
Но на самом деле это не «переписывание» оригинала в том смысле, что вы пытаетесь достичь паритета функций.
источник