Какие вопросы я должен задать при попытке определить, должна ли система быть перестроена?
пользовательская формула:
=IF((($A$1="=E2>=TODAY()-21")*(E2>=TODAY()-21))+
(($A$1="=AND(E2>DATE(2019,3,23),E2DATE(2019,3,23))*(E2 
6 ответов
В целом я нашел, что перезапись кода имеет тенденцию быть проблемой (это является дорогим, трудоемким, и включает фазу исследования, которая заставляет первую систему выглядеть лучше).
Тем не менее вот несколько вопросов спросить:
Базовый рефакторинг был бы достаточен? Вы будете знать от оценки системы, идут ли главные вопросы глубже, чем код. Если проблемы находятся в кодовой базе (а не сама технология), я предпочитаю осуществлять рефакторинг.
До какой степени существующая система является тестируемой? Тестируемость имеет большое значение для расширения срока службы любого модуля системы, потому что тестируемый код обычно предоставляет себя с большей готовностью расширению и пригодности для обслуживания. Это касается № 1 также.
Наконец, был бы, значение, обеспеченное от переписывания, выравнивает по ширине усилие. Это - бизнес-вопрос, конечно, но тот, что разработчик может и должен помочь сделать.
В большинстве случаев я встретился, ответ был нет.
Я рекомендовал бы считать Вещи, которые Вы Никогда не должны Делать, Первая часть. Он приводит веские аргументы в пользу того, что не перестроил.
Денежная кавычка:
Важно помнить, что, когда Вы запускаете с нуля, нет абсолютно никакой причины полагать, что Вы собираетесь сделать лучшее задание, чем Вы сделали в первый раз. В первую очередь, у Вас, вероятно, даже нет той же команды программистов, которая работала над версией один, таким образом, у Вас на самом деле нет "большего опыта". Вы просто собираетесь сделать большинство старых ошибок снова и представить некоторые новые проблемы, которые не были в исходной версии.
Возможно, необходимо спросить себя, если Вы знаете, что система достаточно хорошо решает проблемы, не переписывая его. Если Вы не делаете, могло бы быть безопасно сказать, что Вы не знаете, что система достаточно хорошо перестраивает его с нуля.
Наконец Вы хотите достигнуть чего-то каждый раз, когда Вы переписываете систему от царапины. Необходимо ли спросить себя, чего Вы хотите достигнуть? Сделайте Вы хотите:
- Снизьте риск системной сборки со старыми технологиями
- Уменьшите затраты: слишком дорогой для поддержания
- ?
Вы могли сделать сбалансированный анализ для наблюдения, когда новая система начинает выплачивать. По-моему, необходимо смочь уменьшить перезапись системы до затрат и смочь видеть, что новый стоит меньше, чем старое.
в следующем порядке:
- это делает задание правильно?
- это быстро?
- действительно ли легко поддержать?
- действительно ли легко расшириться?
Сколько времени Вы будете не мочь поставить? Сколько времени Тем, какой фактор Вы недооценили предыдущие проекты? Сколько времени можно выкроить в худшем случае?
Насколько рабочая сила в настоящее время входит в обслуживание существующей системы? Вы имеете эту рабочую силу в наличии в дополнение к людям, разрабатывающим новую систему?
Как можно удостовериться, что Вы не воссоздаете ту же систему с теми же проблемами? Предотвращение очевидных отказов архитектуры обычно недостаточно.
Вы сможете конкурировать/переживать, если у Вас не будет ресурсов для улучшения существующей системы?
Даже если "Осуществляют рефакторинг, и Восстановление" означает, на длительном периоде, заменяя большую часть существующей системы, это означает помещать все ресурсы в ОДНУ систему, а не два.
Я предлагаю, чтобы Вам был нужен контекст для обсуждения, и лучший, с которым я знаком, найден в книге "Рефакторинга" Martin Fowler. Мне вопрос действительно, "Это приложение refactorable?"
Первая определенная инструкция была бы, "Она записана с помощью хороших принципов разработки OO?" В противном случае обычно необходимо или поместить его на жизнеобеспечение и/или запуститься. Если это будет, то книга обеспечит много справки; и по моему опыту существует серьезное основание для надежды.