Є старий жарт про картографа, якого попросили зробити ідеально точну мапу королівства. Він довго працював і зрештою створив мапу в масштабі один до одного. Вона вкривала все королівство цілком, була абсолютно точною і геть марною. Я згадую цю історію щоразу, коли бачу технічне завдання на триста сторінок, у якому описано все, крім головного. Складний світ не можна зрозуміти, повторивши його. Його можна зрозуміти, лише спростивши. І ось тут починається мистецтво моделювання.
Модель це свідоме спрощення
Будь-яка програмна система це модель. Вона не дорівнює бізнесу, вона його спрощене відображення. На справжньому складі є запах картону, протяг від воріт, комірник, який знає, що верхня полиця хитається. У моделі складу є комірки, товари, залишки й рухи. Усе інше ми свідомо відкидаємо, бо для управління воно не потрібне.
Майстерність тут у виборі: що залишити, а що відкинути. Відкинете забагато, і модель перестане відображати реальність, система рахуватиме одне, а на складі буде інше. Залишите забагато, і вийде та сама мапа в масштабі один до одного: громіздка, дорога й незрозуміла. Добра модель схожа на схему метро. Вона не показує справжніх відстаней і вигинів тунелів, але за нею неможливо заблукати, бо вона показує саме те, що потрібно пасажирові.
Модель добра не тоді, коли в ній усе є, а тоді, коли в ній немає нічого зайвого і є все необхідне.
Єдиний спосіб зрозуміти складне
Людський мозок утримує в голові одночасно зовсім небагато речей. Психологи сперечаються про точне число, але всі сходяться в тому, що це одиниці, а не сотні. А сучасна облікова система складається із сотень сутностей, тисяч правил і десятків тисяч рядків коду. Зрозуміти таку систему цілком неможливо. Ні мені, ні будь-якому іншому архітекторові. Єдиний спосіб із нею працювати це розбити її на частини, кожну з яких можна зрозуміти окремо.
Так влаштована будь-яка складна річ, створена людиною. Літак не проєктує один інженер: є команда двигуна, команда крила, команда електроніки, і кожна працює зі своїм модулем, знаючи лише інтерфейси, якими він стикується із сусідами. Містом не керує одна людина: є райони, служби, відомства. Модульність не модне слово з програмування, це спосіб, яким людство взагалі дає раду складності.
Що робить модуль добрим
У програмуванні є два принципи, які я вважаю майже законами природи. Перший: слабка звʼязність. Модулі мають якомога менше знати один про одного й спілкуватися через невеликі зрозумілі інтерфейси. Модуль продажу не повинен лізти в нутрощі складу, він має попросити склад зарезервувати товар і отримати відповідь. Тоді склад можна переробити зсередини, і продажі цього навіть не помітять.
Другий: висока зчепленість. Усе, що стосується одного завдання, має жити в одному модулі. Якщо логіку розрахунку знижок розмазано по пʼяти різних місцях системи, то будь-яка зміна правил знижок перетворюється на полювання за цими шматочками, і один обовʼязково буде пропущено.
- Добрий модуль можна пояснити одним реченням: «цей модуль відповідає за складські залишки».
- Добрий модуль можна змінити, не чіпаючи інших.
- Добрий модуль можна протестувати окремо.
- Над добрим модулем може працювати окрема команда, не заважаючи решті.
Останній пункт особливо важливий для бізнесу. Коли система модульна, команда розробки може працювати паралельно: одні роблять новий звіт, інші інтеграцію з доставкою, треті переробляють права доступу, і ніхто не стоїть у черзі за чужим кодом. Швидкість розвитку системи зростає не тому, що люди працюють швидше, а тому, що вони перестають заважати одне одному.
Де проходять межі
Найважче питання в модульності не «чи треба ділити», а «де різати». І тут я завжди раджу дивитися не на техніку, а на бізнес. Межі модулів мають повторювати межі реальних сфер відповідальності в компанії. Продажі, склад, закупівлі, фінанси, персонал. Якщо в компанії є відділ, який за щось відповідає, найпевніше, у системі має бути модуль, який відповідає за те саме. Тоді зміни в бізнесі природно лягають на зміни в одному модулі, а не розповзаються всією системою.
Помилка, яку я бачу часто: ділити систему за технічними шарами, а не за змістом. Окремо всі екрани, окремо вся логіка, окремо всі дані. Виглядає охайно, але будь-яка зміна бізнес-правила потребує правки в усіх трьох місцях. Це як поділити оркестр не на інструменти, а на «усі, хто грає голосно» і «усі, хто грає тихо».
Що робити завтра
Намалюйте свою систему або ту, яку збираєтеся будувати, як набір блоків. Для кожного блоку напишіть одне речення про те, за що він відповідає. Якщо речення не виходить, блок завеликий або надто розмитий. Потім намалюйте стрілки між блоками. Якщо стрілок забагато і вони йдуть на всі боки, модулі надто сильно повʼязані, і будь-яка зміна буде болісною.
Модульність закладено в основу всього, що ми робимо в Ingello. Forma влаштована як набір модулів, кожен з яких відповідає за свою сферу: продажі, склад, закупівлі, найм, проєкти. Fractal описує систему моделями з явними звʼязками, і межі модулів видно в описі ще до генерації коду. А в Systems ми починаємо проєктування саме з того, щоб знайти правильні лінії розрізу. Складність світу нікуди не зникне. Але її можна розкласти по поличках так, що кожна поличка стане зрозумілою.
