Как сделать предпроектную проверку архитектуры

Question

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

Мы планируем провести проверки архитектуры до начала кодирования.

Один из способов - просто найти архитекторапредставить проект и посмотреть, сможем ли мы найти недостатки в дизайне.

Есть ли у кого-то более структурированный подход, может быть, с контрольным списком "Вы думали" или "Как вы собираетесь это сделать"?

Я думал о чем-то вроде:

• Безопасность
• Запись
• Доступ к данным
• Развертывание
• Обновление

Answer 1

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

Answer 2

Дополнительные элементы, добавляемые в ваш список, в произвольном порядке:

• Производительность - задержка, пропускная способность, масштабирование или другие факторы, связанные с вашим результатом
• Поддерживаемость - у вас уже есть регистрация, но как насчет подключения к другим диагностическим измерениям (счетчики Java-JMX, Windows-WMI / Performance или что-то другое)
• Гибкость - Сложность с изменением архитектуры позже (обычно это одна из тех вещей, которые чрезмерно выполнены и вызывают больше проблем, чем необходимо, но обсуждение должно присутствовать при оценке проекта)
• Модель многопоточности / модель блокировки - Понятно ли, как будут защищены данные? Как будет решаться конфликт ресурсов?
• Требования к ресурсам - потребление памяти на разных уровнях использования. Это вписывается в ваши ограничения?
• Обработка ошибок - Когда что-то в продукте выходит из строя, поддерживает ли архитектура чистую обработку и уведомление о проблемах?
• Понятно - Чрезмерно сложные архитектуры, как правило, забываются при реализации. Если большая часть команды, и в особенности руководители, не могут держать архитектуру, ее философии и правила, в их голове архитектура не будет иметь значения.
• Последовательность. Пытается ли он использовать все возможные паттерны или сосредоточиться на регулярных, повторяющихся паттернах? Не то, чтобы выбор правильного шаблона для каждой проблемы - это нехорошо, но наличие большого количества шаблонов может повлиять на понятность и привести к ошибкам реализации. Архитектор должен стараться демонстрировать все, что они знают (или последнюю классную вещь) в каждом проекте.
• Тестируемый. Помогает ли проект или мешает тестированию (системному и интеграционному). Может ли тестирование быть автоматизированным, или вы будете полагаться на армию тестировщиков, чтобы постоянно повторять регрессионное тестирование, чтобы вы знали, что ваша команда не сломала продукт?
• Действительно ли архитектура решает проблему, которую вы пытаетесь решить, и в рамках этой проблемы? Не создавайте небоскреб, когда будет достаточно дуплекса.

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Я полагаю, что это хорошая практика - постоянно делать обзоры архитектуры. Это не шаг, который вы просто «завершаете».