Как я сдал iSAQB CPSA Foundation Level Exam и зачем он нужен разработчику
Меня зовут Руслан Беспалов, я работаю Java разработчиком в компании Netconomy в Граце, Австрия. Совсем недавно, в 2018 году, я прошёл четырёхдневный тренинг, в конце которого сдавал экзамен iSAQB CPSA Foundation Level Exam. CPSA здесь означает Certified Professional for Software Architecture. В статье я расскажу, что дает такой тренинг, чему там учат и как я его проходил.
Почему именно этот экзамен
iSAQB — это организация, которая позиционирует себя как стандарт в области архитектуры приложений. Примерно на том же уровне, на котором сейчас Project Management Institute со стандартом PMBoK. Я специально не выбирал этот курс, мне предложил его пройти CTO моей компании.
Экзамен не привязан ни к какой технологии, в отличие от аналогов от Kubernetes, AWS и Oracle, а более сосредоточен на теоретических стандартах. iSAQB приводит график, что экзамен с годами набирает популярность:
Для нас курс проводила австрийская компания Software Quality Lab. Есть несколько компаний, проводящих тренинг, правда, сосредоточены они в основном в немецкоговорящих странах. Тренинг, экзамен и материалы у нас были на английском, бонусом мы получили бумажный экземпляр «Clean Architecture» Роберта С. Мартина.
Стоимость тренинга + экзамена «под ключ» —
Чему я научился
Нагляднее всего результаты я бы изобразил так:
Знаний не стало больше, но они стали более структурированными.
Ещё я наконец-то разобрался, что должен делать архитектор, а куда лезть не должен. Вкратце, архитектору нужно постоянно бороться.
Бороться с клиентом по поводу не имеющих смысла требований.
Бороться с менеджером проекта, которому надо, чтобы «фича была готова на вчера, и у меня нету денег на этот ваш рефакторинг».
Бороться с разработчиками, привыкшими работать без документации, тратить кучу времени на простые изменения и от этого быть постоянно демотивированными.
На самом деле не всё так плохо. По крайней мере, вы изучите способы изображать и доносить до людей архитектуру (кстати, это ваша обязанность нумеро уно) и узнаете стандарты, на которые можно ссылаться. По итогу вы сможете успешнее выбивать бюджет на работу.
Темы курса
Базовые понятия
Определение, что такое архитектура программы. Обязанности архитектора. Разница между архитектурой программы и бизнес-архитектурой. Закон Конвея.
Значимые факторы
Функциональные требования и нефункциональные (требования качества). Ограничения (организационные, технические). Цели архитектуры (основная — чтобы продукт не развалился после многих лет изменений).
Создание и проработка архитектуры
От представления системного контекста к чёрному ящику к белому ящику. Приёмы, как изобразить ваши идеи и решения шаг за шагом от глобальной перспективы к деталям (файлы/классы). Объяснения, почему техническая архитектура перпендикулярна бизнес-архитектуре. Подходы сверху вниз и снизу вверх. Формализованные подходы: DDD, Model-Driven Architecture, Reference Architectures (копируем архитектуру из похожего проекта). Основной посыл — узнать, какими стандартными языками и метафорами можно описать то, что вы собираетесь создать и так, чтобы вы не изобретали велосипедов.
Шаблоны архитектуры и шаблоны проектирования
- Архитектурные: MVC/MVVM, Master-Slave, Client/Server, RPC.
- Шаблоны проектирования: Facade, Adapter, Factory — ну вы знаете.
Интерфейсы и зависимости
Итак, вы с горем пополам описали блоки, как бы теперь описать связи между ними? Типы зависимостей (например, по времени, когда внутренний сервис ждёт, пока внешний сервис что-то выполнит, и вешает всю систему). Принципы SOLID.
Cквозные проблемы
Тут вам нужно знать, что это за ерунда и как они влияют на архитектуру. Журналирование, обработка ошибок, безопасность, пользовательский интерфейс. Это то, чего вы никогда не найдёте в спецификации от клиента (ибо им пофиг) и это то, что вам нужно активно пробивать.
Управление рисками
Сюрприз! Это теперь часть вашей работы. Курите FMEA. Дальше!
Спецификация и коммуникация
Свойства хорошей технической документации. Не забывать подгонять документацию к каждому классу читателей. Представление контекста → Представление структурных блоков → Процесс работы (диаграммы активностей, состояния) → Представление развертывания (для нердов). Короче, опять UML диаграммы, потому что ничего лучше нету.
Архитектура программ и качество
Модели качества (де-факто ISO 25010). Метрики качества: количество строк кода (гы-гы), цикломатическая сложность и прочая пурга. Качественные методы: ATAM («А там у них за бугром лучше»), деревья качества. Большой упор на то, как оценить количество говнокода, созданное командой разработчиков за многие годы.
Инструменты
Последняя тема. SonarQube, Sonargraph (никак не связаны, просто имена совпали). Инструменты для генерации кода (хороших нет).
Все темы одной картинкой
Упражнения
Самой интересной частью тренинга были упражнения. Нас разбили на группы по три человека и дали юз-кейсы от клиента для проекта.
Тема у нас была «Маркетплейс инструментов». Мол, у каждого дома валяется дрель и молоток, давайте создадим возможность их сдавать в аренду, искать инструменты поблизости, а ещё предусмотрим интеграцию с бизнес-клиентами — магазинами инструментов.
Упражнения перемежались с теорией, так что у нас было по два упражнения в день. Надо было сначала изобразить систему в контексте («чёрный ящик»), потом нарисовать компоненты и связи внутри («белый ящик»), потом изобразить диаграмму развёртывания и в конце сделать оценку рисков по FMEA.
Своё решение надо было презентовать и защищать перед другими командами. Хорошая практика перед реальной жизнью.
Экзамен
Вы получаете 43 вопроса из довольно узкого пула (по ощущениям:
Тип 1. Вас назначили главным архитектором в проект с тремя командами. В каждой команде уже есть свой архитектор. Что может быть полезно сделать относительно архитектурной документации?
- Создать корневую документацию и потребовать от команд следовать её структуре для документации подпроектов.
- Разделить документацию на три части и оставить внутреннюю структуру на усмотрение каждой команды.
- Подождать, пока одна команда начнёт вести документацию и заставить остальные команды ей следовать.
- Запретить использование текстовых редакторов, ибо из них нельзя генерировать код.
Тут у вас есть несколько утверждений, и надо выбрать правильные и неправильные.
Тип 2. Что из этого является шаблонами проектирования?
- Facade
- Observer
- Window
- Tube
- Machine
Тут вы можете выбрать 0, 1 или 2 варианта.
Подсчёт баллов
Подсчёт весьма интересный. Для каждого вопроса указывается максимум: 1 или 2 балла. Если вы отвечаете абсолютно верно, получаете максимум. Иначе — получаете какую-то промежуточную долю между 0 и максимумом. Учтите, что неправильный ответ на утверждение засчитывается со знаком «-».
Например, если для вопроса про шаблоны максимум указан как 1, вы получаете баллы таким образом:
- Facade, Observer = 1 балл
- Facade = 0.5 (1 из 2)
- Facade, Tube = 0 (+0.5 — 0.5)
- Machine, Tube = 0 (меньше 0 получить нельзя)
Основная проблема с ответами, что многие из них весьма противоречивы, не упомянуты на тренинге или составлены из весьма сомнительных фраз. Особенно это обидно, когда получаешь результат: «Вы набрали 59.85% баллов от максимума. Необходимо набрать 60%. К сожалению, вы не прошли».
Один из вопросов у меня звучал примерно так: «В роли архитектора ваша задача — найти подходящие инструменты для документации архитектуры. Какие характеристики инструментов были бы полезными?».
- Поддержка UML 2.0 и SysML
- Цена за лицензию
- Поддержка нескольких пользователей
- Генерация кода
- Трансформация моделей для поддержки подготовки генерации кода
Первый же вопрос — что за SysML? Я этого не знал, отметил характеристику как бесполезную. Оказывается это разновидность UML. Так что, наверное, правильный ответ был: полезно. Или генерация кода — сама по себе полезна, но что за «трансформация моделей для поддержки подготовки генерации кода». Термин не фигурировал в тренинге.
Да я даже не знаю правильный ответ на вопрос про три команды. Так что лучшая стратегия — помечать ответы только там, где точно уверен, и пропускать остальное. Если пожадничать, то:
И вы правильно поняли: проходной балл — 60%.
Итого
Советовал бы я пройти тренинг? Наверняка. Он добавит уверенности в тех вещах, которые вы уже делаете, и подскажет, где можно свою работу улучшить. Помните, архитектор ПО — это не про написание рабочего кода.
Принимать ли результаты экзамена всерьёз? Думаю, нет. В нашей группе было 9 человек из одной и той же компании, и если наложить наши результаты на график, получаем такую картинку:
Сверху кластер результатов
Дальше плотная группа с результатами
Два человека немного недобрали до 60%.
То есть делить людей по тому, прошли они экзамен или нет, смысла нет. Есть смысл выпендриваться перед коллегами, говоря, что вы набрали баллов намного больше них.
Ещё один момент в том, что экзамен и тренинг сейчас в очень бета-стадии. Термины меняются, целые разделы исчезают и уступают место другим, а через полгода пул вопросов может быть новым на 83%.
И да, я прошёл.
