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

https://stackoverflow.com/questions/146936

02-07-2019
|

Вопрос

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

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

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

Решение

Прочтите книгу Майкла Физера. «Эффективная работа с устаревшим кодом»

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

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

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

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

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

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

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

Другие советы

Я работаю с устаревшим приложением 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow