Усім новачкам радять написати калькулятор. Той самий проєкт, з якого інтерв'юери посміюються, гортаючи твоє портфоліо, — закочують очі ще до того, як відкрили репозиторій. Я все одно його написав. І десь між діленням на нуль і користувачем, який гатить по кнопці «дорівнює», ця скромна сітка кнопок навчила мене мислити як інженер. Десять років по тому, вже працюючи з хмарною інфраструктурою, я спираюся на цей урок щодня.
Проєкт, який ніхто не поважає
Мій перший справжній проєкт — калькулятор. JavaScript для логіки. HTML для сітки кнопок. CSS Grid для верстки — тоді я взяв його до рук уперше. Жодних фреймворків. Жодних бібліотек. Жодного готового API, який зробив би за мене всю брудну роботу. Тільки я, DOM і стільки console.log, скільки я нізащо не зізнаюся на співбесіді.
Гадав, упораюся за день. Провозився цілий тиждень.
Де «просте» розсипається
Математика виявилася найлегшою частиною. Додати, відняти, помножити, поділити — по кілька рядків. Щасливий шлях запрацював за вечір, і я відчув себе генієм. А потім почав по-справжньому ним користуватися.
Натиснув «дорівнює» двічі — отримав повну нісенітницю. З'єднав три операції поспіль — на екрані з'явилося щось, що навіть не число. Хтось увів дві крапки поспіль — і все намертво зависло. А ділення на нуль утнуло таке, про що й досі не хочеться згадувати.
Нічого з цього не було математикою. Усе це було інженерією.
State management ще до того, як я дізнався це слово
Словника в мене тоді не було. Фрази «state management» я жодного разу не чув. Але саме в ній я й тонув. Калькулятор — це не задачка з математики, це крихітний скінченний автомат. Яке число зараз на екрані? Яка операція чекає своєї черги? Останнє натискання завершило обчислення чи продовжує його? Наступна цифра починає нове число чи дописує старе?
Кожен баг був питанням про стан:
- Що буде, якщо натиснути «дорівнює» двічі?
- А якщо з'єднати операції без «дорівнює» між ними?
- А якщо поставити крапку після вже поставленої крапки?
- Яку найтупішу річ може утнути користувач — і чи переживе це програма?
Останнє питання перевернуло моє мислення. Воно перестало бути «чи працює це?» і стало «який найгірший ввід здатна вигадати людина — і чи встоїть програма?». Ось у цих зазорах між щасливими шляхами й живе справжня інженерія.
Від калькулятора до хмарної інфраструктури
А ось чого я не передбачив: кожна з цих навичок пішла за мною слідом.
Обробка подій. State management. Мислення про edge cases. І проста дисципліна — доводити до кінця, а не кидати на вісімдесяти відсотках. Усіма чотирма я користуюся щодня — тепер керуючи хмарною інфраструктурою такого масштабу, якого новачок у мені й уявити не міг: сотні віртуалок, Terraform, CI/CD-пайплайни, Azure.
Контекст змінився. Інстинкт — ні. Ввід користувача непередбачуваний — чи то зайва крапка, чи то кривий API-запит. Стан важливий навіть у маленьких системах — надто в маленьких, бо саме там ти переконуєш себе, що він неважливий. І edge cases — це не прикрі винятки зі «справжньої» роботи. Edge cases і є справжня робота.
Коли я сьогодні рев'юю Terraform-модуль чи проєктую пайплайн, перша думка все та сама, що вбив у мене той калькулятор: що це зламає? Не «як змусити працювати» — змусити працювати я завжди зумію. А як воно переживе того, хто сім разів поспіль тисне «дорівнює»?
Найпростіший проєкт — найглибший урок
Усі хочуть збудувати наступну велику штуку. Про калькулятор не мріє ніхто. Але амбіція зробити щось вражаюче й уміння зробити щось коректне — це два різні м'язи, і другий качають саме на нудних проєктах.
Змусити працювати — легко. Змусити вижити під реальним користувачем — ось це інженерія. Калькулятор, який правильно рахує 0.1 + 0.2, не зависає на подвійній крапці й видає правильну відповідь, коли по «дорівнює» гатять як попало, — тихо доводить, що ти розумієш більше за багатьох.
Тож напиши калькулятор. Напиши без бібліотек. Зламай його навмисне. Найпростіший проєкт здатен дати найглибший урок — якщо ти йому дозволиш.
А що найпростіше ти коли-небудь збирав — і чого воно навчило тебе найбільше?