Что вы делаете, когда вам поручено работать с кодом, который ужасный и устаревший до такой степени, что это почти непостижимо?
Например: код аппаратного интерфейса, смешанный с логикой, и код пользовательского интерфейса, ВСЕ в одних и тех же функциях?
Мы видим плохой код все время, но что вы на самом деле делаете?
Зависит от нескольких факторов для меня:
В идеале, я бы реорганизовал весь плохой код, который мне нужно было поддерживать, но на самом деле есть только так много часов в день.
Как это часто бывает, "Он зависит".
Я, как правило, задаю себе некоторые из следующих вопросов:
И так далее...
Но, полагая, что у меня есть способность сделать это, рефакторинг является предпочтительным, поскольку первоначальная стоимость исправления кода теперь, скорее всего, сэкономит мне много времени и сил позже на время обслуживания и разработки.
Есть и другие преимущества, в том числе тот факт, что чем чище и ухожен ваш код, тем более вероятно, что другие разработчики будут поддерживать его таким образом. Прагматический программист называет это Сломанная теория окон.
У разработчиков есть интуиция предположить, что код всегда уродлив из-за других, уступающих разработчиков. Иногда код является уродливым, потому что проблемное пространство уродливое. Все это уродство - это не просто уродство - это иногда институциональная память. Каждая строка уродливого кода, вероятно, представляет собой исправление ошибки. Так что подумайте очень внимательно, прежде чем вы полностью разобьете.
В принципе, я бы сказал, что вы не должны касаться такого кода, если вам это не нужно. Если есть реальная ошибка, которую вы можете решить, рефакторинг является разумным, если вы можете быть уверены, что поддерживаете такое же количество функций. Но рефакторинг для рефакторинга (например, "сделать код OO" ) - это то, что я обычно классифицировал как классическую ошибку новичка.
В книге Эффективно работает с устаревшим кодом обсуждаются варианты, которые вы можете сделать. В общем правило не менять код до тех пор, пока вам не понадобится (исправить ошибку или добавить функцию). В книге описывается, как вносить изменения, если вы не можете добавить тестирование и как добавить тестирование к сложному коду (что позволяет более существенные изменения).
Вы пытаетесь реорганизовать его в строгом смысле слова, где вы не меняете поведение.
Первая цель, как правило, разбивает гигантские методы.
Отправьте его на www.worsethanfailure.com!!!
Учитывая силу некоторых прилагательных, которые вы используете, т.е. зверские, устаревшие и непонятные, я бы это уложил!
Если он находится в таком состоянии, как пример, который вы даете, он, вероятно, тоже не получил никакого тестового кода. Рефакторинг упоминается во многих других ответах, но иногда это не подходит. Я всегда нахожу, что при рефакторинге вам обычно нужен четкий путь, через который старый код может постепенно превращаться в новый в ряде четко определенных шагов.
Когда старый код настолько удален от того, как вы хотите, чтобы он выглядел, например, крайние случаи, которые вы, кажется, предлагаете, вы, вероятно, могли бы перепроектировать, переписать и протестировать новый код за меньшее время, чем потребовалось бы для рефакторинга.
Откажитесь от него и начните с использования скомпилированного устаревшего приложения в качестве документа бизнес-требований. И тратить время на анализ с пользователями, чтобы увидеть, что они хотят изменить.
Если никаких изменений не требуется, я не трогаю его.
Если это вообще возможно, я сначала пишу автоматические модульные тесты, особенно ориентированные на области, которые нуждаются в модификации.
Если автоматические модульные тесты невозможны, я делаю все возможное, чтобы документировать ручные модульные тесты.
Я просто использую тесты для документирования текущего поведения на этом этапе.
Если возможно, я всегда сохраняю версию кода и исполняемую среду, которая запускает вещи "оригинальным" способом (до того, как я ее коснулся), поэтому я всегда могу добавить новые тесты "поведенческой документации" и лучше обнаруживать регрессии, которые, возможно, вызвали позже.
Как только я начинаю менять вещи, я хочу быть очень осторожным, чтобы не вводить регрессии. Я делаю это, постоянно переигрывая (и добавляя новые тесты) к тестам, которые я написал, прежде чем начал писать код.
Когда это возможно, я оставляю ошибки как есть, если нет необходимости в бизнесе для их исправления. Эти ошибки могут быть "функциями" для некоторых пользователей и могут иметь непонятные побочные эффекты, которые не будут ясны до тех пор, пока код не будет переведен в производство.
Что касается рефакторинга, я делаю это как можно более агрессивно, но только в коде, который мне нужно изменить в любом случае. Я могу реорганизовать более агрессивно в своей личной копии кода, который никогда не будет проверен, просто чтобы улучшить читаемость кода для меня лично. Часто бывает трудно правильно протестировать изменения, которые сделаны только по соображениям удобочитаемости, поэтому по соображениям безопасности я обычно не проверяю эти изменения в их/развертывании, если я не могу уверенно проверить, что изменения кода полностью безопасны (это действительно плохо для вводить ошибки при внесении изменений, которые не нужны ни для чего, кроме чтения).
Действительно, это проблема управления рисками. Действовать с осторожностью. Пользователям все равно, ужасен ли код, им просто нужно, чтобы он улучшался, не ухудшившись. Ваша потребность в красивом коде не важна в этом сценарии, пройдите мимо него.
Как и любой другой код, вы оставляете его немного лучше, когда вы его оставляете, чем когда вы его вводили. Вы никогда не переписываете весь код. По какой-то причине это требует какой-то работы, тогда вы начинаете проект (маленький или большой) для него.
Я предполагаю, что здесь мы говорим о значительном количестве кода.
Не каждый день замечательный день на работе, который вы знаете:)
Первый вопрос: работает?
Если ответ "да", это будет огромным препятствием, чтобы просто сорвать его и начать все заново. В этом коде могут быть тысячи человеко-часов, которые касаются крайних случаев и неприятных ошибок. Хуже того, в системе могут быть другие модули, которые зависят от текущего неправильного (но известного и возможно документированного) поведения. Не связывайтесь с ним, если он не сломан.
Если вы увлечены его очисткой, начните с написания тестовых примеров для текущего поведения. Когда вы сталкиваетесь с экземпляром, где поведение отличается от спецификации, вы должны решить, следует ли принимать поведение как "правильное" или идти с тем, что спецификация говорит, что он должен делать.
Только после того, как вы написали тестовые примеры, которые все проходят, вы должны начать рефакторинг. Тесты скажут вам, что ваши усилия что-то нарушают.
Я бы поговорил с моим менеджером и описал код. Большинство менеджеров не хотели бы, чтобы программа проводилась вместе, объединяя проволочную и клейкую ленту как таковые. Если код действительно такой плохой, наверняка будут какие-то ошибки бизнес-логики, hardcoding и т.д., Которые в конечном итоге просто разрушат производительность.
Я столкнулся с каким-то довольно плохим кодом раньше (имена одной буквы, без комментариев, все переполнено на одну строку и т.д.), и как только я упомянул/показал это моему менеджеру, они почти всегда говорили: "Идите вперед, -write it", потому что вы не только принимаете удар за чтение и изменение кода, но и будущим сотрудникам придется пройти через ту же боль. Лучше, чтобы вы занимали более длительный период времени, чтобы переписать его, вместо того, чтобы каждый человек, который затрагивает код в будущем, должен пройти и понять и расшифровать его в первую очередь.
Есть старая поговорка. Если это не сломано, не исправляйте это. Если вам нужно его поддерживать, то перепроектируйте его и запишите его, чтобы в следующий раз, когда вы столкнетесь с ним, вы узнаете, что он делает.
Вы не знаете ситуации, в которой находился разработчик, когда он написал код. Он или она, возможно, были под хрустком времени, когда он был написан (управление было по всему разработчику и т.д.).
Есть также ситуации, когда он или она написали код в спецификации, спецификация затем несколько раз менялась, разработчику приходилось исправлять код, так как переписать не может быть из-за ограничений по времени. Это происходит все время.
Если код влияет на производительность надежности приложения и является модульным, тогда вы можете пересчитать или переписать. Документируйте ситуацию, чтобы помочь будущим программистам в понимании.
Также многие программисты рассматривают обратное проектирование другого кода разработчиков под ними. они предпочли бы переписать без учета последствий этого.
Если вы никогда этого не делали, попробуйте его когда-нибудь, это сделает вас лучшим разработчиком.
Спасибо
Joe
Убейте его огнем.
Зависит от вашего временного интервала и насколько важно для вас этот код. Если вам нужно "просто заставить его работать", тогда сделайте это и перепишите модуль, когда позволяет время.
Если это важная или неотъемлемая часть того, что вы делаете, рефакторинг рефакторинга рефакторинга.
Затем найдите парня/девушку, которые его написали, и пришлите им грубую открытку!
Худший нарушитель (по моему опыту) действительно AWFUL-кода - это легкость, с которой люди могут делать вырезание и вставку в эти дни. Вырезать и вставить следует использовать редко. Если вы считаете, что это правильное решение, как правило, лучше отступить и немного обобщить проблему.
В моей компании мы всегда Рефлятор безжалостно. поэтому мы до сих пор сталкиваемся с ужасным кодом, но МЕНЬШЕ и Меньше и меньше...
Мы пишем много внутреннего кода, и компания работает около 100 лет одной и той же семьей. Руководство обычно говорит нам, что мы должны поддерживать базу кода (эволюционировать) еще на 50 лет или около того. В этой настройке, имеющей код, который вы не осмеливаетесь касаться, считается большим риском для долгосрочного выживания компании, а затем перспективой простоев, потому что некоторые недооцененные коды сломались из-за рефакторинга.
В любое время вы видите код, который "почти непонятен", ПРОИЗОЙДЕН С ПРЕДОСТЕРЕЖЕНИЕМ. Вы должны предположить, что любой серьезный повторный факторинг приведет к появлению новых ошибок, которые вам нужно будет найти и исправить.
Кроме того, я видел этот сценарий много раз (даже стал жертвой его сам один или два раза): Программист наследует устаревший код, решает, что код является древним и неподъемным, и решает его реорганизовать, заканчивает удаление ключевых "исправлений" или "бизнес-правила", тонко исправленные за последние годы, заканчиваются тем, что тратят много времени на отслеживание и повторное введение подобного кода, когда пользователи жалуются на "проблема, исправленная много лет назад, происходит снова".
Рефакторинг (и отладка) почти всегда занимает больше времени, чем ожидалось, и его никогда не следует рассматривать как "халяву", которая сопровождается любой задачей, которую вы должны выполнять.
"Если он не сломался, не" исправить "его" все еще имеет много правды ".
Я запускаю детектор копий-пасты и findbugs по всему унаследованному коду, который приходит мне на ум.
Затем я планирую свой первоначальный рефакторинг:
К этому моменту код соответствует базовому минимуму для ремонтопригодности. Он может быть легко построен и основные ошибки могут быть найдены с помощью автоматизированного теста.
Я часто добавляю такой код:
log.debug("is foo null? " + (foo == null));
log.debug("is discount < raw price ? " + (foo.getDiscount() < foo.getRawPrice()));
Некоторые из этого кода будут восстановлены для модульных тестов, когда я смогу реорганизовать его.
Я работал там, где мы отправляем этот код.
Я пытаюсь понять это, внести необходимые изменения и двигаться дальше.
Конечно, осознание этого обычно связано с некоторыми изменениями; по крайней мере, я перемещаюсь по пробелам и выравниваю соответствующие фигурные скобки в том же столбце, что и так:
if(condition){
doSomething(); }
// becomes...
if(condition)
{
doSomething();
}
Я также часто буду менять имена переменных.
И очень часто "необходимые изменения" требуют рефакторинга.:)
Получите представление о том, что они делают, и о крайнем сроке. Больший срок, как правило, восстанавливает большую часть кода с нуля, так как я считаю, что это очень полезный опыт, чтобы не только расшифровать ужасный код и сделать его разборчивым и документированным, но где-то в вашем мозге эти нейроны нажимаются, чтобы избежать подобных ошибок в будущее.