Перший тиждень на проєкті. Задача здається дрібною: додати поле в профіль користувача. Код написано за годину, тести зелені. А наступного ранку падає сервіс розсилок, про який тобі ніхто не розповідав.
Junior не вирішує, якою буде архітектура системи. Зате щодня працює всередині вже ухвалених рішень. І чим раніше стає зрозуміло, чому система влаштована саме так, тим менше таких ранків. Розберемось, чому Junior повинен розуміти архітектуру проєкту.
Що таке мікросервісна архітектура і де з нею стикається Junior
Мікросервісна архітектура ділить застосунок на невеликі сервіси, кожен з яких відповідає за свою частину бізнесу. Один сервіс веде замовлення, інший рахує оплату, третій надсилає сповіщення. Кожен мікросервіс має власний код, часто власну базу даних і розгортається окремо. Спілкуються вони через API (домовлений інтерфейс для запитів між програмами) або через брокер повідомлень.
Сам термін microservices закріпився після статті Мартіна Фаулера та Джеймса Льюїса 2014 року. В англомовних пошукових запитах його ще пишуть роздільно, micro services, але йдеться про те саме.
Junior стикається з цим не на рівні схем. Ти відкриваєш репозиторій одного сервісу і бачиш, що половина даних приходить звідкись ззовні. Задача звучить як зміна в одному місці, а зачіпає три.
Моноліт чи мікросервіси: чому команда взагалі обирає архітектуру
Що таке моноліт? Це застосунок, де вся логіка живе в одній кодовій базі й розгортається одним пакетом. Монолітна архітектура простіша на старті: один репозиторій, одна база, зрозумілий дебаг. Для невеликої команди з молодим продуктом це часто найрозумніший вибір.
Проблеми починаються з ростом. Двадцять розробників комітять в один код, реліз чекає, поки всі домовляться, а одне повільне місце гальмує весь застосунок. Тоді команда задумується про поділ.
Мікросервіси теж мають ціну: мережеві збої, складніше тестування, окремий моніторинг для кожного сервісу. Тому рішення залежить від масштабу продукту, розміру команди, навантаження і того, скільки людей зможе це підтримувати. Детальніше про плюси й мінуси обох підходів ми писали в порівнянні мікросервісної та монолітної архітектур.
Що змінюється в роботі Junior у мікросервісному проєкті
У моноліті можна зосередитися на своєму методі. IDE підсвітить усі місця, де його викликають, компілятор не дасть зламати сигнатуру. У мікросервісах цієї страховки немає. Інший сервіс викликає твій через мережу, і компілятор про нього нічого не знає.
Звідси нові обов’язки. Перед зміною API треба знати, хто ним користується. Поле, яке здається зайвим, може читати аналітика. Перейменування в JSON-відповіді ламає контракт (домовленість про формат даних між сервісами), навіть якщо твій код бездоганний.
Змінюється і дебаг. Помилка часто виникає не там, де проявляється. Користувач бачить збій у кошику, а причина в сервісі цін, який відповів із запізненням. Щоб знайти таке, доводиться читати логи кількох сервісів і розуміти, як запит проходить через систему. Звикнути до такої роботи найпростіше там, де помилка коштує дешево, наприклад на стажуванні на IT-проєкті.
Які архітектурні рішення Junior повинен навчитися помічати
Мелвін Конвей ще 1968 року помітив, що організації проєктують системи, які копіюють структуру їхніх комунікацій. Межі сервісів часто збігаються з межами команд, і це ключ до розуміння проєкту. Коли береш нову задачу, корисно відповісти собі на чотири питання:
- Хто відповідає за конкретні дані та бізнес-логіку? Якщо сервіс не власник даних, міняти їх напряму не можна, тільки через того, хто за них відповідає.
- Як сервіси взаємодіють між собою? Синхронний запит чекає відповіді, подія в черзі обробляється пізніше, і від цього залежить, що побачить користувач.
- Чому відповідальності розділені саме так? За кожною межею стоїть чиєсь рішення, і його причину варто знати.
- Що станеться з іншими компонентами після зміни коду? Хто читає ці дані, хто підписаний на цю подію.
Тут і з’являється зв’язок з основами. ООП, GRASP, SOLID та GoF вчать розподіляти відповідальності всередині сервісу. Мікросервіси ставлять те саме питання на рівні системи.
Чому знання патернів без розуміння архітектури недостатньо
Junior може розповісти про Factory, Adapter і Observer. На співбесіді це допомагає. На проєкті швидко з’ясовується, що назва патерну нічого не каже про те, навіщо його тут використали.
Візьмімо Adapter. У мікросервісах він часто стоїть на межі з зовнішнім сервісом і захищає твою логіку від чужого формату даних. Хто розуміє цю причину, той не протягне формат партнера вглиб свого коду. Хто знає лише назву, зробить адаптер і все одно передасть сирий об’єкт далі. Назва патерну тут другорядна. Важлива межа, яку він охороняє.
Професійне зростання починається з питання чому. Чому межа тут, чому ця залежність, чому саме такий шаблон. Як ООП, GRASP, SOLID та GoF складаються в одну систему, ми розбирали окремо, і саме це розуміння відрізняє Middle від Junior.
YouTube
Дивись на систему ширше за свою задачу ще до того, як стати Middle
Архітектурне мислення не з’явиться від самих лише книжок, але його можна тренувати вже зараз. Читай документацію проєкту і схеми взаємодії сервісів, навіть якщо вони трохи застаріли. Розбирай чужі pull requests і питай автора, чому обрано саме це рішення.
Ставити питання Senior чи Tech Lead нормально: кожна відповідь економить тобі тижні здогадок. Помічай, які компоненти залежать від коду, що ти змінюєш, і з часом у голові складеться карта системи.
Теоретичну основу дає книга Сергія Немчинського Фундамент архітектури, де ООП, GRASP, SOLID та GoF пояснені як одна система.
Junior, який бачить місце своєї задачі в системі, ламає менше і росте швидше. Наступну задачу почни з пошуку тих, кого вона зачепить.
