Обдумывать чужой код

Question

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

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

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

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

Answer 1

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

Большинство любителей, для которых я взял код, просто как-то развили код, чтобы сделать то, что им нужно, в течение нескольких итераций. Это всегда был гигантский инцестуозный беспорядок в библиотеке A, вызывающей B, перезванивающей в A, вызывающей C, вызывающей B и т. Д. Большую часть времени они использовали потоки, а не критическую секцию.

Я обнаружил, что лучший / единственный способ получить дескриптор кода - начать с точки входа ОС [main ()] и построить собственную диаграмму стека вызовов, показывающую дерево вызовов. Вам не нужно создавать полное дерево с самого начала. Просто проследите разделы, над которыми вы работаете на каждом этапе, и вы получите достаточно хорошее представление о вещах, чтобы иметь возможность работать с ним.

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

РЕДАКТИРОВАТЬ: много говорят о стандартах кодирования ... они просто заставят плохой код выглядеть в соответствии с хорошим кодом (и, как правило, будет труднее обнаружить). Стандарты кодирования не всегда облегчают ведение кода.

Answer 2

Хм, это тяжело, так много времени, чтобы сказать так мало ...

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

2) Подход пуристов заключается в написании нескольких модульных тестов для известной функциональности, затем рефакторинга для улучшения кода и понимания, а затем повторного тестирования. Если что-то сломается, создайте больше юнит-тестов - повторяйте до тех пор, пока вам не надоест / старый / не перейдет в новый проект

3) ReSharper хорошо показывает, где что-то используется, например, что вызывает метод, это статическое, но хорошее начало, и это помогает с рефакторингом.

4) Многие события .net закодированы как общедоступные, и в лучшие времена отладка событий может быть затруднена. Перекодируйте их, чтобы они были частными и используйте свойство с добавлением / удалением. Затем вы можете использовать точку останова, чтобы увидеть, что прослушивает событие.

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

Answer 3

Я делаю это на регулярной основе. И разработали некоторые инструменты и приемы.

• Попробуйте получить общий обзор (диаграмма объекта или другое).
• Документируйте свои выводы.
• Проверьте свои предположения (особенно для неопределенного кода).

Проблема в том, что в большинстве компаний вы оценили результат. Вот почему некоторые программисты быстро пишут плохой код и переходят к другому проекту. Таким образом, вы остаетесь с мусором, и ваш босс сравнивает ваш медленный прогресс с быстрым и грязным парнем. (К счастью, мой нынешний работодатель другой).

Answer 4

Окончательный текст этой ситуации - «Эффективная работа Майкла Фезерса с устаревшим кодексом». Как S. Лотт говорит, что проведите несколько юнит-тестов, чтобы установить поведение кода с задержкой. Как только у вас есть те, вы можете начать рефакторинг. Кажется, на сайте Object Mentor есть пример главы , доступной .

Answer 5

Я обычно использую диаграммы последовательности UML различных ключевых способов использования компонента. Я не знаю каких-либо инструментов, которые могут генерировать их автоматически, но многие инструменты UML, такие как BoUML и EA Sparx, могут создавать классы / операции из исходного кода, что экономит некоторую печать.

Answer 6

Я настоятельно рекомендую BOUML . Это бесплатный инструмент моделирования UML, который:

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

Итак: импортируйте свой код в BOUML и просмотрите его там, или экспортируйте в SVG и просмотрите его в Firefox.

Answer 7

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

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

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

Answer 8

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

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

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

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

Answer 9

• Отпечатки
• Whiteboards
• много бумаги для заметок
• Много Starbucks

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

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

Answer 10

Познакомьтесь с программным обеспечением с точки зрения пользователя. Многое можно узнать о базовой структуре, изучая и взаимодействуя с пользовательским интерфейсом (ами).