Лучший способ ознакомиться с унаследованной кодовой базой - PullRequest
20 голосов
/ 18 октября 2008

Stacker Никто не спрашивал о самой шокирующей вещи, которую находят новые программисты, когда они входят в поле .

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

Как эффективно использовать все эти новые данные? Что облегчает этот переход? Является ли единственное реальное решение, которое уже внесло свой вклад в достаточное количество проектов с открытым исходным кодом, чтобы шок прошел?

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

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

Ответы [ 14 ]

1 голос
/ 18 октября 2008

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

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

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

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

0 голосов
/ 14 ноября 2018

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

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

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

0 голосов
/ 04 ноября 2008

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

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

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

это реверс-инжиниринг - выяснить что-то, просто пытаясь перестроить решение.

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

Существует два типа кода: объектно-ориентированный и структурно-ориентированный.

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

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

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

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

Гудлак.

0 голосов
/ 18 октября 2008

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

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

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

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

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

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

...