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

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

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

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

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

Я запитував їх: “А що ж ви вивчали на ваших курсах?”. Вони з гордістю відповідали: “Ми робили бульбашкове сортування і рахували числа Фібоначчі!”. Я питав: “А Spring вивчали?”. Вони дивилися круглими очима: “Ні, а що таке Spring?”. І це мене просто дико бісило.

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

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

Біль №1: Знання у вакуумі

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

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

Біль №2: Застаріле лайно мамонта

Це просто якесь жахіття. Всі курси та книжки по GoF-патернах, які я бачив, просто беруть і слово в слово переказують книгу 1994 року. Йоханий бабай! Минуло більше 30 років!

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

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

Біль №3: Сліпа віра у ШІ

Багато хто вважає, що відколи є штучний інтелект, архітектуру можна не вчити: “Він же сам напише код, він такий самовпевнений!”. Ні.

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

Якщо ви не знаєте китайської, будь-який переклад від ШІ здаватиметься вам правильним. Так само і тут: якщо ви не розумієте архітектури, будь-яка відрижка штучного інтелекту здаватиметься вам нормальним кодом. Ви повинні мати принципи, щоб сказати ШІ: “Ні, так не роби. Роби ось так”. Але щоб це сказати, треба знати як саме.

Для кого ця книга

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

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

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

Як ми будемо вчитися: Problem-First

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

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

An icon of a info-circle1

Щодо мови прикладів: Більшість сніпетів коду в цій книзі написані мовою Java (або дуже наближеним до неї псевдокодом). Чому? По-перше, це мова, якій я присвятив понад 15 років свого професійного життя. По-друге, Java та C# — це своєрідна “латина” об’єктно-орієнтованого програмування. Їхній синтаксис легко читають розробники на TypeScript, PHP, Python, Swift та C++. Я хочу, щоб ви зосередилися на архітектурі, а не витрачали сили на парсинг незвичних конструкцій. Водночас, там, де патерн зав’язаний на екосистему (наприклад, ізоляція запитів у PHP-FPM чи Event Loop у JavaScript), я буду наводити приклади відповідними мовами. Але пам’ятайте: фундаментальні принципи ООП від синтаксису не залежать!

An icon of a info-circle1

Важливо для читачів електронної версії (EPUB): Книга містить багато блоків коду. Для комфортного читання та збереження правильного форматування (відступів) я наполегливо рекомендую використовувати стандартні додатки, такі як Google Play Books, Apple Books, FBReader або Moon+ Reader. Уникайте додатків для паралельного читання та перекладу (наприклад, Smart Book), оскільки вони примусово “розбивають” код на окремі слова і повністю ламають його структуру.

Структура: Куди ми йдемо

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

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

Подяка Early Access читачам

Окремо хочу подякувати всім, хто купив і читає цю книгу в процесі її написання. Це просто вогонь! Мене це дико надихає.

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

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

Люблю вас. Залишайтеся з нами, а ми поїхали розбиратися з фундаментом архітектури!

🔑 Висновки розділу

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