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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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