Пакеты C / C++ для понимания кода для рефакторинга

Question

Я собираюсь начать работать над проектом, который включает в себя рефакторинг и изменение существующего кода, который находится на c & C++. Код раздутый и в огромном объеме. Конечно, так как код должен быть изменен, понимание кода должно быть разработано и в очень короткий промежуток времени, так как у нас есть довольно сжатые сроки графика проекта. Может ли кто-нибудь предложить какие-либо инструменты с открытым исходным кодом, которые помогут в достижении вышеизложенного. Короче говоря, я ищу инструмент, который может:

1. Обратные инженерные инструменты, которые помогут понять дизайн.
2. Инструменты генератора последовательностей, которые помогут рисовать последовательности во время выполнения (скорее всего, мы сможем запустить код, но не на начальных этапах, по крайней мере) или посредством проверки кода.
3. Хорошие инструменты просмотра кода для изучения существующей базы кода.
4. Подходит инструмент, который может автоматически рефакторинг кода с минимальными усилиями.

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

[РЕДАКТИРОВАТЬ] Придумал список инструментов, чтобы помочь в выше. Вот список:

1. Графвиз и доксиген
   Генерация диаграмм классов UML из существующей кодовой базы

2. UMLStudio
   Создание объектной модели для вашего унаследованного кода является лучшим подходом к ее анализу, пониманию и поддержанию. UMLStudio может автоматически преобразовывать код C++, Java, CORBA IDL, PHP 5 и Ada 95 в нотацию OOA&D быстрее, чем любой другой инструмент CASE.

3. CodeDrawer для C++
   CodeDrawer преобразует исходный код в визуальные диаграммы. Класс, структура и любые элементы исходного кода могут быть показаны диаграммами. Он также показывает логику функции и метода. CodeDrawer помогает понять исходный код вашего проекта

4. Imagix
   Обратный инжиниринг и визуализация исходного кода приводят к улучшению понимания программы. Скорости: изучение незнакомого изменения кода Анализ влияния Интеграция программного обеспечения с открытым исходным кодом Повторное использование программного обеспечения

5. AgileJ AgileJ StructureViews - это подключаемый модуль для Eclipse Java IDE, который генерирует настраиваемые диаграммы классов UML в промышленном масштабе и идеально подходит для гибкой разработки или исследования любой существующей кодовой базы Java.

6. MaintainJ Если вы можете запустить кодовую базу, то MaintainJ генерирует последовательности UML и диаграммы классов во время выполнения, когда вы запускаете конкретный вариант использования.

7. Java Reverse Engineering Tool Генерирует диаграммы классов и отношения между классами из исходного кода Java.

8. Source Insight Отличное программное обеспечение для просмотра исходного кода

Еще одно, благодаря Стиву Таунсенду
Klocwork

Answer 1

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

Тогда у вас возникнет проблема управления: если вы уже знаете, что у вас мало времени, чтобы ПОНИМАТЬ много кода, вы обречены. Чтобы понять этот код, вам нужно будет запустить его и пройти через него, и это займет время. Инструменты просто дадут вам большую карту вещей, но не покажут вам реальный путь.

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

Ты живешь в стране чудес.

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

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

Answer 2

Первый вопрос, который вы должны задать: "Как сделать так, чтобы любые изменения, которые мы вносим, ​​не сломали систему?". Тем не менее, ваш вопрос не упоминает тесты вообще. Это красный флаг для меня.

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

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

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

Вы могли бы посмотреть на что-то вроде этого - не использовал себя, хотя: Klokwork Architect

Answer 3

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

По модулю этих глюков наш DMS Software Reengineering Toolkit может быть настроен на проведение рефакторинга кода C и C++. DMS имеет промышленные синтаксические анализаторы для C и C++ и уникальным образом может захватывать большинство использований препроцессора как часть внутренних структур кода (обычно люди, пытающиеся проанализировать C / C++, расширяют директивы препроцессора, а это не вариант для рефакторинга).

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

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

Answer 4

1. Если у вас есть источник, технически это не реверс-инжиниринг. Вы можете использовать очень хороший Doxygen для генерации документации (включая диаграммы - установите GraphViz тоже!): Ссылка
2. Понятия не имею, не уверен, что он существует.
3. Ваш веб-браузер вместе с Doxygen, если вы включите просмотр исходного кода. Visual Studio, с правой кнопкой мыши для перехода к определениям и отладчиком для пошагового выполнения кода и получения понимания его работы (используйте команду Step Out и злоупотребляйте ею).
4. Существуют инструменты для проведения рефакторинга, но очень трудно добиться минимальных усилий и "автоматического рефакторинга", я не думаю, что вы найдете инструменты для этого.

Answer 5

Я просто подумал добавить примечание, что CTAGS/ECTAGS очень полезны при изучении / рефакторинге неизвестной кодовой базы, особенно при использовании такого инструмента, как Emacs / CEDET.

Answer 6

5 agilej ( http://www.agilej.com/) AgileJ StructureViews - это плагин для Eclipse Java IDE, который генерирует настраиваемые диаграммы классов UML в промышленном масштабе и идеально подходит для гибкой разработки или исследования любой существующей кодовой базы Java.

AgileJ относится к вашим пунктам 1 (обратный инжиниринг, чтобы помочь понять дизайн) и 3 (Хорошие инструменты просмотра кода для изучения существующей базы кода). Раздутый код, который был быстро сложен вместе, обычно проявляется в виде:

• Один или два больших класса, которые действуют как свалка для каждого бита функциональности в последнюю минуту (анти-шаблон blob)
• Вырезать и вставить код, в котором весь класс был скопирован и настроен для новой цели, а не выделять общие части для базового класса
• Отсутствие ОО, о чем свидетельствуют многие классы только с методами get и set
• Зависимости связаны между собой, все зависит от всего остального на протяжении всего проекта, и в архитектуре нет расслоения

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