Понимание программной системы

Question

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

Я стараюсь сделать хорошее начало, но застенчивость и страх появления глупостей затрудняют задание вопросов. Как задавать вопросы?

Я хотел спросить, какие методы вы используете для понимания проекта? Я имею в виду, что есть много технических деталей, которые нужно запомнить и сохранить в контексте, чтобы сделать дизайн. Вы читаете код и получаете некоторые факты, но как двигаться дальше? Например, вы читаете код и документ (ы) и получаете некоторые факты A и факт B. Как достичь подходящего заключения X, для которого вам может потребоваться или не нужно было учитывать факты C и D также?

Answer 1

Чтение кода сбалансировано путем написания документации.

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

Если вы не можете объяснить что-то своей замене, задайте вопросы.

Если у вас есть полное описание, вы будете «знать» систему.

И вы получите полную документацию.

Answer 2

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

1. Структура - есть ли какие-либо разбиения сущностей/системы? Где в коде (и как) они общаются друг с другом?

2. Данные - какие структуры используются для хранения глобальных данных? Как данные доступны и сохранены?

3. Если вы выполняете C или C++, также важно выяснить, как обрабатывается память, и для C++ (и, возможно, других языков OOP, не связанных с управлением памятью), как это связано с владением объектами.

4. Поскольку это внедренный проект, существуют ли какие-либо нестандартные кодовые или кодирующие конструкции?

Answer 3

Вы не упомянули, какие существуют испытания. Если есть тестовые примеры, измените их и проследите, как это повлияет на конечный результат.

Answer 4

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

Answer 5

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

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