Что Вы делаете со зверским кодом?

Я работал в местах, где мы отправляем такой код.

Я пытаюсь разобраться в этом, внести необходимые изменения и двигаться дальше.

Конечно, понимание этого обычно включает в себя некоторые изменения; по крайней мере, я перемещаю пробелы и выстраиваю соответствующие фигурные скобки в одном столбце следующим образом:

if(condition){
doSomething(); }

// becomes...

if(condition)
{
    doSomething();
}

Я также часто меняю имена переменных.

И очень часто «необходимые изменения» требуют рефакторинга. :)

Я моя компания, мы всегда Рефакторинг безжалостно . так что мы все еще сталкиваемся с ужасным кодом, но МЕНЬШЕ, Меньше и меньше ...

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

Каждый раз, когда вы видите "почти непонятный" код, ДЕЙСТВУЙТЕ ОСТОРОЖНО. Вы должны предположить, что любой серьезный рефакторинг приведет к появлению новых ошибок, которые вам нужно будет найти и исправить.

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

Рефакторинг (и отладка ) почти всегда занимает больше времени, чем ожидалось, и никогда не должен рассматриваться как «халява»

Наихудшим нарушителем (по моему опыту) действительно УЖАСНОГО кода является легкость, с которой в наши дни люди могут вырезать и вставлять. Cut & paste следует использовать редко. Если вы считаете, что это правильное решение, лучше сделать шаг назад и немного обобщить проблему.

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

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

Затем найдите парня / девушку, которые это написали, и отправьте им грубую открытку!

Убейте его огнем.

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

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

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

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

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

Спасибо

Джо

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

Я предполагаю, что мы говорим здесь о значительном количестве кода.

Не каждый день хорош день на работе вы знаете :)

Я бы поговорил со своим менеджером и описал код. Большинство менеджеров не хотели бы, чтобы программа скреплялась связкой проволоки и изолентой как таковой. Если код действительно настолько плох, наверняка там будут какие-то ошибки бизнес-логики, жесткое кодирование и т. Д., Которые в конечном итоге просто снизят производительность.

Я уже сталкивался с довольно плохим кодом раньше (однобуквенные имена переменных, нет комментарии, все втиснуто в одну строку и т. д.), и как только я упоминал / показывал это своему менеджеру, они почти всегда говорили: «Давай, переписывай это», потому что ты не только принимаешь удар за чтение и изменение кода, но и будущим коллегам придется пережить ту же боль.

Если никаких модификаций не требуется, я этого не трогаю.

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

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

Я просто использую тесты для документирования «текущего» поведения на данном этапе.

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

Как только я начинаю что-то менять, я хочу быть очень осторожным, чтобы не ввести регрессии. Я делаю это, постоянно повторяя (и / или добавляя новые тесты) тесты, которые я написал до того, как начал писать код.

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

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

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

Разместите на www.worsethanfailure.com !!!

Developers have an instinct to assume that code is always ugly because of other, inferior developers. Sometimes, code is ugly because the problem space is ugly. All that ugliness isn't just ugliness - it is sometimes institutional memory. Each line of ugly in your code probably represents a bug fix. So think very carefully before you rip it all out.

Basically, I would say that you shouldn't touch code like this unless you actually have to. If there's a real bug that you can solve, refactoring is reasonable, if you can be sure you're maintaining the same amount of functionality. But refactoring for the sake of refactoring (eg, "make the code OO") is what I would generally classify as a classic newbie mistake.

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

Как это часто бывает, «Зависит от обстоятельств».

Я часто задаю себе следующие вопросы:

• Существуют ли модульные тесты для существующего кода?
• Является ли рефакторинг кода приемлемым риском для моего проекта?
• Может ли автор уточнить какие-либо вопросы, которые могут возникнуть по поводу кода?
• Считает ли мой работодатель время, потраченное на изменение существующего, работающего кода, приемлемым использованием моего времени?

И так далее ...

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

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

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

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

Первый вопрос, который нужно задать: работает ли ?

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

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

Только после того, как вы написали тестовые примеры, которые все пройти, если вы начнете рефакторинг.

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

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

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

Затем я планирую свой первоначальный рефакторинг:

1. удаляю неиспользуемый код, неиспользуемые переменные и неиспользуемые методы
2. рефакторинг дублированного кода
3. настройка одноэтапной сборки
4. построение базового функционального теста

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

Я часто добавляю такой код:

log.debug("is foo null? " + (foo == null));

log.debug("is discount < raw price ? " + (foo.getDiscount() < foo.getRawPrice()));

Часть этого кода будет восстановлена ​​для модульных тестов, когда я смогу провести рефакторинг.

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

Учитывая силу некоторых прилагательных, которые вы используете, например, ужасный , устаревший и непонятный , я бы убрал его!

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

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

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