Как справиться с плохим кодом

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

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

Теперь мой вопрос Как я могу научиться справляться с плохим кодом? Как я могу научиться понимать огромные кодовые базы, а затем реорганизовывать их части, не нарушая работу, которая уже работала и не превышала предельный срок? Есть ли литература, которую вы можете порекомендовать? У вас есть общие советы для меня?

Ответ 1

Майкл Перс написал хорошую книгу об этой теме.

Эффективно работает с устаревшим кодом.

Еще одна замечательная книга - Мартин Фаулер, Кент Бек и другие:

Рефакторинг: улучшение дизайна существующего кода.

Ответ 2

Общий совет:

if (it is working)
   Do (not touch it);
else
{
   Make (as few modifications as possible)
   Or (it will stop working at all);
}

Это опыт поколений.

Ответ 3

Рефакторинг нуждается в ремне безопасности для комплекта unit test, чтобы удалить его: "Разве я его сломал?" чувство. Покрытие плохого кода в одеяле тестов поможет вам, пока вы стремитесь к хорошему чистому коду.

Pex - это инструмент, который я считаю полезным (если вы в мире .NET) для создания тестов для устаревшего кода.

Устаревший код == код без тестов!

Доброта,

Dan

Ответ 4

Когда мне приходится иметь дело с добавлением функциональности к плохому коду, мой обычный подход:

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

Это дает вам хоть какую-то уверенность в том, что вы не сломали все. Что касается того, как учиться справляться с плохим кодом, я думаю, что это просто опыт.

Ответ 5

Хорошо, если вы собираетесь реорганизовывать большое количество кода в проект, я бы рекомендовал использовать какой-то достойный контроль версий, чтобы вы могли легко и легко отворачиваться. Учитывая это, вероятно, это открытая дверь, но важная имо.

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

Аспирин хорошо работает.

Ответ 6

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

Действительно ли код плохой? Если да, каковы распространенные ошибки? == > возможно сосредоточиться на тех, кто первым
Каков основной поток выполнения в коде? Возможно, вы можете отбросить от него несколько конструкций.
Попробуйте сложить/модулировать код без его изменения. Это приводит к некоторому сокращению взаимозависимостей.
Попробуйте выставить код с помощью тестов. Если база кода запутана без надежды: используйте что-то вроде PowerMock для имитации объектов, которые еще не нуждаются в изменении
У вас есть среда интеграции, в которой вы можете протестировать изменения в производственной среде.
Не уклоняйтесь, чтобы переписать части базы кода. Но старайтесь не реализовывать в нем слишком много нового.
Попробуйте объединиться, обсудите проекты, принципы, решения.

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

Ответ 7

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

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

Ответ 8

Рефакторинг: улучшение дизайна существующего кода

Ответ 9

Это зависит от количества факторов, но самое главное, если у вас есть полномочия на его изменение.

В случае, если вы это сделаете, отредактируйте его. Например, переименуйте классы/функции/переменные. Извлеките и обобщите функциональные возможности. См. Рефакторинг: Улучшение дизайна существующего кода (Библия для предмета). Прежде чем начать, убедитесь, что код находится в правильном управлении версиями (VC) и имеет хороший набор тестовых примеров. VC позволяет вам откатываться назад, а тестовые случаи помогают поймать неожиданные побочные эффекты.

Я предлагаю управление распределенной версией, например Mercurial/Bazaar и Git, потому что это очень рефакторинг, который не точно структурирован как добавление функций.

Если не было тестов (общее), вы должны их создать. Прочтите Эффективно работайте с устаревшим кодом. Особенно о "точке уплотнения" (не о сиамской кошке: p).

Если вы не создаете API-интерфейс оболочки, который является более чистым.

Например:


Old code ====================
const ACT_SHOW = 'show';
const ACT_HIDE = 'hide';
function int DoThing(Object $Obj, Stirng $Action, Object $Param1, Object $Param1) {
     ....;
}
Added code ==================
enum Actions {
    show, hide;
};
class ActionDoer {
    private obj;
    ActionDoer($Object) {
        this.obj = $Object;
    }
    function int act(Actions $Action, $Param1, $Param1) {
        this.act($Action.toString(), $Param1, $Param1) ;
    }
    function int act(String $Action, $Param1, $Param1) {
        DoThing(this.obj, $Action, $Param1, $Param1) ;
    }
    function int show() {
        this.act(Actions.show, null, null);
    }
    function int hide(Color $ToBGColor, long $FadeTime) {
        this.act(Actions.hide, $ToBGColor, $FadeTime);
    }
}

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

Надеюсь, что это поможет.