Что вы можете сделать с устаревшей кодовой базой, которая окажет наибольшее влияние на улучшение качества?

Question

Когда вы работаете в устаревшей кодовой базе, что со временем окажет наибольшее влияние на качество кодовой базы?

• Удалить неиспользуемый код
• Удалить дублирующийся код
• Добавление модульных тестов для улучшения покрытия тестами при низком охвате
• Создание согласованного форматирования для файлов
• Обновление стороннего программного обеспечения
• Сокращение предупреждений, генерируемых инструментами статического анализа (например, Findbugs)

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

Answer 1

• Прочитайте книгу Майкла Пера "Эффективная работа с устаревшим кодом"

Это БОЛЬШАЯ книга.

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

• Во-первых, прекратите создавать новый устаревший код [1]

[1]: устаревший код = код без юнит-тестов и, следовательно, неизвестный

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

ПРИМЕЧАНИЕ. Я не говорю, что вам нужно все остановить и потратить недели на написание тестов для всего. Наоборот, просто проверяйте области, которые вам нужно проверить, и отрабатывайте оттуда.

Джимми Богард и Рэй Хьюстон сняли интересный ролик на тему, очень похожую на эту: http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/06/pablotv-eliminating-static-dependencies-screencast.aspx

Answer 2

Я работаю с устаревшим приложением 1M LOC, написанным и модифицированным примерно 50 программистами.

* Remove unused code

Почти бесполезно ... просто игнорируй это. Вы не получите большой возврат инвестиций (ROI) от этого.

* Remove duplicated code

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

* Add unit tests to improve test coverage where coverage is low

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

* Create consistent formatting across files

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

* Update 3rd party software

Делайте это только в том случае, если есть новая действительно приятная функция или ваша версия не поддерживается новой операционной системой.

* Reduce warnings generated by static analysis tools

Это может стоить того. Иногда предупреждение может скрыть потенциальную ошибку.

Answer 3

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

На эту тему есть хорошая книга, написанная автором CPPUnit, Эффективная работа с устаревшим кодом .

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

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

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

Хорошая документация. Для человека, который должен поддерживать и расширять устаревший код, это проблема номер один. Сложно, если не просто опасно, менять код, который вы не понимаете. Даже если вам посчастливилось получить документированный код, насколько вы уверены в правильности документации? Что это охватывает все скрытые знания оригинального автора? Что это говорит обо всех «хитростях» и крайних случаях?

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

Answer 7

Я бы сказал, что это во многом зависит от того, что вы хотите сделать с унаследованным кодом ...

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

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

Если вы планируете использовать версию 2.0, добавьте модульные тесты и очистите код, который вы предоставите

Answer 8

Поздно к вечеринке, но, возможно, стоит сделать следующее, если функция / метод часто используется или на него ссылаются:

• Локальные переменные часто имеют плохие имена в унаследованном коде (часто из-за расширения их области действия при изменении метода и отсутствия обновления для отражения этого). Переименование их в соответствии с их реальным назначением может помочь уточнить устаревший код.
• Даже простое изложение метода может творить чудеса - например, помещая все пункты if в одну строку.
• Там уже могут быть устаревшие / запутанные комментарии к коду. Удалите их, если они не нужны, или исправьте их, если это абсолютно необходимо. (Конечно, я не защищаю удаление полезных комментариев, только те, которые являются помехой.)

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

Answer 9

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

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

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

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

Answer 10

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