Есть ли момент, когда стоимость рефакторинга перевешивает стоимость переписывания?

Question

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

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

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

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

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

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

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

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

Answer 1

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

Рефакторинг почти наверняка правильный ответ. У меня нет опыта рефакторинга PHP (я делаю C ++ и C #), поэтому я не могу предложить какой-либо конкретный совет. Вы должны приступить к шагам ребенка.

• Во-первых, определите те части кода, которые вас больше всего оскорбляют. Для меня в C ++ это глобальные переменные.
• Во-вторых, сделайте небольшой рефакторинг, чтобы устранить одну проблему за раз. Чтобы не сломать старых клиентов этого кода, вам может потребоваться установить фасад. Либо вы можете поместить новый фасад в старый код, либо вы можете поместить старый фасад в новый код.
• В-третьих, и это самое главное, если вы не действительно уверены, убедитесь, что у вас есть солидный набор модульных тестов для кода, который вы собираетесь реорганизовать.

Но: не бросайте все, чтобы переписать код. Рефакторинг постепенно. Это немного замедлит вас, но вы все равно будете приносить пользу, пока продвигаетесь вперед.

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

Да, на небольшом уровне: предоставьте новую версию функции, убедитесь, что она работает как с новой, так и со старой, удалите старую. Это часто достаточно быстро, чем рефакторинг самой функции. Но на этом уровне это рефакторинг:)

Стратегическая стоимость перезаписи *1003* практически всегда превышает рефакторинг.

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

---

Да. Сценарии, где перезапись дешевле, МОЖЕТ быть построена:

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

---

Тем не менее, опыт показывает, что код плох по какой-то причине, и это не всегда кодеры, и когда вы не идентифицируете и не измените причины, переписывание будет упражнением в повторении истории.

Answer 6

это очень сложное решение ...

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

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

есть три варианта:

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

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