Лучший способ познакомиться с наследуемой кодовой базой

Ответ 1

Карандаш и блокнот (не отвлекайтесь, пытаясь создать незатребованное решение)

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

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

• Помните, что проблемы из вашей последней рабочей среды не обязательно действительны или прочны в вашей новой среде. Остерегайтесь предвзятых понятий.

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

Мои шаги:

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

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

3.) Продолжайте повторять 1.) и 2.) итеративно, пока вы не дойдете до точки, в которой вы можете изменить код или добавить код/​​найти ошибку в exisitng code/исправить ошибку!

-AD

Ответ 5

Я не знаю, что это "лучший способ", но кое-что, что я сделал на недавней работе, - это написал кодовый паук/парсер (на Ruby), который прошел и построил дерево вызовов (и обратное дерево вызовов), которое Я мог бы позже запросить. Это было немного нетривиально, потому что у нас был PHP, который называл Perl, который называл функции/процедуры SQL. Любые другие инструменты для сканирования кода могут помочь аналогичным образом (например, javadoc, rdoc, perldoc, Doxygen и т.д.).

Чтение любых юнит-тестов или спецификаций может быть весьма поучительным.

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

Конечно, не стоит недооценивать силу просто задавать вопросы товарищу по команде (или вашему боссу!). Вначале я спрашивал так часто, как это необходимо: "у нас есть функция/скрипт/foo, который делает X?"

Ответ 6

Перейдите по основным библиотекам и прочитайте объявления функций. Если это C/С++, это означает только заголовки. Документируйте все, что вы не понимаете.

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

Ответ 7

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

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

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

Ответ 8

Одна вещь, которую могут использовать пользователи vi и emacs, это использовать теги. Теги содержатся в файле (обычно называемом TAGS). Вы генерируете один или несколько файлов тегов командой (etags для emacs vtags для vi). Затем мы редактируем исходный код, и вы видите запутанную функцию или переменную, которую вы загружаете в файл тэгов, и он приведет вас к тому, где объявлена ​​функция (не совсем хорошо). Я на самом деле написал несколько макросов, которые позволяют вам перемещаться по источнику, используя Alt-курсор, вроде как popd и pushd во многих вариантах UNIX.

BubbaT

Ответ 9

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

Ответ 10

Я неоднократно занимался этой проблемой. Я закончил тем, что написал сообщение в блоге об общем процессе для изучения новой кодовой базы: http://www.larsavery.com/blog/a-process-for-learning-a-new-codebase/

Ответ 11

Другая процедура...

После прочтения Энди Ханта "Прагматическое мышление и обучение - Рефакторинг вашей Wetware" (который не затрагивает это напрямую), я взял несколько советов, которые можно было бы упомянуть:

Наблюдать за поведением:

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

Подтвердить структуру папки:

Опять же, это свет. Просто посмотрите, что принадлежит где, и надеемся, что структура достаточно семантична - вы всегда можете получить информацию о верхнем уровне отсюда.

Анализ вызовов-стеков, сверху вниз:

Пройдите и перейдите на бумагу или какой-либо другой носитель, но не пытайтесь набирать его - это задействует различные части вашего мозга (выстройте его из Legos, если вам нужно) - функциональные вызовы, объекты и переменные, наиболее близкие к первому уровню. Посмотрите на константы и модули, убедитесь, что вы не погружаетесь в мелкозернистые объекты, если можете вам помочь.

MindMap It!:

Возможно, самый важный шаг. Создайте очень приблизительную схему вашего текущего понимания кода. Удостоверьтесь, что вы быстро пробегаете мозг. Это позволяет равномерно распространять разные части вашего мозга (в основном R-Mode), чтобы иметь право голоса на карте.

• Создавайте облака, ящики и т.д. Где бы вы ни думали, они должны идти на бумаге. Не стесняйтесь обозначать ящики с синтаксическими символами (например, "F'-Function", "f'-замыкание", "C'-Constant", "V'-Global Var", "v'-low-level var" и т.д.). Используйте стрелки: Входящий массив для аргументов, Исходящий для возвратов или что более естественно для вас.
• Начните рисовать соединения для обозначения отношений. Его нормально, если он выглядит грязным - это первый черновик.
• Сделайте быструю грубую ревизию. Его слишком сложно читать, делать еще одну быструю организацию, но не делать больше одной ревизии.

