Рефакторинг рабочего проекта

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

Это даст вам одну точку зрения на переписывание с нуля:

http: / /www.joelonsoftware.com/articles/fog0000000069.html

Сначала создайте набор автоматических модульных тестов и убедитесь, что у вас высокий уровень покрытия кода (70% или больше). Во время рефакторинга вы будете запускать эти тесты очень часто, чтобы убедить себя (и руководство), что вы ничего не сломали.

Нет модульных тестов = нет рефакторинга.

---

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

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

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

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

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

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

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

И каждый день вы будете говорить себе: «Это было бы намного быстрее, если бы я просто переписал все». НЕ ДЕЙСТВУЙТЕ НА ЭТОЕ ЧУВСТВО. (См. Уже упомянутую статью Джоэла).

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

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

И каждый день вы будете говорить себе: «Это было бы намного быстрее, если бы я просто переписал все». НЕ ДЕЙСТВУЙТЕ НА ЭТОЕ ЧУВСТВО. (См. Уже упомянутую статью Джоэла).

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

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

И каждый день вы будете говорить себе: «Это было бы намного быстрее, если бы я просто переписал все». НЕ ДЕЙСТВУЙТЕ НА ЭТОЕ ЧУВСТВО. (См. Уже упомянутую статью Джоэла).

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

И каждый день вы будете говорить себе: «Это было бы намного быстрее, если бы я просто переписал все». НЕ ДЕЙСТВУЙТЕ НА ЭТОЕ ЧУВСТВО. (См. Уже упомянутую статью Джоэла).

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

И каждый день вы будете говорить себе: «Это было бы намного быстрее, если бы я просто переписал все». НЕ ДЕЙСТВУЙТЕ НА ЭТОЕ ЧУВСТВО. (См. Уже упомянутую статью Джоэла).

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

За свою карьеру я переписал три важных приложения (Значимые: 50 тысяч LOC или больше, уровень данных, логический уровень, требования интеграции). Каждая система требовала от меня сказать To Hell With This в какой-то момент хорошей практики. Вы знаете, чему я научился? В определенный момент это может быть действительно очень безопасно. Безусловно, вам нужно подумать о том, что значит отбросить осторожность, но гораздо важнее, чтобы вы отправили его, чем следовать чужому представлению о хорошей практике.

Позвольте мне проиллюстрировать на примере то, о чем я говорю:

Сегодня я работаю над системой, которая была написана более шести лет и первоначально была преобразована в язык .NET из приложения, которое было времени, возможно, десятилетней давности, и он был написан с помощью клиента DOS, который содержал всю логику. Исходный код и большинство последующих обновлений и преобразований выполнялись неопытными программистами. Это механизм управления документами для всех целей и задач, и нигде в коде нет единой абстракции для «документа».

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

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

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

Если вы знаете систему, если вы обратите внимание, Если вы протестируете свой код и ОБРАТИТЕ ВНИМАНИЕ, часто нет ничего плохого в том, чтобы вносить большие изменения небезопасным способом.

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

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

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

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

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

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

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