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

Question

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

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

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

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

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

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

Answer 1

Я использую знаменитую AT & T Graphviz , она проста и прекрасно работает. Это та же библиотека, что и Doxygen.

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

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

• Веб-сканер
• экстрактор данных
• Парсер
• нормализатор и фильтр

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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