Віктор Турський про програмування / навігатор

Інженерна майстерність і карʼєра / крок 01

3 речі, які роблять програміста кращим

початковий 20:13 дивитися на YouTube ↗

Розділи

Про що це відео

Перше відео каналу. Спираючись на ~20 років програмування, великий досвід співбесід і запуск багатьох проєктів, автор пропускає «банальні» поради (софт-скіли, англійська) і називає три речі, яких найчастіше бракує навіть сильним кодерам: (1) справжнє бажання розібратися в предметній області (знання домену) — архітектуру диктує домен, а не патерни; (2) звичка вивчати, як усе працює, глибоко (глибоке вивчення основ) — тут його авторитет — Джон Кармак; та (3) вміння проектувати абстракції й працювати з ними. Писати добрий код, наголошує він, — лише невелика частка того, що робить хорошого програміста.

Головне

  • Знання домену визначає архітектуру. Його приклад із чатом: дизайнер показує вам чат з індикатором набору тексту — одразу тягнутися до WebSockets? Не обов'язково. Якщо насправді це просто коментарі під замовленнями, класичний long-polling раз на ~5 секунд цілком годиться; якщо це внутрішній корпоративний чат щонайбільше на 100 користувачів, 100 запитів на секунду полінгу можуть виявитися простішими за цілу інфраструктуру WebSocket. А чи прийнятно це — знаєш лише з домену.
  • Знання домену також живить мотивацію. Він із подивом виявив, що програмісти віддають перевагу зрозумілим доменам, а не технічно складним: друзі хотіли працювати над інтернет-магазином («там товари, ціни, знижки, замовлення»), але втратили мотивацію, щойно з'явився модуль логістики, — і повернули її (та ще й почали ухвалювати кращі архітектурні рішення), коли розібралися, як логістика насправді працює як бізнес.
  • Щоб прокачатися в доменах, він радить книги з DDD: Ерік Еванс і Вон Вернон (дві книги). Вернон практичніший, але він рекомендує саме Еванса — читати не заради того, як структурувати код (приклади/агрегати), а заради чому, заради способу мислення автора. І ще: завжди продумуйте весь шлях користувача — ви зробили кнопку «Забронювати квиток», а як користувач цей квиток отримає? Подія офлайн чи онлайн? А якщо квиток загубився? Такі запитання виявляють речі, про які проектний менеджер і не думав, — і дешевше запитати зараз.
  • Вивчайте речі глибоко — на ринку є два типи інженерів: ті, хто каже «навіщо мені знати нутрощі, я просто викликаю методи», і ті, хто готовий копати. Якщо не знаєш, як усередині влаштовані MySQL, PostgreSQL чи MongoDB, ти не знаєш їхніх властивостей: що станеться, коли даних стане вдвічі більше, скільки насправді коштує UPDATE, чим рушії відрізняються (глибоке вивчення основ).
  • Класичні пастки поверхневих знань, які він бачив особисто: люди, які думають, що JWT шифрує payload (це підпис — прочитати може будь-хто), і клієнтський інженер, який стверджував, що HTTP Basic Auth «зашифрований, бо це Base64», — Base64 — це кодування, а не шифрування. Розуміння асиметричної криптографії, ключів і підписів навіть на рівні «абетки» веде до кращих рішень (практики безпеки).
  • Байка «Docker на macOS удвічі повільніший»: розробник зарепортив це як баг; його відповідь — «це не баг, це фіча». Контейнерів як концепції ядра не існує навіть у Linux — це абстракція над підсистемами ізоляції. На macOS взагалі немає Docker: запускається віртуалка з Linux, ваш процес працює всередині неї, і кожен виклик файлової системи проходить через ядро Linux, а потім через ядро хоста — звісно, це коштує продуктивності й пам'яті.
  • З чого почати копати: класичне питання зі співбесід «що відбувається між введенням URL і відмальовуванням сторінки» може провести крізь мережевий стек, HTTP/HTTPS, рівні OSI — і навіть у DNS ховається глибина (Chrome сам ходить у DNS чи делегує іншому процесу ОС?). Вивчення безпеки (ін'єкції, XSS/CSRF, buffer overflow, Heartbleed, Shellshock) — чудовий транспорт, бо безпека — це якраз про те, як речі працюють і як порушити їхні очікувані властивості. Його конкретна стартова вправа (з внутрішнього бейзлайну webilab на 13–14 тем): напишіть JSON-парсер без жодної бібліотеки — і зрозумієте JSON у деталях.
  • Проектування абстракцій: два ключові аспекти — coupling і cohesion (обіцяє окреме відео). Його особистий метод (проектування ПЗ): він любить тести, але не червоно-зелений цикл TDD; натомість ніколи не починає з реалізації — спершу пише приклад коду використання майбутнього модуля/класу, і лише коли API демонструє одну нерозмиту відповідальність, приймає тільки потрібні йому параметри, не протікає деталями реалізації та виглядає розширюваним — іде реалізовувати.

Теми відео

Частина цих треків