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

Ответ 1

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

Это отличная книга.

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

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

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

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

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

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

Ответ 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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

Остальное - это действительно арахис. Это основные проблемы с устаревшей кодовой базой, они действительно съедают тонны времени.

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

Самое большое, что я сделал с устаревшим кодом, с которым я должен работать, - это создать реальный API. Это API COBOL 1970 года, в котором я построил объектную модель .NET, так что весь небезопасный код находится в одном месте, все переводы между собственными типами данных API и типами данных .NET находятся в одном месте, первичные методы возвращают и принимают DataSets и т.д.

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

Ответ 9

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

Ответ 10

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

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

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

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

Ответ 11

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

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

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