Припиніть писати код, як ніби ви працюєте в Google

Давайте відразу розставимо крапки над «і». Ви не працюєте в Google. Я теж. Більшість з нас не працює. І все ж, з якоїсь причини, існує поширена епідемія розробників, які пишуть код так, ніби щосекунди можуть опинитися на індивідуальній зустрічі з Сундаром.

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

Ось вам невеличка історія.

Кілька років тому я допомагав другові створити невеликий інтернет-магазин. Нічого особливого. Кілька товарів, сторінка оплати, можливо, трохи інтеграції Stripe. Знаєте, що в нього було? Повна подія-орієнтована архітектура. Він використовував RabbitMQ для надсилання повідомлень від своєї платіжної системи до своєї поштової служби. У нього був окремий репозиторій для кожного «обмеженого контексту».

До речі, цей магазин продавав домашні ласощі для собак.

Я подивився йому прямо в очі і запитав: «Ти очікуєш, що до наступного вівторка це масштабується до рівня Amazon?».

Він не засміявся. Він був абсолютно серйозний.

Корпоративний кодувальний мозковий штурм

Коли ви працюєте в компанії FAANG, ви не просто пишете код. Ви вирішуєте проблеми, які існують лише в глобальному масштабі. Наприклад, «що станеться, якщо мільярд людей одночасно відкриють додаток» або «як розгорнути 10 тис. мікросервісів, не підпаливши дата-центр».

Але коли ви працюєте над побічним проєктом, MVP для стартапу, фрілансом або навіть внутрішнім інструментом для своєї команди з п’яти осіб, у вас немає таких проблем. У вас зовсім інші проблеми.

Наприклад

• Чи зможе новий розробник прочитати це і зрозуміти, не розшифровуючи візантійський лабіринт абстракцій?
• Чи зможу я випустити це за менше ніж три тижні, не вигорівши?
• Чи буде це працювати на дешевому VPS, коли закінчаться гроші інвесторів?

Це не ті самі проблеми. То чому ви шукаєте ті самі рішення?

Вам не потрібна фабрика, щоб зробити бутерброд

Насправді не потрібна.

У більшості випадків вам потрібно щось, що працює. Щось швидке, зрозуміле і підтримуване вами, вашим другом або вашим трохи розгубленим майбутнім «я» після трьох банок Red Bull і легкої екзистенціальної кризи.

Тож давайте поговоримо про деякі типові ознаки того, що ви пишете код як Googler у світі, який просто хоче, щоб ви створили цю кляту штуку:

1. Ви створили власну систему ін’єкції залежностей;
2. Круто. Ви щойно винайшли колесо, але тепер воно квадратне і тримається на надії.;
3. Ви написали фреймворк для абстрагування фреймворка, який ви використовуєте;
4. Навіщо? Просто… навіщо;
5. Ви використовуєте слово «інтерфейс» частіше, ніж «функція»;
6. Інтерфейси — це чудово. Але якщо вся ваша програма складається з інтерфейсів без реальної логіки, вітаємо. Ви створили архітектурну діаграму. Тепер поверніться і створіть програму;
7. Ви розділили свою програму на чотирнадцять рівнів абстракції для списку завдань;
8. Брате. Просто збережіть завдання;
9. Ви вважаєте, що «моноліт» — це лайка;
10. Це не так. Моноліти прекрасні. Вони швидко створюються, простіші в розумінні, і вам не потрібно склеювати п’ять сервісів, щоб відобразити список елементів.

Підйом інді-хакерського мислення

Я не кажу, що потрібно писати спагетті. Я не кажу, що не потрібно використовувати шаблони. Але спосіб, яким ми пишемо код, повинен відповідати нашим цілям.

Якщо ви самостійно створюєте SaaS, випускаєте інструмент з відкритим кодом або розробляєте крутий AI-віджет за вихідні, вам не потрібні абстракції корпоративного рівня. Вам потрібна швидкість. Ясність. Стислість. Елегантність у тому, щоб зробити багато з малого.

Швидко випускайте, швидко виправляйте, швидше вчіться.

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

Інженери Google пишуть так, бо мусять

У них сотні людей працюють над одним і тим самим кодом. Вони мусять думати про версії, зворотну сумісність і безпеку на рівні, з яким ми з вами не маємо справи.

А ви? Ви можете змінити все за одну ніч, якщо захочете. Ви маєте свободу. Гнучкість. Чому б не скористатися цим?

Остання історія

На місцевій зустрічі розробників я зустрів хлопця, який за чотири дні створив цілий сайд-проект. Він був потворний. Функції були довгими. Стан був повсюди. Він використовував jQuery у 2023 році.

Але це працювало. І що важливіше, це приносило гроші.

Я зустрів його знову через півроку. Він переписав все з нуля, використовуючи React, TypeScript, Vite і повністю модульну архітектуру. Це було чудово.

Дохід впав до нуля.

Чому? Тому що він не додав жодної функції за півроку. Він весь час витрачав на рефакторинг. Він побудував найкрасивіше місто-привид, яке я коли-небудь бачив.

Останнє слово

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

Серйозні інженери вирішують проблеми. Вони не косплеять інших інженерів.

Припиніть писати код, ніби ви працюєте в Google. Почніть це робити, ніби ви працюєте на себе.

Ви будете більше працювати. Менше нервувати. І, можливо, вам це навіть сподобається.

PS

Якщо цей пост вас розлютив, то, швидше за все, він був призначений саме для вас. А якщо він вас розсмішив, то ви, мабуть, вже наполовину вирвалися з корпоративної клітки. Продовжуйте в тому ж дусі.