Лучший способ ознакомиться с унаследованной кодовой базой
Stacker Никто не спрашивал о самой шокирующей вещи, которую новые программисты находят, когда они выходят на поле.
Очень высоко в списке - влияние наследования кодовой базы, с которой нужно быстро познакомиться. Это может быть шоком, когда вы вдруг обнаружите, что обязаны поддерживать N строк кода, которые были сведены вместе для того, кто знает, как долго, и не хватает времени, чтобы начать вносить свой вклад.
Как вы эффективно поглощаете все эти новые данные? Что облегчает этот переход? Является ли единственное реальное решение, которое уже внесло свой вклад в достаточное количество проектов с открытым исходным кодом, чтобы шок прошел?
Это также относится к опытным программистам. Какие методы вы используете, чтобы облегчить переход на новую кодовую базу?
Я добавил к этому тег Community-Building, потому что я также хотел бы услышать некоторые военные истории об этих переходах. Не стесняйтесь поделиться тем, как вы справились с особенно напряженной кривой обучения.
14 ответов
Карандаш и блокнот (не отвлекайтесь, пытаясь создать незапрошенное решение)
Делайте заметки на ходу и занимайте каждый понедельник час, чтобы прочитать и упорядочить записи предыдущих недель.
с большими базами кода первые впечатления могут быть обманчивыми, а проблемы, как правило, быстро перестраиваются, пока вы знакомитесь.
Помните, что проблемы из вашей последней рабочей среды не обязательно являются действительными или уместными в вашей новой среде. Остерегайтесь предвзятых представлений.
Заметки / замечания, которые вы сделаете, помогут вам быстро узнать, какие вопросы задавать и у кого. Надеюсь, вы собрали имена всех официальных (и неофициальных) заинтересованных сторон.
Один из лучших способов познакомиться с унаследованным кодом - это испачкать руки. Начните с исправления нескольких простых ошибок и перейдите к более сложным. Это согреет вас к коду лучше, чем систематическая проверка кода.
Если есть документ с требованиями или функциональной спецификацией (который, мы надеемся, обновлен), вы должны прочитать его.
Если есть высокоуровневый или подробный проектный документ (который, мы надеемся, обновленный), вам, вероятно, следует прочитать его.
Еще один хороший способ - организовать сеанс "передачи информации" с людьми, которые знакомы с кодом, где они представляют презентацию проекта высокого уровня, а также проводят обзор важных / хитрых частей кода.
Написать юнит-тесты. Вы найдете бородавки быстрее и будете увереннее, когда придет время менять код.
Попробуйте понять бизнес-логику кода. Как только вы узнаете, почему код был написан в первую очередь, и что он должен делать, вы можете начать читать его или, как кто-то сказал, просто исправлять несколько ошибок здесь и там.
Мои шаги будут:
1.) Настройте рабочее пространство / проект с исходной информацией (или любым хорошим браузером исходного кода, который вы используете) со всеми исходными файлами заголовков в базе кода. Брови на более высоком уровне от самой верхней функции (основной) до самой нижней функции. Во время просмотра кода продолжайте делать заметки на бумажном / или текстовом документе, отслеживая поток вызовов функций. Не вдавайтесь в подробности реализации функций на этом этапе, оставьте это для последующих итераций. На этом этапе отслеживайте, какие аргументы передаются в функции, возвращаются значения, как инициализируются передаваемые в аргументы аргументы, как изменяется значение набора этих аргументов, как используются возвращаемые значения?
2.) После одной итерации шага 1.) после чего у вас есть некоторый уровень кода и структур данных, используемых в базе кода, настройте MSVC (или любой другой соответствующий проект компилятора в соответствии с языком программирования базы кода), скомпилируйте код, выполняемый с допустимым контрольным примером, и снова выполните один шаг по коду от основного до последнего уровня функции. Между вызовами функций продолжайте помечать значения переданных, возвращенных переменных, взятых различных путей кода, избегать различных путей кода и т. Д.
3.) Продолжайте повторять 1.) и 2.) итеративно до тех пор, пока вы не освоитесь, до того момента, когда вы сможете изменить некоторый код / добавить некоторый код / найти ошибку в существующем коде / исправить ошибку!
-ОБЪЯВЛЕНИЕ
Я не знаю, что это "лучший способ", но кое-что, что я сделал на недавней работе, - это написал кодовый паук / парсер (на Ruby), который прошел и построил дерево вызовов (и обратное дерево вызовов), которое Я мог бы позже запросить. Это было немного нетривиально, потому что у нас был PHP, который называл Perl, который называл функции / процедуры SQL. Любые другие инструменты для сканирования кода могут помочь аналогичным образом (например, javadoc, rdoc, perldoc, Doxygen и т. Д.).
Чтение любых юнит-тестов или спецификаций может быть весьма поучительным.
Помогает документирование вещей (как для себя, так и для других товарищей по команде, текущих и будущих). Прочитайте любую существующую документацию.
Конечно, не стоит недооценивать силу просто задавать вопросы товарищу по команде (или вашему боссу!). Вначале я спрашивал столько раз, сколько необходимо: "есть ли у нас функция / скрипт /foo, которая делает X?"
Еще одна процедура...
После прочтения книги Энди Ханта "Прагматическое мышление и обучение - рефакторинг вашей посуды" (в которой это напрямую не рассматривается) я подобрал несколько советов, которые, возможно, стоит упомянуть:
Наблюдайте за поведением:
Если есть пользовательский интерфейс, тем лучше. Используйте приложение и получите ментальную карту отношений (например, ссылки, модалы и т. Д.). Посмотрите на HTTP-запрос, если он помогает, но не придавайте этому особого значения - вам просто нужно легкое дружеское знакомство с приложением.
Подтвердите структуру папок:
Еще раз, это свет. Просто посмотрите, что и где принадлежит, и надейтесь, что структура достаточно семантическая - отсюда всегда можно получить некоторую информацию верхнего уровня.
Анализировать кол-стеки сверху вниз:
Пройдите и составьте список на бумаге или другом носителе, но постарайтесь не набирать его - это задействует разные части вашего мозга (если нужно, создайте его из Legos) - вызовы функций, объекты и переменные, которые ближе всего к верхнему уровню Посмотрите на константы и модули, убедитесь, что вы не погрузитесь в мелкозернистые функции, если можете помочь.
MindMap Это!:
Возможно, самый важный шаг. Создайте очень черновое отображение вашего текущего понимания кода. Убедитесь, что вы быстро пробежали по карте ума. Это позволяет равномерно распределить различные части вашего мозга (в основном R-Mode), чтобы иметь право голоса на карте.
- Создайте облака, коробки и т. Д. Везде, где вы изначально думаете, что они должны идти на бумаге. Не стесняйтесь обозначать поля с синтаксическими символами (например, "F'-функция", "f" -закрытие, "C" -константа, "V'-глобальная переменная", "v" низкоуровневая переменная и т.д.) Используйте стрелки: входящий массив для аргументов, исходящий для возвратов или что более естественно для вас.
- Начните рисовать связи, чтобы обозначить отношения. Это нормально, если выглядит грязно - это первый проект.
- Сделайте быстрый грубый пересмотр. Его слишком сложно читать, сделайте еще одну быструю организацию, но не делайте больше одной ревизии.
Откройте отладчик:
- Подтвердите или аннулируйте любые представления, которые у вас были после сопоставления. Отслеживание переменных, аргументов, возвратов и т. Д.
- Отслеживайте HTTP-запросы и т. Д., Чтобы получить представление о том, откуда поступают данные. Посмотрите на сами заголовки, но не углубляйтесь в детали тела запроса.
Снова MindMap!
Теперь вы должны иметь представление о большинстве функциональных возможностей верхнего уровня.
- Создайте новую MindMap, в которой есть все, что вы пропустили в первой. Вы можете потратить больше времени на это и даже добавить относительно небольшие детали - но не бойтесь того, с какими предыдущими понятиями они могут конфликтовать.
- Сравните эту карту с вашей последней и устраните все вопросы, которые у вас были раньше, запишите новые вопросы и запишите противоречивые перспективы.
- Пересмотрите эту карту, если она слишком туманная. Изменяйте столько, сколько хотите, но сводите изменения к минимуму.
Притворись, что это не код:
Если вы можете выразить это механически, сделайте это. Наиболее важной частью этого является создание метафоры для поведения приложения и / или небольших частей кода. Думайте о смешных вещах, серьезно. Если это было животное, монстр, звезда, робот. Какой это будет вид. Если бы это было в Star Trek, для чего бы они его использовали. Подумайте о многих вещах, чтобы взвесить это.
Синтез над анализом:
Теперь вы хотите увидеть не "что", а "как". Любые низкоуровневые детали, которые через вас для петли могут быть извлечены и помещены в стерильную среду (вы контролируете их входы). Какие результаты вы получаете. Является ли система более сложной, чем вы думали изначально? Simpler? Нужны ли улучшения?
Внести что-то, чувак!
Написать тест, исправить ошибку, прокомментировать ее, абстрагировать ее. У вас должно быть достаточно способностей, чтобы начать делать небольшие взносы, и FAILING IS OK:)! Обратите внимание на любые изменения, внесенные вами в коммиты, чат, электронную почту. Если вы сделали что-то подлое, вы, ребята, можете поймать это прежде, чем оно пойдет в производство - если что-то не так, это отличный способ заставить товарища по команде прояснить ситуацию для вас. Обычно слушание разговора с товарищем по команде многое прояснит, что привело к столкновению MindMaps.
Короче говоря, самое важное, что нужно сделать, это использовать нисходящий способ задействовать как можно больше различных частей вашего мозга. Это может даже помочь закрыть ноутбук и, если это возможно, повернуть лицо к окну. Исследования показали, что соблюдение крайнего срока создает "похмелье под давлением" в течение ~2,5 дней после крайнего срока, поэтому именно такие сроки лучше всего использовать в пятницу. Так что БУДЬТЕ РАССЛАБЛЕННЫМ, ТАМ НЕТ ВРЕМЕНИ, И ТЕПЕРЬ ОБЕСПЕЧИ СВОЮ СРЕДУ, В КОТОРОЙ БЕЗОПАСНО ПРОВЕРИТЬ. Большая часть этого может быть довольно спеша, пока вы не приступите к деталям. Убедитесь, что вы не обходите понимание тем высокого уровня.
Надеюсь, это поможет и вам:)
Пользователи vi и emacs могут использовать только теги. Теги содержатся в файле (обычно он называется TAGS). Вы генерируете один или несколько файлов тегов с помощью команды ( etags для emacs vtags для vi). Затем мы редактируем исходный код и видим сбивающую с толку функцию или переменную, загружаем файл тегов, и он доставит вас туда, где объявлена функция (не достаточно совершенная, но достаточно хорошая). Я на самом деле написал несколько макросов, которые позволяют вам перемещаться по источнику с помощью Alt-курсора, вроде popd и pushd во многих разновидностях UNIX.
BubbaT
Пройдите по основным библиотекам и прочитайте объявления функций. Если это C/C++, это означает только заголовки. Документируйте все, что вы не понимаете.
В последний раз, когда я делал это, один из комментариев, который я вставил, был "Этот класс никогда не используется".
Попытайтесь понять код, исправляя ошибки в нем. Исправьте или поддержите документацию. Не изменяйте комментарии в самом коде, это может привести к появлению новых ошибок.
В целом, в нашей работе мы не вносим никаких изменений в производственный код без уважительной причины. Это включает косметические изменения; даже они могут вносить ошибки.
Независимо от того, как выглядит отвратительный фрагмент кода, не поддавайтесь искушению переписать его, если у вас нет исправления или другого изменения. Если вы обнаружили ошибку (или возможную ошибку) при чтении кода, пытаясь его изучить, запишите ошибку для последующей сортировки, но не пытайтесь ее исправить.
Я имел дело с этой проблемой много раз. Я закончил тем, что написал сообщение в блоге об общем процессе изучения новой кодовой базы: http://www.larsavery.com/blog/a-process-for-learning-a-new-codebase/
Все действительно хорошие ответы здесь. Просто хотел добавить еще несколько вещей:
Можно соединить архитектурное понимание с флэш-картами, и повторное посещение может укрепить понимание. Я нахожу такие вопросы, как "Какую часть кода выполняет функциональность X?", Где X может быть полезной функциональностью в вашей кодовой базе.
Мне также нравится открывать буфер в emacs и начинать переписывать некоторые части базы кода, с которыми я хочу ознакомиться, добавить свои собственные комментарии и т. Д.
Создайте документацию для каждой вещи, которую вы выяснили из кодовой базы. узнайте, как это работает, по экспериментированию - измените несколько строк здесь и там и посмотрите, что произойдет. используйте geany, поскольку это ускоряет поиск часто используемых переменных и функций в программе и добавляет его к автозаполнению. узнайте, можете ли вы связаться с оригинальными разработчиками кодовой базы, через Facebook или с помощью поиска в Google. выясните исходное назначение кода и посмотрите, соответствует ли этот код цели или его следует переписать с нуля в соответствии с поставленной целью.
выясните, какие фреймворки использовал код, какие редакторы использовали для создания кода.
Самый простой способ определить, как работает код, - это на самом деле воспроизвести, как определенная часть была бы сделана вами, и перепроверить код, если такая часть существует.
это обратный инжиниринг - выяснить что-то, просто пытаясь перестроить решение.
большинство программистов имеют опыт кодирования, и есть определенные шаблоны, которые вы можете найти, если они присутствуют в коде.
Есть два типа кода, объектно-ориентированный и структурно-ориентированный.
если вы знаете, как делать то и другое, вы можете идти, но если вы не знакомы с тем или другим, вам придется заново учиться программировать таким образом, чтобы понять, почему это было так закодировано.
в объектно-ориентированном коде вы можете легко создавать диаграммы, документирующие поведение и методы каждого класса объектов.
если он структурно ориентирован, то есть по функциям, создайте список функций, документирующий, что делает каждая функция и где она появляется в коде.
Я сам не делал ничего из вышеперечисленного, так как я веб-разработчик, относительно легко понять, начиная с index.php и до остальных страниц, как что-то работает.
удачи.
Первое, что я делаю перед тем, как углубляться в код, - это использую приложение (как несколько разных пользователей, если необходимо), чтобы понять все функции и посмотреть, как они соединяются (как информация течет внутри приложения).
После этого я проверяю среду, в которой было построено приложение, чтобы я мог установить прямую связь между всеми интерфейсами, которые я только что видел, с помощью некоторого кода View или UI.
Затем я смотрю на базу данных и любой уровень обработки команд базы данных (если применимо), чтобы понять, как хранится эта информация (которой манипулируют пользователи) и как она поступает и поступает из приложения.
Наконец, узнав, откуда поступают данные и как они отображаются, я смотрю на уровень бизнес-логики, чтобы увидеть, как преобразуются данные.
Я полагаю, что каждая архитектура приложения может быть разделена таким образом, и знание общей функции (кто есть кто в вашем приложении) может быть полезным перед его реальной отладкой или добавлением новых вещей - то есть, если у вас есть достаточно времени для этого.
И да, это также очень помогает общаться с кем-то, кто разработал текущую версию программного обеспечения. Однако, если он / она собирается покинуть компанию в ближайшее время, запишите его / ее список пожеланий (что они хотели сделать для проекта, но не смогли из-за бюджетных ограничений).