Лучшие практики по управлению сложностью / визуализации компонентов в вашем программном обеспечении?

Question

Мы создаем инструменты для извлечения информации из Интернета.У нас есть несколько штук, таких как

• Сканирование данных из Интернета
• Извлечение информации на основе шаблонов и бизнес-правил
• Анализ результатов в базу данных
• Применяйте правила нормализации и фильтрации
• И т.д., и т.п.

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

Какие методы помогли вам понять сложные процессы и управлять ими?

• Используйте инструменты рабочего процесса, такие как Windows Workflow foundation
• Инкапсулируйте отдельные функции в инструменты командной строки и используйте скриптовые инструменты для связывания их вместе
• Напишите специфичный для домена язык (DSL), чтобы указать, в каком порядке все должно происходить на более высоком уровне.

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

Answer 1

В коде указано, что происходит на каждом этапе.Использование DSL было бы благом, но, возможно, нет, если это связано с написанием вашего собственного языка сценариев и / или компилятора.

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

Хорошие советы:

• Визуализируйте отношения вашей схемы базы данных.
• Используйте visio или другие инструменты (например, тот, который вы упомянули - не использовали его) для обзоров процессов (имхо, это относится к спецификации вашего проекта).
• Убедитесь, что ваш код правильно структурирован / разделен на части / и т.д.
• Убедитесь, что у вас есть какая-то спецификация проекта (или какая-то другая "общая" документация, которая объясняет, что система делает на абстрактном уровне).

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

Answer 2

Я использую знаменитые AT & T. Графиквиз, это просто и прекрасно выполняет свою работу.Это та же библиотека, которую использует Doxygen.

Кроме того, если вы приложите немного усилий, вы можете получить очень красивые графики.

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

Answer 3

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

В зависимости от вашей платформы и набора инструментов существует множество действительно полезных пакетов статического анализа, которые могли бы помочь вам документировать взаимосвязи между подсистемами или компонентами вашего приложения.Для платформы .NET, NDepend это хороший пример.Однако есть много других для других платформ.

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

Answer 4

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

Вам нужно нарисовать диаграмму высокого уровня (я люблю карандаш и бумагу).

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

Я бы подумал об использовании нескольких очередей для

• URL-адреса для обхода
• Просмотренные страницы из Интернета
• Извлеченная информация на основе шаблонов и бизнес-правил
• Проанализированные результаты
• нормализованные и отфильтрованные результаты

У вас были бы простые (вероятно, из командной строки без пользовательского интерфейса) программы, которые считывали бы данные из очередей и вставляли данные в одну или несколько очередей (сканер передавал бы обе "URL-адреса для обхода" и "Просмотренные страницы из Интернета"), Вы могли бы использовать:

• Веб-сканер
• Средство извлечения данных
• Синтаксический анализатор
• Нормализатор и фильтровщик

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

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

Answer 5

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

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

В качестве аргумента авторитета Джоэл рекомендует Функциональные спецификации здесь и здесь.

Answer 6

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

Answer 7

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

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

• Процессы (каждый компонент выполняется в изолированном пространстве памяти)
• Потоки (каждый компонент выполняется в отдельном потоке)
• Коммуникация (компоненты взаимодействуют через один простой канал передачи сообщений)

Я написал довольно сложные системы пакетной обработки, которые по звучанию похожи на вашу систему, использующую:

Каждый компонент сопоставляется с исполняемым файлом .NET Время жизни исполняемого файла управляется с помощью Autosys (все на одном компьютере) Связь осуществляется через TIBCO Rendezvous

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

Answer 8

Мне нравится использовать NDepend для обратного проектирования сложной базы кода .NET.Инструмент поставляется с несколькими замечательными функциями визуализации, такими как:

График зависимостей:

Матрица зависимостей:

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