Что делать с чрезмерно сложным унаследованным кодом

Ответ 1

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

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

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

Иди со своими кишками. Если это плохо и беспорядочно, когда вы кодируете, потому что код уродливый и противный. Просто начните менять его по частям, скоро код "будет вашим", вы будете знать, что делает код в действии, вы делаете его своей территорией:)

Приветствия!

Ответ 2

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

Ответ 3

Я слышал подкаст на Hanselminutes на эту тему только на днях беседует с Michael Feathers, у которого есть книга по этому поводу: Эффективно работает с устаревшим кодом. Я рекомендую прочитать. В прошлом я сам разбирался с большим количеством плохого кода устаревшего кода, и обычно думаю, что вы должны регулярно реорганизовывать/переписывать плохие детали, быть осторожными, чтобы вы не вызывали слишком много поломки, и быть стратегическими относительно того, что нужно реорганизовать/переписать, Я также рекомендую прочитать это от Джоэла: Вещи, которые вы не должны делать, часть I

Ответ 4

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

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

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

Ответ 5

Самое важное эмпирическое правило: если оно не сломано, не исправляйте его (даже если оно уродливо).

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

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

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

Кроме того, я считаю, что переписывание и замена (по частям) обычно более продуктивны, чем рефакторинг.

Ответ 6

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

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

Преимущества включают такие вещи, как:

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

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

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

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

Ответ 7

Очевидно, нет правильного ответа на ваш вопрос. В некоторых случаях вы рефакторинг. В других случаях вы начинаете с нуля.

Ответ 8

Реорганизовать низко висящие фрукты

Ответ 9

Красота находится в глазах смотрящего.

Архитектура? Вы один из тех астронавтов архитектуры?

И, кстати, ваш код тоже засасывает. Да, это действительно так.

Ответ 10

Делайте все, что можете, но всегда помните: это их код, а не ваш.