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

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

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

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

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

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

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

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

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

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

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

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

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

включать такие вещи, как:

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

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

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

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

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

Рефакторинг низко висящего плода

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

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

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

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