Ресурсы для обучения, как лучше читать код

Question

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

Моя реакция на необходимость читать много кода - ну, ну, ну, переписать его. Но мне нужно быстро освоиться и построить поверх существующей системы.

Есть ли у других людей методы, которым они научились поглощать кодовую базу? На данный момент я просто читаю код. Я пытался генерировать UML-диаграммы с использованием UModel. Они такие большие, что не будут печатать чисто, и когда я увеличиваю изображение, я действительно теряю перспективу видеть все отношения.

Как другие люди справились с этой проблемой?

Answer 1

Ух ты - я буквально только что закончил слушать подкаст о чтении кода !!!

http://www.pluralsight -training.net / сообщества / блоги / pluralcast / Архив / 2010/03/01 / pluralcast-10-чтение-кода с-алан-stevens.aspx? Utm_source = FeedBurner & utm_medium = подача & utm_campaign = Подача% 3A + pluralcast +% 28Pluralcast + на + Pluralsight% 29

Я бы порекомендовал послушать это. Было сделано одно интересное замечание, что я нашел радикальным и, возможно, вы могли бы попробовать (я знаю, я собираюсь!). Загрузите всю базу исходного кода. Начните редактирование и рефакторинг кода, затем ... выбросьте эту версию !!! Я думаю, что с учетом всех требований, предъявляемых нами к срокам, выполнение этого даже большинству разработчиков не придет.

Я нахожусь с вами в своей работе, и я обнаружил, что для меня сработало следующее: - Напишите контрольные примеры на существующий код. Чтобы написать тестовый пример, вы должны уметь понимать базу cde. - Если это возможно, посмотрите на ошибки \ проблемы, которые были задокументированы в течение жизненного цикла продукта, и посмотрите, как они были решены. - Попробуйте реорганизовать часть кода - вы, вероятно, сломаете его, но это нормально, вы можете выбросить его и начать заново. Разложив код на более мелкие задачи, вы поймете, что лучше

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

Да, и если вы можете, пожалуйста, получите копию «Эффективной работы с устаревшим кодом» Майкла С. Фезерса - я думаю, вы найдете ее неоценимой в вашей ситуации.

Удачи!

Answer 2

Эта статья содержит руководство

• Визуализация: визуальное представление дизайна приложения.

• Нарушения дизайна: понимание здоровья объекта модель.

• Нарушения стиля: понимание состояния кода в настоящее время в.

• Business Logic Review: возможность тестирования существующего источника.

• Обзор производительности: где узкие места в исходном коде?

• Документация: есть ли в коде адекватная документация для людей чтобы понять, над чем они работают?

Answer 3

Я бы порекомендовал еще один подкаст и ресурсы: Эпизод SE-Radion по программной археологии

Answer 4

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

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

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