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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Якось я здав американським замовникам (індійського походження) ідеальний архітектурний документ. Частина діаграм була у форматі Activity (схоже на шкільні блок-схеми). Вони повернули його зі словами: “Будь ласка, намалюйте нам UML, ми взагалі не розуміємо, як виглядає ця діаграма”. Це чудовий показник. Не треба займатися наукоподібним навчанням. Використовуйте прості речі, які зрозумілі всім. Це саме стосується, до речі, і різних тренажерів на кшталт LeetCode — на мій погляд, це сьогодні чистий карго-культ, який не робить ваш код кращим.

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

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

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

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

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

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

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