Передмова: Чому ця книга існує і як її читати

Вітаю, мої дорогі!

Спочатку про те, хто я такий і чому взагалі маю право розповідати вам про архітектуру. Мене звати Сергій Немчинський. І я в айтішці з 1996 року, відколи закінчив університет. З того часу я багато де встиг попрацювати — від дрібних контор до топових українських аутсорсерів та продуктових гігантів, серед яких ЛІГА, Luxoft, Ciklum, Netcracker, IntroPro.

Я пройшов майже всі можливі ролі. Був наймолодшим керівником відділу в ЛІГА:ЗАКОН (до речі, перша пристойна версія їхнього порталу на початку 2000-х писалася саме під моїм керівництвом). Був проєктним менеджером у Ciklum, архітектором у Luxoft і тімлідом майже в кожній із цих компаній. Тому процес розробки я бачив і з «окопів» програміста, і з крісла стратега, і з позиції бізнесу.

Впродовж усієї цієї кар’єри я проводив технічні співбесіди та нерідко викладав у корпоративних навчальних центрах. І десь у 2015-2016 роках, коли до мене на співбесіди почали масово приходити випускники різноманітних ІТ-курсів, я з жахом усвідомив, що вони… майже нічого не знають.

Коли я запитував: «А що ж ви вивчали на ваших курсах?», вони з гордістю відповідали: «Ми робили бульбашкове сортування й рахували числа Фібоначчі!». Але варто було запитати: «А Spring у вас був?», як новачки «сипались» і робили при цьому круглі очі: «Ні, а що таке Spring?». Мене це дико бісило.

А все тому, що ці курси за три місяці намагалися втиснути цілу п’ятирічну університетську програму, викидаючи при цьому все те, що реально потрібно програмісту на роботі: фреймворки, патерни, enterprise-підходи. Я хапався за голову і врешті-решт вирішив: «Все, досить цієї дичини. Я буду навчати сам». Так у 2016 році з’явилася компанія FoxmindEd, яка успішно навчила вже багато тисяч спеціалістів.

Окрім навчання новачків, ми створюємо серйозні програми для мідлів та сеньйорів. Зокрема я особисто ще з 2008 року викладаю теорію базової архітектури (GRASP та GoF Design Patterns) — саме цей курс і ліг в основу книги, яку ви зараз читаєте. Згодом я додав до програм просунутий курс з enterprise-патернів (про нього планую написати наступну книгу), а також курс «Ефективний тімлід». Спостерігаючи за своїми студентами та за індустрією загалом, я зрозумів, що сучасна освіта для досвідчених розробників має три фундаментальні проблеми. Які мене люто дратують.

Якщо сучасний програміст хоче розібратися в архітектурі, то запросто відкриє для себе аж цілу гору книжок: від класичної «Банди Чотирьох» до новинок, що виходять ледь не щотижня. Але всі вони «хворіють знаннями у вакуумі».

Проблема в тому, що ці книжки розповідають про архітектурні концепції ізольовано одна від одної. Якщо книжка про SOLID, вона жодним словом не згадає про GoF-патерни, ніби їх не існує. Якщо ж це книжка про GRASP, то, окрім GRASP, там теж не скажуть, як саме він перетинається з іншими підходами. У нещасних студентів виникає суцільний когнітивний дисонанс: вони бачать одну абревіатуру, інтуїтивно відчувають, що вона пов’язана з іншою, але НІХТО не пояснює їм як саме. Всі ці знання нагромаджуються в голові, як детальки від конструктора, що ніяк не з’єднуються докупи правильно.

Це просто якесь жахіття. Більшість із того, що сьогодні викладають про GoF-патерни, — це досі «законсервований» переказ підходів 30-річної давнини. Всі курси та навчальні матеріали, які я бачив, слово в слово повторюють ту саму книгу «Design Patterns» 1994 року. Ні, ну серйозно?! Минула третина століття!

Вони використовують ті самі діаграми класів, що й у 94-му. Наприклад, патерн Factory Method в тому вигляді, як його «малюють» в класичних діаграмах, вже давно «вимер» в реальному продакшені. Так код ніхто не пише. Ба більше, так писати не можна, бо це не вирішує жодної проблеми!

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

