Як я здав 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» Роберта С. Мартіна.

Вартість тренінгу + іспиту «під ключ» — 1600-2000 євро на людину. Сам іспит — 250 євро.

Чого я навчився

Наочно результати я б зобразив так:

Знань не стало більше, але вони стали більш структурованими.

Ще я нарешті розібрався, що повинен робити архітектор, а куди лізти не має. Коротенько, архітектору потрібно постійно боротися.

Боротися з клієнтом з приводу не мають сенсу вимог.

Боротися з менеджером проекту, якому треба, щоб «фіча була готова на вчора, і у мене немає грошей на цей ваш рефакторинг».

Боротися з розробниками, які звикли працювати без документації, витрачати купу часу на прості зміни і від цього бути постійно демотивированными.

Насправді не все так погано. Принаймні, ви вивчіть способи зображати і доносити до людей архітектуру (до речі, це ваш обов'язок нумеро уно) і дізнаєтеся стандарти, на які можна посилатися. За підсумком ви зможете успішніше вибивати бюджет на роботу.

Теми курсу

Базові поняття

Визначення, що таке архітектура програми. Обов'язки архітектора. Різниця між архітектурою програми і бізнес-архітектурою. Закон Конвея.

Значущі фактори

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

Створення і опрацювання архітектури

Від подання системного контекстудо чорного ящикадо білого ящика. Прийоми, як зобразити ваші ідеї та рішення крок за кроком від глобальної перспективи до деталей (файли/класи). Пояснення, чому технічна архітектура перпендикулярна бізнес-архітектурі. Підходи зверху внизі знизу вгору. Формалізовані підходи: DDD, Model-Driven Architecture, Reference Architectures (копіюємо архітектуру схожого проекту). Основний посил — дізнатися, якими стандартними мовами і метафорами можна описати те, що ви збираєтеся створити і так, щоб ви не винаходили велосипеда.

Шаблони архітектури та шаблони проектування

Архітектурні: MVC/MVVM, Master-Slave, Client/Server, RPC.
Шаблони проектування: Facade, Adapter, Factory — ну ви знаєте.

Інтерфейси і залежності

Отже, ви з горем навпіл описали блоки, як би тепер описати зв'язки між ними? Типи залежностей (наприклад, з часу, коли внутрішній сервіс чекає, поки зовнішній сервіс щось виконає, і вішає всю систему). Принципи SOLID .

Наскрізні проблеми

Тут вам потрібно знати, що це за нісенітниця і як вони впливають на архітектуру. Облік, обробка помилок, безпека, користувальницький інтерфейс. Це те, чого ви ніколи не знайдете в специфікації від клієнта (бо їм пофіг) і це те, що вам потрібно активно пробивати.

Управління ризиками

Сюрприз! Це тепер частина вашої роботи. Паліть FMEA . Далі!

Специфікація і комунікація

Властивості хорошою технічної документації. Не забувати підганяти документацію до кожного класу читачів. Подання контексту ? Подання структурних блоків ? Процес роботи (діаграми активностей, стану) ? Подання розгортання (для нердов). Коротше, знову UML діаграми, тому що нічого кращого немає.

Архітектура програм і якість

Моделі якості (де-факто ISO 25010 ). Показники якості: кількість рядків коду (ги-ги), цикломатическая складність та інша пурга. Якісні методи: ATAM («А там у них за бугром краще»), дерева якості. Великий упор на те, як оцінити кількість говнокода, створений командою розробників за багато років.

Інструменти

Остання тема. SonarQube, Sonargraph (ніяк не пов'язані, просто імена співпали). Інструменти для генерації коду (хороших немає).

Всі теми однією картинкою

Вправи

Найцікавішою частиною тренінгу були вправи. Нас розбили на групи по три людини і дали юз-кейси від клієнта для проекту.

Тема у нас була «Маркетплейс інструментів». Мовляв, у кожного вдома валяється дриль і молоток, давайте створимо можливість здавати їх в оренду, шукати інструменти поблизу, а ще передбачимо інтеграцію з бізнес-клієнтами — магазинами інструментів.

Вправи чергувалися з теорією, так що у нас було по два вправи в день. Треба було спочатку зобразити систему в контексті («чорний ящик»), потім намалювати компоненти і зв'язки всередині («білий ящик»), потім зобразити діаграму розгортання і в кінці зробити оцінку ризиків по FMEA.

Своє рішення треба було презентувати і захищати перед іншими командами. Хороша практика перед реальним життям.

Іспит

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

Тип 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 чоловік з однієї і тієї ж компанії, і якщо накласти наші результати на графік, отримуємо таку картинку:

Зверху кластер результатів 74-85% у трьох людей, які працюють архітекторами року по три, так що можна сказати, тест підтвердив це.

Далі щільна група з результатами 65-68%.

Дві людини трохи недобрали до 60%.

Тобто ділити людей за того, вони пройшли іспит чи ні, сенсу немає. Є сенс випендрюватися перед колегами, кажучи, що ви набрали балів набагато більше за них.

Ще один момент у тому, що іспит і тренінг зараз в дуже бета-стадії. Терміни змінюються, цілі розділи зникають і поступаються місцем іншим, а через півроку пул питань може бути новим на 83%.

І так, я пройшов.

Опубліковано: 17/01/19 @ 11:38
Розділ Різне

SEO Блог