концепції / abstractions
Абстракції
Проєктування абстракцій — третя з трьох навичок, які, за першим відео каналу, перетворюють хорошого кодера на видатного програміста, з двома ключовими аспектами: звʼязаністю (coupling) та звʼязністю (cohesion) (3 речі, які роблять програміста кращим); якісний код, своєю чергою, визначається як абстракції, що продовжують працювати, коли ви їх розширюєте, — код, який ніколи не доводиться викидати (3 речі, які псують програміста). Його практичний тест для межі: бізнес-логіка не повинна знати про веб-фреймворк — якщо ті самі сервісні класи могли б працювати під CLI чи Telegram-ботом (він показує свого семирічного гольф-бота на Perl 6, збудованого саме за цим патерном), абстракція правильна (вайб-кодинг нового проєкту). Навичку проєктування він вважає по суті синонімом навички роботи з абстракціями — саме вона визначає твій рівень у Google, і саме тому він називає Go «абсолютно не окей» для систем із важкою бізнес-логікою на кшталт бухгалтерії: мові бракує конструкцій для абстракцій, вона годиться для мікросервісів, проксі та CLI-інструментів, тоді як для складних застосунків він бере TypeScript/C# (Q&A і плани на 2024, Q&A №2).
Його найоригінальніше спостереження — він виніс його на слайд DOU Day — у тому, що менш досвідчені розробники бояться створювати нові абстракції: вони перевикористовують або копіюють наявні структури і майже ніколи не виокремлюють нові. Це не страх нових файлів (файли розробники створюють постійно), а додаткове мислення, якого вимагає нова абстракція, плюс ще невміння бачити наслідки (страшні абстракції). Бойові історії: assertDate, приліплений до TestFactory у WebbyLab, бо фабрика «вже всюди»; базові сервісні класи, що обростають утилітами для дат/файлів/сесій до стану God Object; його PoC-віджет на ~100 рядків, що виріс в один файл на 5000 рядків («так ВИ ж нам показали»); React-команда, якій було некомфортно додати поняття контролера, бо ніхто там такого не робив, — тоді як у Google його UI-контролери над низькорівневими шматками «чудово» спростили код. Існує і зворотний провал: ШІ перемудровує, вигадуючи ієрархії класів brand-manager із registerNewBrand() там, де вистачило б JSON-файлу з марками авто, — він постійно командує «видали цю абстракцію» (вайб-кодинг, частина 2). І конструктивний напрямок: специфічні для проєкту декларативні білдери (grid, form, PageBuilder) як свідомі додаткові шари, що кардинально здешевлюють роботу над UI (швидша розробка UI, див. декларативний UI).
Розібрано у відео
- Голосове №3 — страшні абстракції
головне відео: чому розробники запихають код у наявні структури замість виокремлювати нові абстракції; чотири бойові історії
- 3 речі, які роблять програміста кращим
проєктування абстракцій як одна з трьох навичок видатного програміста; coupling і cohesion
- 3 речі, що псують програміста
якість = абстракції, що переживають розширення
- Вайб-коджу новий крутий проєкт (стрім)
тест на заміну: сервіси, які могли б працювати під CLI/Telegram-ботом; шари як межа
- Вайб-кодінг — частина 2 (стрим)
протилежний провал: непотрібні ієрархії абстракцій від ШІ, «видали цю абстракцію»
- Головна проблема мікросервісів, яку часто недооцінюють
неправильні абстракції дешево виправити в моноліті та боляче — між сервісами
- Голосове №2 — як швидше розробляти інтерфейс
білдери як продуктивні додаткові шари абстракції з люком, щоб спуститися на шар нижче
- Відповідаю на питання №2
відсутні інструменти абстракції в Go; розширення архітектурних патернів (власне поняття контролера), коли вони перестають пасувати
Повʼязане
Проєктування програмного забезпечення — проєктування абстракцій — його серце Декларативний UI (білдери на схемах) — його улюблена конструктивна абстракція: UI-білдери на основі схем Якість коду — гниття починається, коли структура перестає відповідати відповідальностям Технічний борг — невиокремлені абстракції накопичуються в борг Патерни проєктування — патерни як названі, заздалегідь класифіковані абстракції A Philosophy of Software Design — книжка, яку він цитує про увагу до дизайну