Проєктування програмного забезпечення

Проєктування — центральна тема каналу про інженерну майстерність: у Google, каже Віктор, твій рівень визначається вмінням проєктувати, а не знанням технологій (до приходу туди він жодного рядка не написав ні на Java, ні на Angular), і це вміння він напряму повʼязує з роботою з абстракціями та знанням властивостей речей через їхню внутрішню будову: індекс — це відсортована структура, а отже запис чогось коштує і виграють лише певні форми запитів (Q&A і плани на 2024). Його особистий метод — API-first: ніколи не починати з реалізації — спершу написати приклад коду використання, переписувати його, доки не проявиться скелет, і братися за реалізацію лише тоді, коли API демонструє єдину відповідальність, мінімум вхідних даних, відсутність витоку деталей реалізації та розширюваність (3 речі, які роблять програміста кращим, Q&A №2). Він відкрито анти-TDD-пурист: цикл red/green годиться для виправлення багів, але під час проєктування звужує фокус — він цитує A Philosophy of Software Design про те, що TDD відводить увагу вбік, пише тести після коду і тримається класицистської позиції щодо моків: замість них проєктувати під підмінювані (injectable) реалізації (Q&A №2). Детальне проєктування відбувається під час кодування, через прослідковування сценаріїв використання від початку до кінця; не передбачити все — нормально, і саме тому він любить думку Роберта Мартіна про те, що робота архітектора — відкладати рішення: хороша архітектура максимізує кількість неприйнятих рішень, бо розуміння домену покращується щодня (головна проблема мікросервісів).

Стрими з вайб-кодингу показують цю доктрину в дії: чиста архітектура, продиктована Claude, — мета: тонкі контролери як клей, що його не тестують (товсті контролери й анемічна доменна модель — антипатерни), один application service на ендпоінт з єдиним run(), валідація всередині сервісу, ніколи не випускати доменні сутності назовні (приклад із хешем пароля), бо хешування паролів — доменна бізнес-політика; плюс його жарт про «API для терранів» проти JSON:API «для зергів» і відповіді завжди-HTTP-200-зі-статус-прапорцем, як у API Facebook (стрим вайб-кодингу нового проєкту). Проєктування також спирається на контекст, якого бракує ШІ: він знає, що гоночних трас буде ~100–200 (кешувати назавжди, без пагінації), а точок телеметрії — мільйони (в жодному разі не окрема сутність на кожну точку) — з доказами: Rust→WASM-оптимізація Figma з першого дня і Monaco з VS Code, який відкинув усі веб-фреймворки (тоді як Atom помер від повільності): деякі властивості мають бути закладені в дизайн від самого початку (вайб-кодинг, частина 2). Глибина — передумова проєктування: потрібно знати властивості кожної підсистеми — що станеться з БД, якщо даних стане вдвічі більше, як поводиться її ізоляція — щоб система в цілому відповідала своїм вимогам (випуск про глибоке навчання і запамʼятовування). Патерни й best practices не священні: патерн — це лише класифікована назва того, що спрацювало, а best practices існують, щоб запобігати жахливому коду, а не породжувати найкращий — зрозумійте причини, і зможете свідомо їх порушувати; він наводить приклад event sourcing Ґреґа Янґа, канонізованого всупереч задуму автора (3 речі, які псують програміста). У WebbyLab ця дисципліна інституціалізована: періодичні архітектурні ревʼю з чеклістами помилок (анемічна доменна модель включно), ревʼюер, який мусить зуміти запустити проєкт однією командою, C4-діаграма контейнерів, з якої відкривається ~2-годинний дзвінок, і план дій, що повторно перевіряється за ~2 місяці (випуск про код-ревʼю в Google). Його книжковий канон: Clean Architecture про шари, Domain-Driven Design про домен, Patterns of Enterprise Application Architecture про те, як ці шари реально реалізуються (3 книжки про проєктування ПЗ, книжки на пʼять зірок).