#longread #php #symfony #magento #architecture #cleancode
🚀 Він йшов у моноліт на Magento, а потрапив у SOA на Symfony
або Чому я забрав Magento-розробника в команду мікросервісів?

Нещодавно проводив співбесіду на позицію Magento Backend Developer. Прийшов молодий хлопець із приблизно 2,5 роками комерційного досвіду, переважно на Magento 2. Звичайна, здавалося б, співбесіда. Але в процесі розмови я зрозумів, що в команді Magento-розробників йому немає чого робити.

І справа не в знанні Magento чи інших технологій. Із технічною базою там усе добре, він навіть встиг мігрувати Magento на PHP 8.4.

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

За понад 10 років проведення технічних співбесід я можу пригадати лише три випадки, коли рівень архітектурного мислення кандидата настільки помітно випереджав його практичний досвід.

І тут виникла цікава ситуація. Хлопець прийшов працювати з Magento, а я вирішив забрати його в команду розробки мікросервісів на Symfony, попри те, що досвіду із Symfony в нього практично немає.

Чому?
Бо Symfony можна вивчити. Його компоненти, DI-контейнер, Messenger, Doctrine та інші інструменти — це питання часу й практики. А от архітектурне мислення, здатність бачити систему цілісно, розуміти межі відповідальності та оцінювати наслідки технічних рішень — це значно фундаментальніші навички.

Звісно, це певний ризик, тому в процесі його адаптації та навчання він буде мати технічний супровід.
А щоб перехід був максимально швидким, ми розробили для нього експрескурс "Із Magento на Symfony".
Не посилання на документацію, а матеріал, який допомагає переосмислити знайомі концепції Magento через архітектуру Symfony.

Хто навчався на моїх курсах, напевно пам'ятає один із моїх основних підходів до викладання: складні речі ми розкладаємо на прості поняття, а нові концепції пояснюємо через те, що вже знайоме.

Так влаштований мозок: нові знання легше засвоювати, пов'язуючи їх з уже відомими поняттями.

Саме за цим принципом ми й побудували курс: не вчимо Symfony з чистого аркуша, а показуємо, як уже знайомі Magento-розробнику концепції реалізовані в іншій екосистемі, де вони схожі, а де принципово відрізняються.

Частину цього матеріалу я вирішив опублікувати на своєму сайті цілим пулом статей:
📖 Magento → Symfony: перехід для Backend Developer

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

У Magento ми працюємо всередині вже сформованої системи: модулі, service contracts, repositories, plugins, observers, dependency injection — усе має своє місце та визначені механізми взаємодії.

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

Можна побудувати моноліт або мікросервіси, застосувати DDD, Hexagonal Architecture чи простішу структуру.
І жоден із цих варіантів не стане правильним лише тому, що ми використали Symfony.

Свобода архітектурних рішень передбачає відповідальність за їхні наслідки.

Саме тому для мене набагато важливіше, щоб розробник розумів принципи проєктування систем, ніж знав напам'ять конфігурацію конкретного фреймворку.

Якщо тема переходу з Magento на Symfony цікава — запрошую до статті.
Там розбираємо знайомі Magento-розробникам концепції, їхні відповідники у Symfony та принципові архітектурні відмінності.

А головна думка, яку хотів донести цією історією, проста:
Не плутайте знання інструмента з інженерною компетентністю.

Іноді найкращий кандидат на вакансію — це людина, яка ще не знає вашого технологічного стеку.
———
P. S. Знаю, що ти це читаєш, тому не зазнавайся. Поки що це лише шанс!

😉