Багато хто вважає, що відколи є штучний інтелект, архітектуру можна не вчити: «Він же сам напише код, ще й так самовпевнено й переконливо!». Ні. ШІ зовсім не скасовує потребу розуміти архітектуру — навпаки, він робить її ще більш важливою. 

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

А все тому, що ШІ поки що не вміє системно мислити. Й, напевно, ніколи не буде вміти. Тому єдине, що робить нас кращими за LLM — це наше критичне мислення. А воно неможливе без фундаменту й принципів.

Ви повинні володіти принципами принаймні для того, щоб сказати ШІ: «Ні, так не роби. Роби ось так». Бо якщо ви самі не розумієте архітектурних підходів, то не зможете пояснити штучному інтелекту, чому ці його рішення, навіть такі переконливі, — насправді погана ідея.

Ця книга створена для:

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

Як казали мені ще в університеті: знання декількох принципів звільняє від запам’ятовування багатьох фактів. Я хочу, щоб у вашій голові склалася єдина система координат, яка відрізняє хороший код від поганого.

Я інженер, а не теоретик. Будь-яке рішення в розробці для мене має сенс тільки тоді, коли воно розв’язує конкретну проблему. Робити щось «бо це красиво» — шлях в нікуди. Тому мій підхід у цій книзі — це Problem-First: спочатку ми на атоми розбираємо проблему і тільки потім застосовуємо патерн як рішення. І, звісно ж, приклади будуть з сучасного життя, а не «сферичні коні» з 90-х.

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

Ми маємо застекувати всі ваші знання:

1. Згадаємо базовий фундамент ООП (більшість пам’ятає його зовсім не так, як він працює в реальному житті).
2. Розберемо GRASP — правила розподілу відповідальності (бо це основа проєктування систем).
3. Поєднаємо все це з «технікою безпеки» — принципами SOLID.
4. Розглянемо сучасні інструменти мікрорівня — GoF-патерни.
5. Визначимо наступні кроки — куди вам рухатися й що з усім цим робити далі. 

Ця книга навряд чи з’явилася б на світ, якби не мої Early Access читачі — ті, хто купив і читав її ще під час написання. Це просто вогонь! Ви мене дуже надихали.

Я людина відповідальна, але розумію: якби я вирішив писати «в шухляду» одразу всю книгу від початку до кінця, я б її не закінчив ніколи. Як директор компанії, я б завжди знаходив інші, «більш важливі» справи. Але той факт, що ви придбали книжку наперед і чекали на нові розділи, став для мене залізобетонним стимулом: «я точно її завершу!». Така вже я людина 😄.

Окрема подяка моїй дружині Наталі — без її віри та колосальної підтримки ця книга так і залишилася б «тією ідеєю, за яку я колись обов’язково візьмусь». Вона не тільки надихала мене, а й у прямому сенсі змушувала сідати за книгу, бо ж розділ сам себе не напише.

Величезне дякую моїй доньці Ані. Вона у нас професійна художниця, тож всі ці чудові ілюстрації, включно з обкладинкою, — її робота. Завдяки їй у книги з’явився власний візуальний стиль.

Особлива подяка Євгенію Піддубному — найактивнішому рев’юеру цієї книги, який вніс найбільше пропозицій та правок.

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

Люблю вас. Ну що ж, погнали розбиратися з фундаментом архітектури!

• Архітектура потрібна всім: без неї ви не зможете ні контролювати свій код, ні ставити осмислені задачі штучному інтелекту.
• Знання мають бути системними: не можна вчити патерни ізольовано один від одного. ООП, GRASP, SOLID та GoF — це єдина взаємопов’язана система.
• Problem-First: кожен патерн — це інструмент для вирішення конкретного болю. Якщо болю немає, патерн не потрібен.
• Геть академізм: патерни з 1994 року змінилися. Ми вивчатимемо їх так, як вони використовуються в реальному продакшені сьогодні, а не в інститутських методичках.