Какой лучший способ познакомиться с большой кодовой базой?
Присоединение к существующей команде с уже существующей большой кодовой базой может быть пугающим. Какой лучший подход;
- Широкий; попытаться получить общий обзор того, как все связывает воедино, из кода
- Узкие; сосредоточиться на небольших разделах кода за раз, понимая, как они работают полностью
- Выберите функцию, чтобы развиваться и учиться по ходу дела
- Попробуйте получить представление о диаграммах классов и uml, если они доступны (и в курсе)
- Что-то еще целиком?
Я работаю над тем, что в настоящее время составляет около 20 тыс. Строк приложения и библиотеки C++ (Edit: small по большому счету!). В индустрии, я думаю, вы познакомитесь с опытным программистом. Однако, если это не так, что вы можете сделать, чтобы начать добавлять стоимость как можно быстрее?
-
Резюме ответов:
- Пошаговый код в режиме отладки, чтобы увидеть, как он работает
- Соединитесь с кем-то, кто более знаком с базой кода, чем вы, по очереди, чтобы быть человеком, который кодирует, и человеком, который смотрит / обсуждает. Вращайте партнеров среди членов команды, чтобы знания распространялись.
- Написать юнит-тесты. Начните с утверждения о том, как вы думаете, код будет работать. Если все получается так, как вы ожидали, вы, вероятно, поняли код. Если нет, вам нужно решить головоломку и / или сделать запрос. (Спасибо, Донал, это отличный ответ)
- Пройдите существующие модульные тесты для функционального кода, аналогично описанному выше
- Прочитайте UML, сгенерированные Doxygen диаграммы классов и другую документацию, чтобы получить более полное представление о коде.
- Сделайте небольшие правки или исправления ошибок, затем постепенно наращивайте
- Делайте заметки, не прыгайте и не начинайте развиваться; более важно потратить время на понимание, чем на создание грязного или неуместного кода.
этот пост является частичной копией лучшей базы для ознакомления себя с унаследованной кодовой базой
19 ответов
Если возможно, начните с небольшой задачи, отладьте код вокруг вашей проблемы. Прохождение кода в режиме отладки - самый простой способ узнать, как что-то работает.
Другой вариант - написать тесты для функций, которые вас интересуют. Настройка набора тестов - это хороший способ установить, какие зависимости есть у системы и где находится ее состояние. Каждый тест начинается с утверждения о том, как система должна работать. Если это работает таким образом, вы чего-то добились и у вас есть некоторый рабочий пример кода для его воспроизведения. Если это не сработает, вам нужно решить головоломку и провести расследование.
Одна вещь, которую я обычно предлагаю людям, которые еще не упоминались, это то, что важно стать компетентным пользователем существующей базы кода, прежде чем вы сможете стать разработчиком. Когда новые разработчики приходят в наш большой программный проект, я предлагаю им потратить время на то, чтобы стать опытными пользователями, прежде чем пытаться работать над кодом.
Может быть, это и так понятно, но я видел, как многие люди пытаются прыгнуть в код слишком быстро, потому что они стремятся начать прогрессировать.
Это зависит от того, какой вы ученик и какой программист, но:
- Широкий сначала - вам нужно представление о масштабах и размерах. Это может включать скимминг docs / uml, если они хороши. Если это долгосрочный проект и вам понадобится полное понимание всего, я мог бы на самом деле правильно прочитать документы. Опять же, если они хороши.
- Узкий - выберите что-то управляемое и попытайтесь понять это. Получить "вкус" для кода.
- Выберите функцию - возможно, отличную от той, на которую вы только что смотрели, если вы чувствуете себя уверенно, и начните вносить небольшие изменения.
- Итерируйте - оцените, насколько хорошо все прошло, и посмотрите, не выиграете ли вы от повторения более раннего шага.
Спаривание со строгим вращением.
Если возможно, просматривая документацию / кодовую базу, попробуйте использовать сопряжение со строгой ротацией. Это означает, что двое из вас сидят вместе в течение определенного периода времени (скажем, двухчасовой сеанс), затем вы переключаете пары, один человек будет продолжать работать над этой задачей, а другой переходит к другой задаче с другим партнером.
В парах вы оба получите знания, которые затем могут быть переданы другим членам команды, когда произойдет ротация. Что хорошо и в этом, так это то, что когда новая пара собирается вместе, тот, кто работал над задачей (в данном случае, исследует код), может затем обобщить и объяснить концепции в более понятном виде. С течением времени все должны быть на одинаковом уровне понимания и, надеюсь, избегать синдрома "О, только Джон знает этот бит кода".
Из того, что я могу рассказать о вашем сценарии, у вас есть хорошее число для этого (3 пары), однако, если вы распределены или не работаете в одном и том же масштабе времени, это вряд ли будет возможно.
Я бы посоветовал запустить на нем Doxygen, чтобы получить современную диаграмму классов, а затем немного подойти к ней. Это дает вам краткую общую картину, которую вы можете использовать, когда будете подходить поближе к коду.
Я согласен, что это полностью зависит от того, какой вы тип ученика. Сказав это, я был в двух компаниях, у которых были очень большие кодовые базы для начала. Как правило, я работаю так:
Если возможно, прежде чем рассматривать какой-либо функциональный код, я прошёл модульные тесты, которые уже написаны. Как правило, они могут очень помочь. Если они недоступны, я делаю следующее.
Во-первых, я в значительной степени игнорирую реализацию и смотрю только на заголовочные файлы или только на интерфейсы классов. Я пытаюсь понять, какова цель каждого класса. Во-вторых, я углубляюсь в реализацию, начиная с того, что представляется наиболее важной областью. Это трудно измерить, поэтому иногда я просто начинаю сверху и прохожу путь вниз по списку файлов. Я называю это изучением в ширину. После этого начального шага я обычно углубляюсь в остальную часть кода. Первоначальный взгляд в ширину помогает закрепить / исправить любые идеи, которые я получил от уровня интерфейса, а затем взгляд в глубину показывает мне шаблоны, которые использовались для реализации системы, а также различные идеи дизайна. Под глубиной я имею в виду, что вы в основном проходите через программу с помощью отладчика, заходите в каждую функцию, чтобы увидеть, как она работает, и так далее. Это, очевидно, невозможно на действительно больших системах, но 20 тыс. LOC не так много.:)
У меня была похожая ситуация. Я бы сказал, что вы идете так:
- Если это приложение, управляемое базой данных, начните с базы данных и попытайтесь разобраться в каждой таблице, ее полях, а затем в ее отношении к другим таблицам.
- Как только все будет в порядке с базовым хранилищем, перейдите на уровень ORM. Эти таблицы должны иметь какое-то представление в коде.
- После этого перейдите к тому, как и откуда эти объекты берутся. Интерфейс? какой интерфейс? Какие-либо проверки? Какая предварительная обработка происходит на них, прежде чем они отправляются в хранилище данных?
Это лучше познакомит вас с системой. Помните, что попытка написать или понять модульные тесты возможна только тогда, когда вы очень хорошо знаете, что тестируется и почему его нужно тестировать только таким способом.
А в случае большого приложения, которое не ориентировано на базы данных, я бы рекомендовал другой подход:
- Какова основная цель системы?
- Каковы основные компоненты системы, чтобы решить эту проблему?
- Какое взаимодействие имеет каждый компонент? Сделайте график, который изображает зависимости компонентов. Спросите кого-то, кто уже работает над этим. Эти компоненты должны что-то обмениваться между собой, поэтому постарайтесь выяснить это (например, IO может возвращать объект File обратно в GUI и т. П.)
- Когда вам будет удобно, погрузитесь в компонент, который меньше всего зависит от других. Теперь изучите, как этот компонент делится на классы и как они взаимодействуют друг с другом. Таким образом, вы получите общий вид одного компонента
- Перейти к следующему наименее зависимому компоненту
- До самого конца перейдите к основному компоненту, который обычно зависел бы от многих других компонентов, с которыми вы уже работали
- Глядя на основной компонент, вы, возможно, обращаетесь к компонентам, которые вы исследовали ранее, так что не беспокойтесь, продолжайте усердно работать!
Для первой стратегии: возьмем, к примеру, этот сайт stackru. Изучите хранилище данных, что хранится, как хранится, какие представления эти элементы имеют в коде, как и где они представлены в пользовательском интерфейсе. Откуда они приходят и какая обработка происходит на них, когда они возвращаются в хранилище данных.
Для второго Возьмем пример текстового процессора, например. Какие компоненты есть? IO, UI, Page и т.п. Как они взаимодействуют друг с другом? Двигайтесь дальше, когда вы учитесь дальше.
Будьте расслаблены. Письменный код - это чье-то мышление, застывшая логика и стиль мышления, и чтобы прочесть это мнение, потребуется время.
Работайте с другим программистом, который более знаком с системой, чтобы разработать новую функцию или исправить ошибку. Это метод, который я видел, работает лучше всего.
Если у него есть юнит-тесты (держу пари, что нет). Начните с малого и убедитесь, что юнит-тесты не провалились. Если вы смотрите на всю кодовую базу сразу, ваши глаза застекятся, и вы будете чувствовать себя разбитым.
Если нет модульных тестов, вам нужно сосредоточиться на функции, которую вы хотите. Запустите приложение и посмотрите на результаты того, что должно повлиять на вашу функцию. Затем начните просматривать код, пытаясь понять, как приложение создает то, что вы хотите изменить. Наконец, измените его и убедитесь, что результаты получаются так, как вы хотите.
Вы упомянули, что это приложение и библиотека. Сначала измените приложение и придерживайтесь использования библиотеки в качестве пользователя. Тогда после того, как вы изучите библиотеку, ее будет легче изменить.
При подходе сверху вниз приложение, вероятно, имеет основной цикл или основной графический интерфейс, который контролирует все действия. Стоит понять основной поток управления приложением. Стоит прочитать код, чтобы дать себе широкий обзор основного потока приложения. Если это приложение с графическим интерфейсом, создайте документ, который показывает, какие экраны есть и как перейти с одного экрана на другой. Если это приложение командной строки, то как выполняется обработка.
Даже в компаниях такой подход не редкость. Часто никто не понимает, как работает приложение. И у людей нет времени, чтобы показать вам это. Они предпочитают конкретные вопросы о конкретных вещах, поэтому вы должны сами покопаться и поэкспериментировать. Затем, как только вы получите конкретный вопрос, вы можете попытаться выделить источник знаний для этой части приложения и задать его.
Во-первых, если у вас есть члены команды, которые имеют опыт работы с кодом, вы должны договориться, чтобы они сделали обзор кода с вами. Каждый член команды должен предоставить вам информацию о своей области знаний. Обычно полезно, чтобы несколько человек объясняли вещи, потому что некоторые из них будут лучше объяснять, чем другие, а некоторые будут лучше понимать, чем другие.
Затем вам нужно некоторое время начать читать код без какого-либо давления (пару дней или неделю, если ваш босс это предоставит). Это часто помогает скомпилировать / собрать проект самостоятельно и иметь возможность запустить проект в режиме отладки, чтобы вы могли пошагово выполнить код. Затем начните намокать ноги, исправляя небольшие ошибки и делая небольшие улучшения. Будем надеяться, что скоро вы будете готовы к среднему проекту, а позже - к большому. Продолжайте опираться на своих товарищей по команде на ходу - часто вы можете найти кого-то конкретного, кто готов наставить вас.
Не будь слишком жесток к себе, если борешься - это нормально. Может потребоваться много времени, может быть годы, чтобы понять большую кодовую базу. На самом деле, часто бывает так, что даже спустя годы все еще есть некоторые части кода, которые все еще немного пугающие и непрозрачные. Когда вы получаете время простоя между проектами, вы можете копаться в этих областях, и вы часто обнаруживаете, что после нескольких попыток вы можете разобраться даже с этими частями.
Удачи!
Я думаю, что вам нужно привязать это к конкретной задаче. Когда у вас есть время, выбирайте подход, к которому у вас есть настроение.
Когда у вас есть что-то, что нужно сделать, сосредоточьтесь на себе и сделайте это.
Начните с понимания "проблемной области" (система заработной платы, инвентарь, контроль в реальном времени или что-то еще). Если вы не понимаете жаргон, используемый пользователями, вы никогда не поймете код.
Затем посмотрите на объектную модель; возможно, диаграмма уже существует, или вам, возможно, придется перепроектировать ее (вручную или с помощью инструмента, предложенного Дагом). На этом этапе вы также можете исследовать базу данных (если таковая имеется), если она должна следовать объектной модели, но это не так, и это важно знать.
Посмотрите историю изменений или базу данных ошибок, если есть область, которая часто появляется, посмотрите сначала на этот бит. Это не значит, что это плохо написано, но это то, что каждый использует.
Наконец, сохраните некоторые заметки (я предпочитаю вики).
- Существующие парни могут использовать это, чтобы рассудить, проверить ваши предположения и помочь вам.
- Вам нужно будет вернуться к нему позже.
- Следующий новый парень в команде будет действительно благодарен вам.
Вы можете рассмотреть возможность использования инструментов обратного инжиниринга исходного кода. Есть два инструмента, о которых я знаю:
- SWAG Kit (только для Linux) ссылка
- Баухаус академический рекламный ролик
Оба инструмента предлагают похожие наборы функций, которые включают статический анализ, который создает графики отношений между модулями в программном обеспечении.
В основном это графы вызовов и приличия типа / класса. Просмотр этой информации должен дать вам хорошее представление о том, как части кода связаны друг с другом. Используя эту информацию, вы можете найти действительный источник информации для тех частей, которые вас больше всего интересуют и которые вам необходимо понять / изменить в первую очередь.
Попросите команду поставить вас на исправление ошибки на две недели (если у вас есть две недели). Они будут рады, если кто-то возьмет на себя ответственность за это, и к концу этого периода вы потратите столько времени на решение проблем с библиотекой, что вы, вероятно, будете это хорошо знать.
Мне нравятся все ответы, в которых говорится, что вы должны использовать такой инструмент, как Doxygen, чтобы получить диаграмму классов, и сначала попытаться понять общую картину. Я полностью согласен с этим.
Тем не менее, это в значительной степени зависит от того, насколько хорошо кодируется код для начала. Если это гигантский беспорядок, это будет трудно учиться. Если это чисто и организовано должным образом, это не должно быть так плохо.
Я считаю, что просто переход к коду может быть немного ошеломляющим. Постарайтесь прочитать как можно больше документации по дизайну. Это, мы надеемся, объяснит цель и структуру каждого компонента. Лучше всего, если существующий разработчик может провести вас через это, но это не всегда возможно.
Как только вы освоитесь с высокоуровневой структурой кода, попробуйте исправить одну или две ошибки. это поможет вам разобраться с реальным кодом.
Посмотрите этот ответ о том, как использовать инструменты тестирования покрытия, чтобы найти код для интересующей функции, ничего не зная о том, где находится эта функция или как она распространяется на многие модули.
(бесстыдный маркетинг впереди)
Вы должны проверить nWire. Это плагин Eclipse для навигации и визуализации больших кодовых баз. Многие наши клиенты используют его для привлечения новых разработчиков, распечатывая визуализации основных потоков.