День 1318. #DevOps 6 Принципов Разработки Архитектуры ПО В последнее время термин «непрерывный» (continuous) очень часто используется в речи поставщиков ПО и экспертов как программная архитектура, которую мы все должны и хотим иметь. Проблема в том, что многие считают, что «непрерывный» означает быструю доставку. Однако проектирование непрерывной программной архитектуры требует постоянной обратной связи от всех участников процесса: архитекторов, дизайнеров, разработчиков, операторов — и постоянного улучшения. Разработка архитектуры ПО больше не может быть разовым процессом. Об этом на недавней конференции GOTO 2022 поговорили Пьер Пюрер, соавтор книги «Continuous Architecture in Practice», и Курт Биттнер, глава отдела корпоративных решений в Scrum.org. «Проектирование и поддержка хорошо функционирующей непрерывной программной архитектуры требует, прежде всего, терпения,» - считает Пюрер. - «Cпешить с технологическим решением, прежде чем задать правильные вопросы, означает упускать возможности или функции, которые могут быть жизненно важными для бизнеса. Я видел команды, которые начинают с конца, и они знают, что хотят внедрить какую-то технологию. Кто-то сказал им: «Нам нужно быть в облаке Amazon». Ответом будет облако Amazon, а вы даже не задаёте этот вопрос.» В течение многих лет проектирование архитектуры ПО означало проектирование чего-либо на начальном этапе, а затем переход к этапу развёртывания. Согласно традиционному представлению об архитектуре, «мы не пишем ни строчки кода, пока вся архитектура не будет собрана», — сказал Пюрер. «Проблема с таким подходом, конечно, в том, что очень сложно знать всё сразу. Проектирование архитектуры, когда более половины ваших требований неверны, не даст вам хороших результатов. Трудно предсказать, как система будет эволюционировать." Появились более гибкие подходы, что сделало процесс более итеративным. Тем не менее, это предполагает, что «вы пишете код, и архитектура каким-то образом появляется, как кит из воды». Но это приводит к необходимости «большого рефакторинга и перенастройки». Гибкая разработка — это шаг в правильном направлении, но для непрерывной архитектуры проектировщики и разработчики ПО должны сделать ещё один шаг. Им нужно задавать трудные вопросы: что нужно бизнесу? Что лучше сработает для пользователей или клиентов? Какие части бизнеса должны быть вовлечены в процесс проектирования? По словам Пюрера, в основе успешной непрерывной архитектуры лежат шесть принципов. «Ни один из принципов не является новым или революционным, но вместе они имеют большой смысл». Вот эти принципы: 1. Создавайте архитектуру продукта, а не проекта. Звучит очевидно, но многие об этом забывают. 2. Сосредоточьтесь на атрибутах качества, а не на обширности функционала. Да, функциональные требования важны, но, если качество не соответствует, у вас не получится эффективного продукта. 3. Откладывайте решения до тех пор, пока не будете уверены, что должны принять решение. У каждого решения есть цена. А если оно окажется неверным, будет и цена отката этого решения. Не принимайте решения слишком рано, пытаясь угадать, старайтесь основывать решение на фактах. 4. Планируйте изменения, потому что всё изменится — так что подумайте о «минималистичном дизайне». Хотя это не обязательно означает микросервисы. 5. Помните, тестирование сборки системы важно, но тестирование развёртывания системы едва ли не важнее. 6. Организуйте команду из людей, которые занимаются всеми аспектами системы. Да, может быть разделение на фронт и бэк, но все специалисты должны чётко представлять, какой продукт должен получиться. «Люди думают об архитектуре как о чертежах, красивых диаграммах и т. д.», — говорит Пюрер. - «Да, у вас должны быть эти вещи, с помощью которых вы будете общаться, как часть архитектуры. Поскольку вы постоянно принимаете решения, вы будете учиться на своих ошибках, постоянно возвращаться и пересматривать свои решения». Источник: https://www.zdnet.com/article/agile-alertness-6-principles-to-help-your-software-design-process-succeed/