Все, чему я научился как архитектор приложений при создании своего продукта
28 декабря 2023 г.В этой статье мы исследуем важность архитектуры решений для небольших приложений и почему участие архитектора может иметь существенное значение. Автор делится своим опытом создания документа архитектуры решения и тем, как они решили хранить все заметки и документы в виде текстовых файлов в формате MD, давая представление о том, как создавать привлекательные файлы README.md с использованием значков от щитов. , предоставляя структуру документа и необходимые главы. В статье также рассматриваются такие темы, как определение требований, управление инструментами разработки и библиотеками, а также создание эффективной документации для небольших приложений.
* «Вы шутите?» - можете спросить вы. "Требуют ли такие небольшие приложения участия архитектора?"" * «Да, да и да!» — отвечал я.
Обычно архитекторы создают огромный документ, известный как Документ архитектуры решения, который включает в себя все. Изначально я придерживался того же подхода, но отслеживать изменения оказалось достаточно сложно из-за высокой частоты модификаций. Поэтому я решил хранить все заметки и документы в виде текстовых файлов в формате MD, как этот. Я также научился создавать привлекательные файлы README.md с использованием значков из щитов. , предоставляя структуру документа и необходимые главы.
Требования
Свой путь архитектора я начал с выбора требований. Выбрав правильные требования, архитектор может гарантировать, что программное обеспечение разработано с учетом конкретных бизнес целей и задач, а также технических и эксплуатационных требований. Это помогает обеспечить масштабируемость, удобство обслуживания и соответствие программного обеспечения потребностям как конечных пользователей, так и заинтересованных сторон. Стоит отметить, что мой подход к выбору требований отличался от подхода менеджера по продукту< /a> потому что мне нужно было больше технических требований. Я разделил требования архитектора на четыре части:
* Ограничения; * Предположения; * Атрибуты качества; * и Требования к оборудованию.
Ограничения
Ограничения — это факторы, ограничивающие возможности архитектора по проектированию и реализации программного решения. Эти факторы могут включать технические, деловые или организационные ограничения, влияющие на процесс разработки.
Я перечислил их на следующей странице в виде таблицы со следующими столбцами:
- Ограничение – для описания самого ограничения;
- Описание – чтобы предоставить более подробную информацию об ограничении;
- Бизнес-ценность – для указания бизнес-ценности ограничения (высокая, средняя или низкая);
- Точка зрения архитектуры – для указания ресурсов, необходимых для реализации ограничения (высокое, среднее или низкое).
Предположения
Предположения — это заявления, сделанные архитектором об окружающей среде, условиях или факторах, которые Ожидается, что они будут верными для того, чтобы программное решение функционировало должным образом. Эти утверждения сделаны на основе доступной информации, но их не обязательно подтверждают.
Предположения важно учитывать при выборе требований, поскольку они могут повлиять на проектирование и реализацию программного решения. Выявив предположения на ранних этапах процесса разработки, архитектор может предпринять шаги для проверки предположений и при необходимости скорректировать проект, чтобы гарантировать, что решение будет работать так, как задумано.
Атрибуты качества
Атрибуты качества, также известные как нефункциональные требования, — это характеристики программного обеспечения. решение, описывающее, насколько хорошо оно работает с точки зрения его эксплуатации, обслуживания и развития. Атрибуты качества напрямую связаны не с функциональностью программного обеспечения, а с тем, насколько оно соответствует определенным стандартам или требованиям.
Атрибуты качества важно учитывать при выборе требований, поскольку они могут повлиять на удобство использования, стоимость владения и долгосрочный успех программного решения.
Атрибуты качества представлены в виде таблицы со следующими столбцами:< /п>
- Имя: для описания атрибута качества.
- Описание: чтобы предоставить дополнительную информацию об атрибуте качества.
- Мотивация: объяснить причину выбора атрибута качества.
- Измеримые показатели: для обозначения показателей, используемых для измерения того, достигнут ли атрибут качества или нет.
- Бизнес-приоритеты: для указания бизнес-приоритетов для атрибута качества.
- Приоритеты архитектуры: для указания приоритетов архитектуры для атрибута качества.
Требования к оборудованию
И последнее, но не менее важное: требования к оборудованию.
Требования к оборудованию относятся к физическим компонентам, таким как серверы, устройства хранения и сетевое оборудование, которые необходимы для поддержки программного решения. Эти требования основаны на потребностях программного обеспечения и ожидаемой рабочей нагрузке или моделях использования.
На этапе проектирования архитектуры важно учитывать требования к оборудованию, чтобы гарантировать, что решение будет работать в пределах ограничений и возможностей оборудования, которое будет использоваться для его поддержки.
Представления архитектуры программного обеспечения
Представления архитектуры программного обеспечения — это представления различных аспектов программной системы, предназначенные для передачи конкретной информации различным заинтересованным сторонам. Они обеспечивают структурированный способ организации и представления информации об архитектуре программной системы. Используя представления архитектуры программного обеспечения, архитекторы могут гарантировать, что все заинтересованные стороны имеют четкое представление о системе и ее архитектуре, что может помочь избежать недоразумений и гарантировать, что система спроектирована с учетом потребностей всех заинтересованных сторон. .
Я создал три представления архитектуры программного обеспечения:
- Контекстное представление,
- Функциональный вид.
- и представление развертывания.
Я использовал Mermaid.js, поскольку теперь он поддерживается GitHub.
Контекстное представление
Контекстное представление – это тип представления архитектуры программного обеспечения, который обеспечивает общий обзор программной системы и ее внешней среды.
Он показывает отношения между программной системой и ее пользователями, другими системами и внешними объектами.
Представление Контекст полезно для заинтересованных сторон, которым необходимо глубокое понимание программной системы и ее контекстов, например бизнес-аналитики, менеджеры проектов или владельцы систем.
Функциональный вид
Функциональное представление – это тип представления архитектуры программного обеспечения, в котором основное внимание уделяется функциональным или поведенческим аспектам программной системы. Он описывает функциональные элементы или компоненты системы и то, как они взаимодействуют друг с другом для выполнения желаемых задач или функций.
Функциональное представление полезно для архитекторов программного обеспечения, разработчиков и тестировщиков, которым необходимо понимать функциональные требования системы и как они реализованы.
Просмотр развертывания
Представление развертывания – это тип представления архитектуры программного обеспечения, который описывает, как программная система развертывается или устанавливается в вычислительной среде. На нем показаны физические элементы системы, такие как серверы, сети и устройства хранения, а также то, как они подключены и настроены для поддержки программной системы.
Представление развертывания полезно для системных администраторов, операторов и специалистов по инфраструктуре, которым необходимо понимать, как программная система развертывается и управляется в вычислительной среде.
Поскольку набор инструментов FVA можно развернуть с использованием только одного узла и нескольких процессов, я предоставил простое текстовое описание для Представление развертывания.
Инструменты, библиотеки и языки
В какой-то момент я понял, что мне нужен лучший способ управления различными IDE, инструментами пользовательского интерфейса и командной строки, библиотеками и языками, которые я использую.
Инструменты и библиотеки
Я составил список всех инструментов и библиотек, которые использовал для разработки, и представил их в таблице на странице проекта< на GitHub< /а>. Таблица включает следующие столбцы:
- Назовите имя инструмента/библиотеки,
- Цель: предполагаемое назначение.
- Версия: версия, которую я использовал.
- Лицензия: лицензия, по которой она распространяется.
- Среда: платформа, на которой его можно запустить.
- и Комментарий: любая дополнительная информация, которую я хотел бы предоставить.
Изначально список был намного длиннее, но поскольку некоторые инструменты/библиотеки устарели, я вынес их в отдельную таблицу в том же формате. Старый список зависимостей можно найти здесь.
Языки
Я просто использовал простой текст для описания языков программирования, которые использует программное обеспечение FVA.
Лицензии
Безусловно, нужно помнить о лицензиях. Поскольку программное обеспечение FVA использует сторонние инструменты и библиотеки, соответствующие лицензии должны быть включены в код. . Кроме того, мне пришлось создать лицензию FVA и получить представление о том, что такое лицензия и как ее создать.
:::информация Также опубликовано здесь.
:::
Оригинал