Откройте отладчик:

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

MindMap Again!:

Теперь у вас должно быть достойное представление о большинстве функций верхнего уровня.

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

Притвориться не его кодом:

Если вы можете поместить его в механические термины, сделайте это. Самая важная часть этого - придумать метафору поведения приложения и/или более мелких частей кода. Подумайте о смешных вещах, серьезно. Если это было животное, монстр, звезда, робот. Что бы это было? Если бы это было в "Звездном пути", для чего они его использовали. Подумайте о многом, чтобы взвесить его.

Синтез по анализу:

Теперь вы хотите увидеть не "что", а "как". Любые части низкого уровня, которые через вас для петли можно вынуть и положить в стерильную среду (вы управляете ее входами). Какие выходные вы получаете. Является ли система более сложной, чем вы изначально думали? Simpler? Нужны ли улучшения?

Внести что-нибудь, чувак!:

Напишите тест, исправьте ошибку, прокомментируйте ее, отрисуйте. У вас должно быть достаточно возможностей для внесения незначительных взносов и ОТКАЗЫВАТЬ ОК:)! Обратите внимание на любые изменения, внесенные вами в коммит, чат, электронную почту. Если вы сделали что-то подлые, вы, ребята, можете поймать его до того, как он начнет производство - если что-то не так, это отличный способ заставить товарища по команде разобраться в этом. Обычно слушая разговор с товарищем по команде, он многое прояснит, что привело к конфликту с MindMaps.

Вкратце, самое важное, что нужно сделать, это использовать сверху вниз способ получения как можно большего числа различных частей вашего мозга. Возможно, это поможет даже закрыть ваш ноутбук и, если возможно, присмотреться к вашему месту. Исследования показали, что соблюдение крайнего срока создает "Похмелье давления" в течение ~ 2,5 дней после крайнего срока, поэтому крайние сроки часто лучше всего иметь в пятницу. Итак, ПРОВЕРЯЙТЕСЬ, НЕТ НИКАКОГО ВРЕМЕНИ, И СЕЙЧАС ПРЕДОСТАВЛЯТЬ СЕБЯ С ОКРУЖАЮЩЕЙ СРЕДОЙ, КОТОРУЮ БЕЗОПАСНО ОТКАЗЫВАТЬ. Большая часть этого может быть довольно быстро опрокинута, пока вы не приступите к деталям. Убедитесь, что вы не обходите понимание тем высокого уровня.

Надеюсь, это тоже поможет вам:)

Ответ 12

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

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

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

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

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

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

Ответ 13

создайте документацию для каждой вещи, которую вы вычислили из кодовой базы. узнайте, как это работает путем эксприментации - меняя несколько строк здесь и там, и посмотрите, что произойдет. использовать geany, поскольку это ускоряет поиск часто используемых переменных и функций в программе и добавляет их к автозаполнению. узнайте, можете ли вы связаться с разработчиками orignal базы кода, через facebook или через googling для них. узнайте исходную цель кода и посмотрите, подходит ли код для этой цели или должен быть переписан с нуля, в соответствии с намеченной целью.

узнать, какие рамки использовали для кода, какие редакторы использовали для создания кода.

Самый простой способ определить, как работает код, - фактически воспроизвести, как определенная часть была бы сделана вами, и перепроверять код, если есть такая часть.

это обратное проектирование - что-то выяснить, просто попытавшись реконструировать решение.

у большинства программистов есть опыт в кодировании, и есть определенные шаблоны, которые вы могли бы найти, если они присутствуют в коде.

существуют два типа кода, объектно-ориентированные и структурно ориентированные.

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

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

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

Я не сделал ни одного из приведенных выше, поскольку я - веб-разработчик, относительно легко понять, начиная с index.php, на остальные страницы, как что-то работает.

Гудлак.

Ответ 14

Все действительно хорошие ответы здесь. Просто хотел добавить еще несколько вещей:

Можно соединить архитектурное понимание с флэш-картами, и повторное посещение может укрепить понимание. Я нахожу такие вопросы, как "Какую часть кода выполняет функциональность X?", Где X может быть полезной функциональностью в вашей кодовой базе.

Мне также нравится открывать буфер в emacs и начинать переписывать некоторые части базы кода, с которыми я хочу ознакомиться, добавить свои собственные комментарии и т.д.