Работа с объектами бога

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

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

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

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

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

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

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

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

Ой! Похоже на то место, где я работаю.

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

DotNetRocks недавно провела шоу по работе с устаревшим кодом. Нет волшебной таблетки, которая заставит его работать.

Лучший совет, который я слышал, - начните постепенно оборачивать код тестами.

Я тоже сталкивался с этой ситуацией.

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

Во-вторых, я определяю основной алгоритм (ы) и разлагаю их на части, используя систему нумерации, в которой чередуются числа и буквы (это некрасиво, но хорошо работает для меня). Например, вы могли бы смотреть на часть алгоритма глубиной в 4 «уровня», и нумерация была бы 1.b.3.e или какая-то другая ужасная вещь. Обратите внимание, что когда я говорю «уровни», я не имею в виду непосредственно блоки управления или область действия, но я определил шаги и подэтапы алгоритма.

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

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

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

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

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