Как вы отслеживаете крупные проекты?

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

Мой опыт: я веб-программист-самоучка. Я имел дело в основном с python для быстрых и грязных скриптов, но я также сделал несколько базовых проектов django . Мне нравятся веб-фреймворки, такие как flask , потому что, благодаря простоте разметки одного файла, я могу легко отслеживать (в основном) происходящее.

Теперь я нахожусь в ситуации, когда мне нужно взаимодействовать с большим PHP-проектом Zend Framework, который кто-то другой разработал, и я потрясен попыткой понять код, разбросанный по многочисленным файлам.

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

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

Grep, отладчики и intellisense ваши друзья здесь. Если вы не знаете, как вызывается функция, установите для нее точку останова и проложите себе путь вниз по трассе стека.

Еще одна вещь, которую стоит отметить, это то, что большие базы кода не возникают из ниоткуда. Чем оно больше, тем больше программистов с этим опытом, поэтому спросите их, с чего начать, но будьте конкретны. Задавайте вопросы типа «Мне нужно добавить нового поставщика платежей. Где в коде я должен искать?» Сосредоточьтесь только на этой задаче, вместо того, чтобы пытаться понять всю кодовую базу, и постепенно ваши знания будут расти.

Там нет ярлыка. Вы просто должны пережить это.

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

В более общем смысле, я сталкиваюсь с примерно следующими этапами, когда сталкиваюсь с новой кодовой базой:

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

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

3. Узнайте о любой среде, которую вы используете. Как минимум, вы должны иметь возможность создать «hello world» или другое простое приложение с этой средой, прежде чем погрузиться в производственное приложение.

4. Получите контроль над всем процессом развертывания (лучше всего делать, когда разработчики оригинала держат вас в руках). Если вы не можете взять текущую кодовую базу и собрать ее и развернуть в среде test / validation / prod, вы готовы. Даже самое маленькое изменение потребует перепрыгнуть через все циклы развертывания, так почему бы не снять эту часть прямо сейчас? При этом вы познакомитесь со всеми прекрасными серверами, базами данных, службами и сценариями, используемыми приложением - вы будете знать, «где оно живет».

5. Получить контроль над функциональными тестами (если таковые имеются). Как вы знаете, если вещь работает правильно? Что должны сделать сотрудники по уходу за приложением и кормлению?

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

---- Обратите внимание, что до этого момента я даже не упоминал, что внимательно изучал кодовую базу. Существует МНОГО вы можете узнать о большом проекте, даже не глядя на код. В какой-то момент, конечно, вы должны освоиться с кодом. Вот что мне помогает:

7. Для диаграмм doxygen - отличный инструмент, который будет генерировать графы вызовов и другие отношения для вас. Это имеет возможность PHP! Если вы еще не пробовали доксиген, вам обязательно нужно его попробовать. Хотя я не могу ручаться за то, насколько это понятно для кода внутри фреймворка, но это может помочь. Оригинальные разработчики часто шокированы тем, что они видят, когда им предоставляют документы, сгенерированные doxygen для их кода. Хорошей новостью является то, что это действительно помогает подтолкнуть их память и помочь вам лучше.

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

9. Закладки IDE бесценны для маркировки горячих точек в кодовой базе. Возможность быстрого переключения между ними будет способствовать пониманию.

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

По запросу, вот мой комментарий в качестве ответа.

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

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

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

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

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

c) Выполнить через общие пользовательские потоки (в приложении), а затем попытаться привести их в соответствие с тем, как выложен код.

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

Я дам вам знать, какие еще идеи я получу в течение следующих двух недель

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

Если вы работаете с чем-то действительно большим с нулевой документацией (я тоже был там, это грубо!), То я обнаружил, что это помогает - попытаться выделить часть, над которой вы работаете. В этой части кода выясните, как данные / события / сообщения / взаимодействия проходят и выходят из этого блока. Другими словами, перепроектируйте интерфейс. Запиши это. В следующий раз, когда вы работаете над другим подразделением (бонус, если он говорит с тем, с которым вы работали первым), сделайте то же самое. Храните всю свою документацию. Через несколько месяцев у вас будет хорошая картина того, как все это происходит.

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

Что я делаю, так это создаю единую модель UML из всех файлов, которые были преобразованы из Java в UML. Этот подход означает, что модель больше не является просто абстрактным представлением проекта, а сам проект полностью сопоставлен с MOF и, следовательно, с UML.

Я получаю большую единую модель, составленную из нескольких подмоделей, каждая из которых состоит из пакетов, составленных из классификаторов и т. Д. Работа на многопроектном уровне также позволяет мне отслеживать каждый классификатор и вызовы методов на многопроектных уровнях. Я имею в виду, что один и тот же метод может вызывать один классификатор в проекте A и другой классификатор в проекте B. Единственный способ увидеть полную структуру проекта - это обратить их обоих одновременно. У меня нет времени на создание диаграмм компонентов, и информация не очень точна. Я предпочитаю попросить компьютер полностью изменить проект для меня. Я делаю обратное на каждой итерации с командой, и все мои диаграммы немедленно обновляются. Обратный инжиниринг является инкрементным и использует отображение идентификаторов Java на UML. Я имею в виду, что каждый элемент Java сопоставлен с единственным уникальным элементом MOF, который остается неизменным в течение всей жизни проекта, даже если он подвергается рефакторингу. Это больше не ограничивает UML-моделирование и позволяет моделировать очень большие и сложные проекты. К вашему сведению я работаю с проектом, имеющим более 5 000 000 строк кода ООП. Все мои проекты перевернуты правильно и возможна графическая навигация

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