Я живу в одному з передмість Тель-Авіва. Якось я прокинувся від шаленої буркотливої роботи свердла. Розпочалося! Почалися будівельні роботи зі зведення фіолетової гілки легкого метро. "Як сильно це вплине на наше життя?" — подумав я...
Минуло кілька тижнів, і я час від часу прокидався о 5 ранку, залежно від того, коли починали будівельні роботи. Моя дружина сказала, що настав час нам переїхати. Відчайдушно намагаючись довести, що ми маємо залишитися (я люблю цей район!), я вирішив знайти плани будівництва, припускаючи, що буріння не триватиме довго.
Коли я переглянув плани будівництва, то як програміст був вражений. У них були детальні, конкретні плани на наступні 3 роки. Плани поділялися на 3 етапи, з точними вимірюваннями та дорожніми структурами для кожного з них. У них був чіткий графік.
І найцікавіше — я зміг легко розібратися в цьому, і все було зрозуміло, хоча я абсолютно нічого не знаю про цивільне будівництво.
Насправді це стосується й інших видів інженерії чи архітектури. Подумайте про діаграми архітектури будинків, електротехніки або механічної інженерії — існують послідовні способи їх написання, щоб усі інші інженери в цій галузі могли це зрозуміти.
Але це не стосується розробки програмного забезпечення (Software Engineering).
Хоча створювати діаграми архітектури програмного забезпечення (Software Architecture Diagrams) досить просто (використовуючи блоки та стрілки), їх читання та розуміння можуть бути не такими очевидними.
Джерело: DALL·E Prompt: Ілюстрація 4 типів інженерів: інженер-програміст (Software Engineer), електротехнік (Electrical Engineer), цивільний інженер (Civil Engineer) та інженер-механік (Mechanical Engineer).
Різниця в розробці програмного забезпечення
Протягом моєї кар’єри інженера я створив, прочитав і переглянув безліч діаграм архітектури програмного забезпечення (Software Architecture Diagrams) та документації з проєктування (Design Docs), а також провів багато співбесід із системного проєктування (System Design Interviews).
Я зрозумів, що люди описують програмне забезпечення дуже по-різному.
"По-різному" означає:
- Різні рівні абстракції
- Різні рівні деталізації
- Різні методи ілюстрації/створення діаграм
- Різний акцент на нефункціональних аспектах, таких як надійність, безпека, конфіденційність та масштабованість
Цілком звичайно зустрічати такі комунікаційні розриви навіть у межах однієї команди, не кажучи вже про різні команди, організації чи компанії. Ці розриви проявляються, наприклад, у діаграмах архітектури, які не є самодостатніми. Вони або супроводжуються значним обсягом тексту (наприклад, 10-сторінковий документ проєктування — Design Doc), або потребують багато часу на пояснення.
Діаграми архітектури на білій дошці (Whiteboard Architecture Diagrams).
Джерело: c4model.com
Ці комунікаційні розриви стають ще більш значущими через останню тенденцію в світі розробки програмного забезпечення (Software Engineering).
Децентралізація ролі архітектора
"Архітектура як командний спорт:
Архітектори більше не працюють самостійно, і архітектори вже не можуть думати лише про технічні аспекти. Роль архітектора значно відрізняється в різних компаніях, і деякі компанії повністю скасували цей титул…"InfoQ Software Architecture and Design Trends Report — квітень 2023
У минулому більшість компаній та організацій реалізовували підхід зверху вниз до проєктування програмного забезпечення та архітектури — наймаючи архітектора для кожної досить великої групи, який діяв як центральний авторитет у проєктуванні продукту/системи.
Зазвичай інженери виконували завдання з написання коду на основі наданої архітектури, специфікації та API (Application Programming Interface).
Світ перейшов до більш децентралізованого підходу, де інженери на всіх рівнях тепер беруть участь у проєктуванні та архітектурі, а не лише у написанні коду.
Те, що відрізняється між різними рівнями та навичками інженерів, — це обсяг їхньої роботи. Наприклад, молодші інженери можуть проєктувати окремий компонент, тоді як більш досвідчені інженери можуть проєктувати систему або середовище з кількох систем.
Фактично, це культурний та ментальний зсув від централізованого процесу проєктування зверху вниз до децентралізованого процесу знизу вгору, який "належить усім".
Вартість
Ця зміна має багато переваг: підсилення та розвиток інженерів на всіх рівнях, підвищення почуття відповідальності та залученості, усунення єдиної точки відмови та кращий розподіл знань між командами.
Однак вона також має свою ціну:
- Якість: архітектор зазвичай кваліфікується як досвідчений інженер із великим досвідом у створенні та підтримці програмних систем. Розподіл цієї роботи між усіма членами команди означає, що немає додаткових кваліфікацій, окрім участі в команді.
Щоб підтримувати високий рівень якості, командам потрібно інвестувати в навчання, освіту та наставництво, створювати якісний процес проєктування та впроваджувати культуру відкритого зворотного зв’язку.
- Додаткове навантаження: наявність чіткого процесу проєктування в організації допомагає підвищити рівень якості, але додає значне навантаження. Зазвичай такі процеси включають створення документації з проєктування (Design Document), діаграм систем (System Diagrams), блок-схем (Flow Charts), а також процес зворотного зв’язку, який може вимагати кількох ітерацій і повторних перевірок дизайну.
Реалізація здорового процесу проєктування в організації є викликом. Існує напруга між додатковим навантаженням, яке він створює, та рівнем якості, що досягається завдяки цьому процесу. Якщо процес надто легкий або взагалі відсутній, якість не зростає. Якщо процес надто складний, він може стати обтяжливим для інженерів, які можуть не дотримуватися його повністю або навіть намагатися обійти його — що в кінцевому результаті призводить до зниження ефективності.
Оптимальна точка знаходиться десь посередині, як завжди.
Існує напруга між додатковим навантаженням, яке створює процес проєктування, та досягнутим рівнем якості. Якщо процесу немає зовсім, немає й покращення. Якщо процес занадто складний, інженери будуть його обходити, і покращення зменшиться. Оптимальна точка знаходиться десь посередині.
Практичний висновок: Модель C4
Є багато аспектів, про які варто говорити, коли йдеться про те, як має виглядати здоровий процес проєктування, але одна практична концепція, яку я хочу виділити, — це модель C4.
Візуалізації — ключова частина у проєктуванні програмного забезпечення (Software Design). Як зазначалося раніше, люди описують програмне забезпечення дуже по-різному, особливо коли йдеться про діаграми програмного забезпечення.
Діаграмування → Моделювання
Модель C4 спрямована на те, щоб перетворити короткочасні, довільні техніки створення діаграм на тривалі, канонічні та стандартизовані техніки моделювання.
Ви можете уявити це як набір правил і конвенцій щодо того, як архітектура програмного забезпечення (Software Architecture) має бути візуалізована та описана (схоже на стандарти, які існують в інших інженерних галузях).
Джерело: c4model.com. Для повного прикладу відвідайте вебсайт.
Модель C4 складається з 4 рівнів абстракції (звідси і назва):
- Контекст системи (System Context): найвищий рівень абстракції. Цей рівень містить внутрішні системи, зовнішні системи, користувачів (якщо є кілька типів користувачів, їх слід зазначити) та взаємозв’язки між цими трьома компонентами.
- Контейнер (Container): після того як ваші системи визначені, можна детальніше розглянути конкретну систему. Система складається з одного або кількох контейнерів. Контейнер представляє додаток або сховище даних, наприклад: бекенд-сервіс (Backend Service), фронтенд-додаток (Frontend Application), мобільний додаток, реляційну базу даних (Relational DB), сховище ключ-значення (Key-Value Store), шину повідомлень (Message Bus), об'єктне сховище (Object Storage) тощо.
Простий спосіб уявити це, принаймні з точки зору бекенду (Backend), — це розглядати окремі процеси/виконувані файли. Кожен виконуваний файл відповідає своєму контейнеру.
Якщо ви коли-небудь проходили співбесіду з проєктування систем (System Design Interview), то вона зазвичай зосереджується на рівні контейнерів.
- Компонент (Component): далі контейнер може бути розбитий на кілька компонентів, зазвичай за функціональністю та зонами відповідальності. Наприклад, якщо ми візьмемо бекенд-сервіс для обробки платежів, він може включати такі компоненти, як: виконавець платежів (Payment Executor), клієнт для роботи зі сторонніми сервісами (3rd Party Client), механізм відновлення (Recovery Mechanism), реєстратор платежів (Payment Recorder), відправник сповіщень (Notification Sender) тощо.
Цілком нормально, що компоненти контейнера можуть взаємодіяти з іншими контейнерами з рівня 2. Наприклад, механізм відновлення може надсилати повідомлення до шини повідомлень (Message Bus) для повторної спроби виконання невдалого платежу через певну затримку.
- Код (Code): це відображення компонентів у реальні класи, модулі або інші частини коду.
Цей рівень деталей реалізації зазвичай менш цікавий і дуже складний у підтримці, тому загалом не рекомендується для більшості випадків використання.
Однак під час написання коду корисно задуматися: “До якого компонента належить мій код?_”; якщо відповідь не очевидна, ви або створюєте новий компонент, або порушуєте існуючі межі компонентів.
Кілька приміток щодо моделі C4:
-
Контейнер і компонент — це критичні рівні. Чітке визначення суті цих рівнів є важливим: ваші рішення на рівні контейнера впливають на масштабованість, надійність, розгортання та еволюційність системи.
Ваші рішення на рівні компонента впливають на швидкість розробки (Developer Velocity), ефективність, підтримуваність та якість. -
Модель C4 додає глибини до діаграм архітектури програмного забезпечення. Уявіть її як онлайн-карту: ви починаєте з високорівневого огляду та можете "наблизити" деталі в місцях, що вас цікавлять.
Якщо ви занадто заглибилися в деталі, ви можете знову "віддалитися" та повернутися до загальної архітектури.
- Модель C4 — це спільна, довгострокова модель. Замість того, щоб кожен інженер створював свої власні випадкові діаграми, модель C4 може бути спільно використана й опрацьована кількома інженерами або командами, розширюючись у міру зростання організації та продукту.
- Існує багато інструментів, що підтримують модель C4.
Сьогодні навіть звичайне корпоративне програмне забезпечення для створення діаграм має шаблон для моделі C4.
Висновок
Проєктування програмного забезпечення (Software Design) є критично важливою частиною життєвого циклу розробки програмного забезпечення (Software Development Lifecycle) і має значний вплив на кінцевий результат продукту або системи, швидкість виконання, підтримуваність і еволюційність.
З огляду на останні тенденції щодо децентралізації ролі архітектора та впровадження підходу "архітектура як командний спорт", структура команд розробників змінюється, і організаціям потрібно ретельно продумати, як має виглядати їхній процес проєктування, а також знайти баланс між додатковим навантаженням і підтриманням високого рівня якості.
Ще одне цікаве питання — як GenAI вплине на розробку програмного забезпечення та проєктування у довгостроковій перспективі.
Ми вже спостерігаємо зміни в щоденній роботі інженерів із впровадженням інструментів на основі штучного інтелекту (AI), ко-пілотів (Co-Pilots) та агентів (Agents).
Як виглядає процес проєктування у вашій організації? Чи вважаєте ви його добре структурованим і впливовим? Чи, можливо, є місце для вдосконалення? Буду радий почути ваші думки в коментарях нижче.
Перекладено з: Software Architecture is Hard