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

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

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

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

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

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

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

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

Джимми Богард и Рэй Хьюстон сняли интересный экран на тему, очень похожую на эту: http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/06/pablotv-eliminating-static-dependencies-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 находятся в одном месте, основные методы возвращают и принимают DataSets и так далее.

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

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

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

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

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

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

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

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

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