Проходим экзамен iSAQB CPSA Foundation Level Exam в 2018-м году

Это русская версия поста Passing iSAQB CPSA Foundation Level Exam in 2018, поэтому некоторые картинки и термины я оставил на английском, sorry.

Недавно я прошёл четырёхдневный тренинг, в конце которого сдавал экзамен
iSAQB CPSA Foundation Level Exam. CPSA здесь означает Certified Professional for Software Architecture.

Почему именно этот экзамен?

iSAQB — это организация, которая позиционирует себя как стандарт в области архитектуры приложений. Примерно на том же уровне, на котором сейчас Project Management Institute со стандартом PMBoK. Я специально не выбирал его, мне предложил пройти этот курс CTO компании, в которой я сейчас работаю — Netconomy.

Экзамен не привязан ни к какой технологии, типа Kubernetes, AWS, Oracle, а более сосредоточен на теоретических стандартах. iSAQB приводит график, что экзамен с годами набирает популярность.

https://www.isaqb.org/wp-content/uploads/2018/03/Folie2.jpg

Чему я научился?

Нагляднее всего результаты я бы изобразил так:

так что знания стали более структурированными

Чему ещё я научился?

Ещё я наконец-то разобрался, что должен делать архитектор, а куда лезть не должен. Вкратце, архитектору нужно постоянно бороться.

Бороться с клиентом по поводу не имеющих смысла требований.

Бороться с менеджером проекта, которому надо, чтобы «фича была готова на вчера, и у меня нету денег на этот ваш рефакторинг».

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

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

Темы курса

Базовые понятия

Определение, что такое архитектура программы. Обязанности архитектора. Разница между архитектурой программы и бизнес-архитектурой. Закон Конвея.

Значимые факторы

Функциональные требования и нефункциональные (требования качества). Ограничения (организационные, технические). Цели архитектуры (основная — чтобы продукт не развалился после многих лет изменений).

Создание и проработка архитектуры

От представления системного контекста к чёрному ящику к белому ящику. Приёмы, как изобразить ваши идеи и решения шаг за шагом от глобальной перспективы к деталям (файлы/классы). Объяснения, почему техническая архитектура перпендикулярна бизнес-архитектуре. Подходы сверху вниз и снизу вверх. Формализованные подходы: 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 (никак не связаны, просто имена совпали). Инструменты для генерации кода (хороших нет).

Все темы одной картинкой

Все темы (кликабельно)

Экзамен

Вы получаете 43 вопроса из довольно узкого пула (по ощущениям: 45-50 всего). Вопросы бывают двух типов.

Тип 1: «Вас назначили главным архитектором в проект с тремя командами. В каждой команде уже есть свой архитектор. Что может быть полезно сделать относительно архитектурной документации?»

[Полезно] [Не очень]
[] []
Создать корневую документацию и потребовать от команд следовать её структуре для документации подпроектов.
[] []
Разделить документацию на три части и оставить внутреннюю структуру на усмотрение каждой команды.
[] []
Подождать пока одна команда начнёт вести документацию и заставить остальные команды ей следовать
[] [ ]
Запретить использование текстовых редакторов, ибо из них нельзя генерировать код.

Тут у вас есть несколько утверждений и надо выбрать правильные и неправильные.

Тип 2: «Что из этого является шаблонами проектирования (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 человек из одной и той же компании, и если наложить наши результаты на график, получаем такую картинку:

Сверху кластер результатов 74-85% у трёх людей, которые работают архитекторами года по три, так что можно сказать, тест подтвердил это.

Дальше плотная группа с результатами 65-68%.

Два человека немного недобрали до 60%.

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

На самом деле

Ещё один момент в том, что экзамен и тренинг сейчас в очень бета-стадии. Термины меняются, целые разделы исчезают и уступают место другим. Через полгода пул вопросов может быть новым на 83%.

И да, я прошёл.


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *