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

Question

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

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

Answer 1

Я бы порекомендовал вам прочитать То, что вы никогда не должны делать, часть I . Он дает веские основания не перестраивать.

Цитата денег:

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

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

Answer 2

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

Тем не менее, вот несколько вопросов, которые нужно задать:

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

2. В какой степени тестируется текущая система? Тестируемость имеет большое значение для продления срока службы любого системного модуля, поскольку тестируемый код, как правило, легче поддается расширению и удобству обслуживания. Это относится и к # 1.

3. Наконец, будет ли значение, предоставленное при переписывании, оправдать усилия. Конечно, это бизнес-вопрос, но он может и должен помочь разработчику.

В большинстве случаев, с которыми я сталкивался, ответ был нет.

Answer 3

Я полагаю, что вам нужен контекст для обсуждения, и лучший из моих знакомых можно найти в книге Мартина Фаулера «Рефакторинг». Для меня вопрос на самом деле: «Является ли это приложение рефактабельным?»

Первым конкретным руководящим принципом было бы «Написано ли оно с использованием хороших принципов проектирования ОО?» Если нет, обычно вам нужно либо поставить его на жизнеобеспечение, и / или начать все сначала. Если это так, то книга окажет большую помощь; и по моему опыту, есть все основания для надежды.

Answer 4

1. Как долго вы не сможете доставить? Сколько времени По какому фактору вы недооценили предыдущие проекты? Сколько времени вы можете позволить себе в худшем случае?

2. Сколько рабочей силы в настоящее время идет на поддержание существующих систем? Есть ли у вас рабочая сила в дополнение для людей, разрабатывающих новую систему?

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

4. Сможете ли вы конкурировать / выжить, если у вас нет ресурсов для улучшения существующей системы?

---

Даже если «Refactor and Repair» означает, что в долгосрочной перспективе замена большей части существующей системы, это означает, что все ресурсы в ОДНОЙ системе, а не две.

Answer 5

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

• Снижение риска сборки системы с использованием старых технологий
• Снижение затрат: слишком дорого поддерживать

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

Answer 6

в следующем порядке:

• это делает работу правильно?
• это быстро?
• это легко поддерживать?
• это легко расширить?