На что следует обратить внимание при рефакторинге проекта для улучшения ремонтопригодности?

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

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

Изменить: мне стало ясно, что мне нужно модульное тестирование. Это не то, что я когда-либо делал, какие хорошие ресурсы для разработчика, плохо знакомого с модульным тестированием (предпочтительно с помощью среды модульного тестирования VS2008)?


refactoring maintainability
person Firoso    schedule 05.11.2009    source источник
comment
Как узнать, что вы ничего не сломаете, без модульных тестов?   -  person Mez    schedule 05.11.2009
comment
Нет, интеграционное тестирование — наш лучший метод сейчас, к сожалению.   -  person Firoso    schedule 05.11.2009
comment
Спасибо всем за отзывы, я считаю, что модульное тестирование будет моим первым зверем, с которым я столкнусь. Может ли кто-нибудь порекомендовать некоторые источники по использованию инструментов тестирования VS2008?   -  person Firoso    schedule 05.11.2009
comment
По большей части тестирование VS может быть выполнено в очень стандартном стиле тестирования xunit. Однако есть некоторые уникальные особенности. Это интересное чтение: msdn.microsoft.com/en -us/library/ms379625(VS.80).aspx   -  person Reed Copsey    schedule 06.11.2009

Ответы (6)


arrow_upward
6
arrow_downward

Пожалуйста, обратите внимание, что в этом проекте не было модульного тестирования, и я на самом деле не ПЛАНИРУЮ добавлять модульные тесты к этому, однако, если это будет общим консенсусом, я приму это во внимание.

Откровенно говоря, если ваша цель — улучшить ремонтопригодность, ничто не заменит модульное тестирование.

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

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

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

person Reed Copsey    schedule 05.11.2009
comment
Хотя часто необходимо провести рефакторинг только для того, чтобы обеспечить надлежащее модульное тестирование. - person Jeff Sternal; 05.11.2009
comment
Ну, для меня они часто идут рука об руку. Я бы сделал как можно меньше рефакторинга, чтобы получить хорошие модульные тесты, затем рефакторинг тестируемой части, а затем перешел бы к следующей области кода и повторил. - person Reed Copsey; 05.11.2009
comment
И еще одно слово для проверяемого — разъединено. Чтобы протестировать модуль изолированно, вы должны отделить его. Таким образом, TDD заставляет вас разделять модули. В самом деле, если вы будете следовать трем правилам [TDD], вы обнаружите, что делаете гораздо больше расцеплений, чем вы, возможно, привыкли. Это заставляет вас создавать лучшие, менее связанные дизайны. Отсюда butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd - person ; 31.07.2013

arrow_upward
5
arrow_downward

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

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

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

2) Сделайте простоту своей целью. Четко ли определена каждая функция/метод/класс? Можете ли вы посмотреть на него и очень хорошо понять, что он делает? Если нет, то это хорошая цель для рефакторинга. Хорошими примерами являются модули, которые делают много вещей (или имеют множество побочных эффектов). Подумайте о том, чтобы разбить их на более мелкие модули логически сгруппированных функций.

3) Имена переменных/классов/функций. Ясны ли они? Они не обязательно должны быть длинными, но они должны четко давать понять вам (или тому, кто поддерживает код), для чего предназначена переменная или что делает функция. Если есть какие-то неясные, подумайте о том, чтобы переименовать их.

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

5) Повышение производительности. У вас может быть или не быть времени для полной алгоритмической перезаписи (лучшее повышение производительности). Тем не менее, это хорошее время, чтобы проверить простые вещи. В качестве примера C++, вы передаете классы как константные ссылки или по значению? Первый гораздо более эффективен, когда вы можете обойтись без него (что составляет 95% времени).

Удачи вам в рефакторинге!

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

person Russell Newquist    schedule 05.11.2009
comment
Чтобы не быть слишком педантичным, но улучшения производительности не являются рефакторингом. (Хотя первые четыре являются хорошими предложениями.) - person Jeff Sternal; 05.11.2009
comment
Технически верно, но это то, что я бы искал, если бы я все равно был в недрах кода. - person Russell Newquist; 05.11.2009
comment
Кроме того, я присоединяюсь ко всем ниже с их рекомендациями по модульным тестам. Я хотел включить комментарий по этому поводу в свой первоначальный ответ. - person Russell Newquist; 05.11.2009

arrow_upward
2
arrow_downward

  • Несмотря на то, что вы сказали, что нет модульных тестов, я все равно собираюсь их подключить. Оборачивайте сложную логику в тесты перед их рефакторингом.
  • Ответ Джруда о запахах кода хорош.
  • Кроме того, изучите S.O.L.I.D. принципы.
person Jeremy Roberts    schedule 05.11.2009

arrow_upward
1
arrow_downward

Я бы посмотрел вики-статью на Code Smells на этом сайте — отличное место для начала!

person Jrud    schedule 05.11.2009
comment
+1 — наряду и часто превосходит wiki.java.net/bin/view/People/ SmellsToRefactorings (ссылка из записи bliki запаха кода Мартина Фаулера martinfowler.com/bliki/CodeSmell.html< /а>). - person Jeff Sternal; 05.11.2009

arrow_upward
1
arrow_downward

Имея проект, хорошо покрытый надежными тестами (как модульные тесты, использующие mocking & c для невероятно быстрой работы, чтобы вы могли запускать их все время, И интеграционные тесты, которые нужно запускать реже, которые фактически взаимодействуют с реальными базами данных, и т. д. и т. д.) является ключом к ремонтопригодности: самая важная вещь, которую вы можете сделать, чтобы сделать проект легко поддерживаемым для любых целей (функций, устранения ошибок, производительности, переноса и т. д. и т. д.) ). Сильный набор тестов дает вам уверенность в правильности любых дальнейших конкретных изменений, которые вы, возможно, захотите попробовать в будущем, плюс, рефакторинг кода, чтобы его можно было хорошо тестировать (модульность, внедрение зависимостей и т. д. и т. д.). ) также становится более гибким и удобным в сопровождении.

Я настоятельно рекомендую Feathers Эффективная работа с устаревшим кодом (оба PDF I и m, и книгу с тем же названием и автором) за подробное и очень практическое руководство о том, как лучше действовать в таких ситуациях.

person Alex Martelli    schedule 05.11.2009

arrow_upward
0
arrow_downward

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

person Paul Graphov    schedule 05.11.2009