Якщо ви уявляєте робочий день backend-розробника як вісім годин зосередженого набору коду, у вас дуже стерильна версія реальності. Приблизно як рекламна фотографія кухні: біла стільниця, один лимон, жодної брудної тарілки й абсолютно незрозуміло, де тут узагалі готують. У справжньому backend код є, тільки він рідко лежить перед вами чистим полем. Зазвичай він похований під чужими рішеннями, терміновими повідомленнями, історичними компромісами, неповними вимогами й одним маленьким завданням, яке хтось уже оцінив у п’ять хвилин — бажано вашими руками.
Я відкриваю редактор не для того, щоб «створювати технології». Я відкриваю його, щоб змінити працюючу систему так, аби вона продовжила працювати після змін. Різниця здається незначною, доки ви не згадаєте, що в системи є база даних, черга повідомлень, кеш, мобільний застосунок старої версії, партнерська інтеграція без документації, три сервіси зі схожими назвами й користувач, який неодмінно натисне кнопку двічі саме в ту мить, коли мережа вирішить зникнути.
Backend — це все, чого користувач не бачить, доки воно не зламається. Коли все добре, екран просто показує потрібні дані, лист надходить, платіж проходить, пароль змінюється, замовлення створюється. Коли погано, невидима частина продукту раптом стає найпомітнішою: кошик порожній, гроші списалися двічі, лист пішов не тій людині, а підтримка пише розробникам фразу «у клієнта нічого не працює», яка за інформативністю приблизно дорівнює медичному висновку «пацієнтові недобре».
Коротка відповідь для тих, хто прийшов по визначення: один день backend-розробника складається не лише з написання серверного коду. У ньому є читання чужого коду, уточнення вимог, робота з базами даних та API, код-рев’ю, тести, пошук причин помилок, розгортання змін і робота з технічним боргом. Найнебезпечніша частина дня часто починається зі слів «там просто маленька правка».
08:52. День починається не з коду
Я приходжу раніше за перший дзвінок і роблю професійну помилку: відкриваю корпоративний месенджер. Там уже є повідомлення від продуктового менеджера, запитання від frontend-розробника, сповіщення про нічну помилку й прохання «швидко глянути» чужий pull request. Слово «швидко» в розробці зазвичай описує не тривалість роботи, а рівень тривоги людини, яка її принесла.
Нічна помилка виглядає невинно: кілька запитів завершилися зі статусом 500. Для звичайної людини це число. Для backend-розробника — двері до темного приміщення, де на підлозі лежать дроти, а вимикач підписаний ім’ям співробітника, який звільнився три роки тому. Треба перевірити графіки, логи, трасування запитів і останні зміни. Можливо, база даних відповідала повільніше, ніж зазвичай. Можливо, партнерський сервіс надіслав неочікувану відповідь. Можливо, наш власний код зустрів null там, де двадцять місяців поспіль надходив рядок, і вирішив, що гідний вихід із ситуації — упасти всім процесом.
Я дивлюся на час події, ідентифікатор запиту й ланцюжок викликів. Помилка не повторюється, користувачі не скаржаться, показники повернулися до норми. Це не означає, що проблеми немає. Це означає, що проблема вміє ховатися й поки що перемагає. Я залишаю нотатку, прив’язую логи до завдання й налаштовую спостереження за відповідним показником. Іноді професіоналізм полягає не в тому, щоб негайно виправити невідомо що, а в тому, щоб не видати здогад за діагноз і не влаштувати додаткову аварію з найкращих міркувань.
Паралельно frontend-розробник запитує, чому API повертає порожнє значення в полі імені менеджера. Я відкриваю документацію, потім код, потім історію змін і з’ясовую: документація обіцяє ім’я, код повертає ідентифікатор, а тест перевіряє лише наявність самого поля. Три джерела істини дивляться одне на одного й чекають, хто першим зізнається в брехні. Перемагає, як завжди, продакшен: він уже працює саме так, як написано в коді, і зовсім не цікавиться нашими презентаціями.
На цей момент я ще не написав жодного нового рядка. Минуло близько сорока хвилин. Якщо вимірювати роботу кількістю набраних символів, я байдикував. Якщо вимірювати її кількістю попереджених хибних рішень, ранок минув продуктивно. Ця різниця регулярно ламає очікування людей, які бачать розробку ззовні: вони спостерігають за клавіатурою, а платять за здатність розуміти систему.
09:35. Стендап, де слово «зроблю» дорожче за оцінку
Щоденний короткий дзвінок має відповідати на три запитання: що зроблено, що буде зроблено і що заважає. На практиці він часто перетворюється на публічний ритуал оптимізму. Кожен намагається сформулювати статус так, щоб не виглядати заблокованою, повільною або випадково живою людиною. Менеджеру потрібна передбачуваність, команді потрібна допомога, а мозок розробника в цей момент намагається оцінити завдання, яке він ще не встиг відкрити.
Мені дістається та сама правка «на п’ять хвилин»: дозволити користувачеві змінювати адресу електронної пошти в профілі. В інтерфейсі це справді одне поле й одна кнопка. Копірайтер міг би замінити підпис, дизайнер — намалювати стан підтвердження, frontend-розробник — надіслати нову адресу на сервер. Від backend очікують маленький endpoint: прийняли рядок, записали рядок, повернули успіх. П’ять хвилин, якщо не враховувати реальність. Реальність, на жаль, включена в тариф.
Я не кажу «зроблю за п’ять хвилин». Я кажу, що спершу перевірю, де e-mail використовується як ідентифікатор, як влаштоване підтвердження адреси і які зовнішні системи отримують ці дані. Це звучить менш бадьоро. Зате таке формулювання має рідкісну перевагу: воно не обіцяє неможливого людині, яка за дві години запитає, чому завдання досі не готове.
Психологія оцінювання проста й неприємна. Коли фахівець миттєво називає короткий термін, замовник чує зобов’язання, а не попередню гіпотезу. Коли термін зростає, обговорюють уже не складність системи, а нібито порушену обіцянку. Тому досвідчений backend-розробник обережний не через любов до бюрократії. Він просто знає, що оптимізм фіксується в завданнях швидше, ніж технічні обмеження.
09:52. Чужий код: спочатку розкопки, потім будівництво
У вакансії backend-розробника зазвичай пишуть «розробка нових функцій». Це звучить привабливо, тому що ніхто не хоче розміщувати оголошення «шукаємо людину, яка з’ясовуватиме, чому у 2022 році Денис вирішив зберігати список прав доступу одним рядком». Утім, значна частина роботи починається не з проєктування, а з читання. Ви входите в чужу логіку, знаходите її межі, відновлюєте контекст і намагаєтеся не судити автора раніше, ніж зрозумієте, які строки, дані й керівники стояли в нього за спиною.
Чуже рішення майже ніколи не виглядає чужим лише через ім’я автора. Воно живе в назвах сутностей, у дивній послідовності перевірок, у коментарі temporary fix, який пережив кілька релізів, і у функції на чотириста рядків під назвою process. Код зберігає історію компанії чесніше за корпоративний блог. Ось тут поспішали до запуску. Тут змінювали бізнес-модель. Тут інтеграцію придбали раніше, ніж прочитали документацію. Тут команда знала про проблему, але квартальна ціль знала про команду більше.
У сервісі профілів я знаходжу три варіанти e-mail. Перший зберігається в таблиці користувачів і використовується для входу. Другий лежить у контактних даних клієнта. Третій надходить із системи виставлення рахунків і оновлюється окремим процесом. Вони можуть збігатися, і саме тому кілька років ніхто не помічав, що це різні поняття. Система взагалі любить маскувати архітектурні помилки однаковими значеннями.
Далі з’ясовується, що частину старих акаунтів створювали через соціальний вхід. У деяких користувачів немає локального пароля. У частини адресу записано літерами різного регістру, а унікальність у базі колись перевіряли без нормалізації. Є заблоковані акаунти, видалені акаунти зі збереженою історією платежів і службові облікові записи, якими користуються інтеграції. Просте поле починає поводитися як родинне прізвище в романі на вісімсот сторінок: пишеться однаково, належить різним людям, і одного дня неодмінно з’ясується, що хтось усім доводиться родичем.
Я йду в історію комітів. Не тому, що Git — машина часу, хоча іноді він дуже намагається нею здаватися. Мені потрібно зрозуміти, чому дані розділили саме так. У старій зміні знаходиться посилання на завдання, у завданні — коментар «тимчасово синхронізуємо після релізу», а після релізу настали наступні релізи, змінився менеджер і тимчасове рішення отримало постійну прописку. Так виникає технічний борг: не як акт дурості, а як рішення, строк дії якого ніхто не позначив у календарі.
Тут легко ввімкнути зверхність і оголосити попередню команду некомпетентною. Це дешева втіха. За рік хтось відкриє ваш код і з таким самим виразом обличчя запитає, чому ви не передбачили новий спосіб авторизації, якого сьогодні ще не існує. Зрілість розробника видно не з того, як люто він засуджує старі рішення, а з того, наскільки точно відрізняє поганий вибір від вибору, зробленого за інших обмежень.
Та розуміння контексту не вимагає романтизувати все знайдене. Іноді код справді поганий. Іноді автор поспішав, не перевірив крайні випадки, скопіював блок, приглушив виняток і залишив наступній людині логічну міну. Професійна етика полягає не в тому, щоб назвати міну «спадщиною». Вона полягає в тому, щоб знешкодити її без публічної вистави й зафіксувати, чому вона взагалі була небезпечною.
10:47. Завдання «на п’ять хвилин» роззявляє рота
Щоб дозволити зміну e-mail, недостатньо оновити рядок у базі. Нову адресу спочатку треба привести до єдиного вигляду, перевірити формат і переконатися, що вона не належить іншому акаунту. Потім слід надіслати підтвердження на нову адресу й сповіщення на стару. До підтвердження не можна повністю замінювати ідентифікатор, інакше людина може помилитися в одній літері й добровільно закрити собі вхід. Після підтвердження потрібно вирішити, що робити з активними сесіями, токенами відновлення, підписками на сповіщення та даними в зовнішніх сервісах.
Кожне «потрібно» в попередньому абзаці — окреме рішення, а не рядок коду. Якщо два користувачі одночасно спробують установити одну адресу, звичайна попередня перевірка не врятує: обидва запити можуть побачити вільне значення. Потрібна гарантія унікальності на рівні бази й коректна обробка конфлікту. Якщо лист буде надіслано, а транзакція бази відкотиться, користувач отримає посилання для зміни, якої система не очікує. Якщо база оновиться, а лист не піде, запит зависне у стані, зрозумілому лише розробникові й, можливо, нотаріусу.
Для таких процесів використовується черга повідомлень або transactional outbox — механізм, який допомагає узгодити зміну даних і подальше надсилання події. Та сама наявність черги нічого не гарантує. Повідомлення може надійти повторно, тому обробник має бути ідемпотентним: повторне виконання не повинно ще раз змінювати результат або надсилати п’ять однакових листів. У світі інтерфейсів подвійний клік виглядає як нетерплячість. У backend це повноцінний сценарій відмови.
Потім з’являється безпека. Треба обмежити кількість спроб, установити строк дії посилання для підтвердження, захиститися від підбору токенів і не розкривати, чи зареєстрована конкретна адреса. Треба вирішити, чи повинен користувач повторно ввести пароль або пройти додаткову перевірку. Якщо акаунт пов’язаний із грошима, персональними даними чи адміністративними правами, зміна e-mail — не косметика. Це операція над одним із ключів до цифрової особистості.
Потім з’являється зворотна сумісність. Мобільний застосунок оновлюється не в усіх одночасно. Старий клієнт може не знати про проміжний статус email_change_pending і далі показувати стару адресу як остаточну. Партнерська інтеграція може вважати e-mail незмінним ключем. Аналітика може склеювати події за цим полем. Служба підтримки може шукати клієнта лише за старою адресою. Не можна просто сказати, що вони «неправильно використовують дані»: вони вже використовують їх саме так, а наше завдання — змінити систему, не перетворивши організаційну звичку на масовий збій.
Потім з’являється текст. Як назвати лист? Що написати людині, яка не запитувала зміни? Куди веде посилання для скасування? Як пояснити, що стара адреса залишатиметься активною до підтвердження нової? Тут backend зустрічається з копірайтингом не на рівні красивої кнопки, а на рівні стану системи. Нечітка фраза в листі спричиняє додаткові звернення до підтримки, повторні запити, підозри щодо зламу й хаотичні дії користувача. Хороший текст не прикрашає процес. Він не дає людині зламати його через нерозуміння.
У завданні було одне речення: «Дати можливість змінювати e-mail у профілі». У системі вже налічується кілька станів, два канали сповіщень, обмеження частоти, міграція частини даних, аудит безпеки, зміни API й набір тестів. П’ять хвилин закінчилися приблизно на слові «можливість». Усе інше — відсотки за кредитом, якого ніхто вголос не оформлював.
Я дописую в завдання запитання й коротку схему станів. Менеджер відповідає: «Ми не думали, що це так складно». Це не звинувачення й не сенсація. Люди майже ніколи не бачать складності за кнопкою, як читач не бачить сорока видалених варіантів заголовка. Різниця в тому, що невдалий заголовок знижує дочитування, а невдала зміна e-mail може подарувати акаунт сторонній людині.
12:06. Код-рев’ю: чуже рішення потрапляє на експертизу
До обіду я перемикаюся на pull request колеги. Там змінюється розрахунок комісії: додано новий виняток для певного типу операцій. Автор зробив робочу правку, тест проходить, завдання формально закрите. Проблема в тому, що виняток вставлено у вже перевантажену функцію, де бізнес-правила змішані із запитами до бази, округленням грошей і формуванням відповіді API. Ще одна умова не зруйнує систему сьогодні. Вона просто зробить завтрашнє руйнування трохи дешевшим у виробництві.
Код-рев’ю часто уявляють як пошук помилок. Насправді це переговори про майбутнє кодової бази. Треба перевірити коректність, зрозумілість, тестованість, безпеку, навантаження й відповідність архітектурі, водночас не перетворивши коментарі на демонстрацію власного інтелекту. Написати «погано» легко. Пояснити конкретний ризик, запропонувати співмірну зміну й не змусити автора захищати самооцінку замість рішення — це вже робота.
Я формулюю коментар: зараз нова гілка дублює правило округлення, тому наступний перегляд комісії вимагатиме змінювати дві частини функції; краще винести розрахунок в окремий компонент і покрити його сценаріями на межах. Це довше, ніж «винеси в метод». Зате колега розуміє не лише дію, а й причину. Хороше рев’ю схоже на сильне редагування: воно не переписує автора зі смакових міркувань, а показує, де читач — у нашому випадку система — зрозуміє текст не так.
За кілька хвилин надходить відповідь: строк горить, рефакторинг не вміщується. Це теж частина реальності. Ми домовляємося залишити поточну форму, але додати тести й окреме завдання на розбір функції. Ніхто не щасливий, зате рішення усвідомлене. Технічний борг відрізняється від технічного сміття саме цим: у боргу є причина, ціна й хоча б теоретичний план повернення. У сміття є лише запах і традиція не дивитися в його бік.
12:48. Обід та інші лабораторні умови
Backend-розробники іноді обідають. Це важлива деталь професії, яку рідко зазначають у вакансіях. Я закриваю ноутбук, беру їжу й отримую повідомлення: зріс час відповіді сервісу замовлень. Інцидент не запитує, чи людина закінчила жувати. У нього взагалі слабкі навички міжособистісного спілкування.
Графік показує зростання затримки після ранкового релізу, хоча реліз не стосувався замовлень безпосередньо. Фраза «не стосувався безпосередньо» зазвичай передує відкриттю зв’язків, про які команда або забула, або ніколи не знала. Новий код збільшив кількість звернень до сервісу профілів; сервіс профілів частіше ходить до спільної бази; пул з’єднань заповнився; запити замовлень почали чекати на вільне підключення. Один невинний запит — не проблема. Кілька сотень невинних запитів за секунду вже мають колективний характер і юридично могли б вважатися організованою групою.
Ми обмежуємо проблемний шлях конфігурацією й повертаємо навантаження до норми. Потім перевіряємо, чи не загубилися події та чи не з’явилися повторні операції. Лише після цього починається розбір причини. Під час інциденту не можна лагодити все, що дратує: спершу зупинити шкоду, потім відновити сервіс, а тоді збирати факти. Спроба одночасно провести архітектурну реформу — хороший спосіб перетворити локальну затримку на навчальний вебінар для всієї компанії.
Ніхто не пише код без помилок. Питання не в тому, чи вдасться колись стати безпомилковим розробником, а в тому, наскільки система вміє виявляти, обмежувати й переживати помилку. Метрики, логи, трасування, попередження, можливість швидко відкотити реліз — це не аксесуари для зрілої команди. Це органи чуття. Без них backend не надійний, він просто поки що не отримав скарги.
До обіду я повертаюся за сорок хвилин. Їжа охолола, зате система знову швидка. Можна вважати, що нагрілося щось важливіше.
13:41. Технічний борг не лежить в окремій шухляді
Про технічний борг люблять говорити так, ніби це список некрасивого коду, який команда одного дня урочисто перепише. Насправді борг вбудований у кожен наступний робочий день. Він збільшує час читання, ускладнює тести, робить оцінки менш точними й додає ризиків до простих змін. Команда сплачує відсотки не щоп’ятниці, а під час кожного дотику до системи.
У нашому випадку зміна e-mail складна не тому, що сама операція потребує наукового прориву. Вона складна, тому що поняття користувача розмазане по кількох системах, події синхронізуються різними способами, а історичні клієнти очікують старої поведінки. Кожне колишнє «зараз зробимо простіше, потім виправимо» перетворилося на додаткову перевірку сьогодні. Слово «потім» узагалі є одним із найбільших власників корпоративного програмного забезпечення.
Не кожен компроміс є боргом. Іноді коротке рішення відповідає масштабу продукту й ніколи не стане проблемою. Борг виникає там, де поточна економія створює майбутню вартість, а команда продовжує будувати поверх обмежень. Якщо прототип закрили за місяць, його негарний код нікому нічого не винен. Якщо той самий прототип обслуговує платежі третій рік, він уже не прототип. Він просто дорослий сервіс із важким дитинством.
Найтоксичніша форма боргу — невідома. Коли команда знає про обмеження, описала ризик і розуміє умови виправлення, із ним можна працювати. Коли важливі знання живуть у голові одного співробітника, тести перевіряють лише щасливий шлях, а документація описує систему до останньої реорганізації, будь-яка оцінка перетворюється на ворожіння з IDE. Менеджер бачить завдання на один день, розробник відчуває три приховані шари, а точна відповідь зберігається в людини, яка зараз у відпустці без зв’язку.
Є спокуса вимагати місяць на генеральне прибирання. Зазвичай це закінчується нічим: бізнес не купує абстрактної краси, а команда не може зупинити продукт заради архітектурної сповіді. Робочий шлях нудніший. Ви зменшуєте борг поруч із ділянкою, яку змінюєте, додаєте спостережуваність, фіксуєте межі, виносите правила, пишете тести на знайдені сценарії й окремо домовляєтеся про ті проблеми, які не можна виправити принагідно. Не героїзм, а санітарія. Вона рідко отримує презентацію, зате після неї менше пахне димом.
14:24. Зустріч про вимоги, де кожне слово — підозрюване
Після інциденту ми обговорюємо зміну e-mail із продуктом, підтримкою, безпекою та frontend-командою. П’ятеро учасників приходять із п’ятьма версіями однієї функції. Продукт хоче простоти. Безпека хоче повторної авторизації. Підтримка хоче бачити історію змін. Frontend хоче один зрозумілий статус. Користувача на зустріч не запросили, тому кожен час від часу говорить від його імені.
Головна робота backend-розробника тут — не перелічити обмеження й не перемогти всіх технічними термінами. Треба перетворити розмите бажання на набір однозначних станів і переходів. Що означає «e-mail змінено»: нову адресу записано, підтверджено чи вже використано для входу? Що станеться, якщо посилання відкрито після завершення строку дії? Чи може людина скасувати запит зі старої адреси? Що побачить підтримка? Які сесії залишаться активними? Одне дієслово «змінити» приховує маленьку державну систему з громадянством, кордонами й процедурою перевороту.
Копірайтери знають цю проблему краще, ніж їм здається. Клієнт каже «зробіть текст живішим», а за словом «живішим» можуть стояти коротші речення, конкретні приклади, менше канцеляризмів, більше емоцій або просто особиста неприязнь до першого абзацу. Доки термін не розкладено на спостережувані ознаки, це не вимога, а настрій. Backend працює з тим самим матеріалом, тільки замість прикметників у нього статуси, права доступу й наслідки.
Я малюю послідовність: користувач вводить нову адресу, повторно підтверджує особу, отримує лист, переходить за одноразовим посиланням, після чого система атомарно змінює основний e-mail, відкликає чутливі токени й надсилає сповіщення на стару адресу. Якщо будь-який крок не виконано, основний ідентифікатор не змінюється. Підтримка бачить запит і його стан, але не може підтвердити його замість користувача. Уперше за день завдання стає не простішим, а визначенішим. Це корисніше.
Потім починається торг. Чи потрібно завершувати всі сесії, чи лише підозрілі? Скільки живе посилання? Чи можна повторно надсилати лист? Як часто? Які дані синхронізувати з білінгом негайно, а які — асинхронно? Тут немає універсально правильної відповіді. Є ціна ризику, незручності й реалізації. Архітектура — це не колекція найкращих практик, а протокол розподілу наслідків.
Ми фіксуємо рішення й критерії готовності. Тепер завдання оцінюється в кілька днів за участю різних фахівців. Ніхто не аплодує. Зате зникає фантазія про п’ять хвилин, а разом із нею — майбутня суперечка про те, чому розробник «так довго вовтузиться з одним полем».
15:18. Нарешті код — і він займає не весь екран дня
Після зустрічей, інциденту, рев’ю та розкопок я починаю реалізацію. Створюю окрему сутність запиту на зміну адреси, тому що проміжний стан не можна надійно зберігати у випадковому полі користувача. Додаю унікальний індекс для нормалізованого e-mail, строк дії токена, лічильник повторних надсилань і аудит спроб. Сам код не виглядає епічно. Хороший backend узагалі рідко нагадує сцену з фільму: немає зелених символів, що летять монітором, є назви, перевірки й неприємно багато уваги до того, що може піти не так.
Перший тест перевіряє звичайний сценарій. Другий — зайняту адресу. Потім з’являються прострочене посилання, повторний перехід, два одночасні запити, заблокований акаунт, соціальний вхід без пароля, збій надсилання події та старий мобільний клієнт. Тести не доводять відсутності помилок. Вони зберігають домовленості у виконуваній формі. Документація може застаріти мовчки, а тест хоча б упаде й зіпсує комусь ранок.
Я не намагаюся одразу зробити ідеальну систему. Навколо зміни встановлюється feature flag — перемикач, який дає змогу ввімкнути функцію для невеликої частки користувачів і швидко зупинити її без нового релізу. Події отримують версію, щоб старі споживачі не намагалися вгадати новий формат. Для синхронізації із зовнішніми системами додаються повторні спроби й окрема черга помилок. Це не параноя. Параноя — вважати, що партнерський API ніколи не відповість HTML-сторінкою з текстом «Service unavailable» там, де обіцяв JSON.
Посеред реалізації надходить повідомлення: «Можеш на хвилинку під’єднатися?» Хвилини в корпоративному середовищі мають здатність розмножуватися під час усного спілкування. Я уточнюю тему й терміновість. Виявляється, колега не розуміє помилку міграції в тестовому середовищі. Ми зідзвонюємося, знаходимо старі дублікати в даних і домовляємося спочатку очистити їх окремим скриптом, а потім вмикати обмеження унікальності.
Після розмови я повертаюся до коду й кілька хвилин відновлюю контекст: які гарантії вже реалізовано, де зупинився, який сценарій перевіряв. Перемикання між завданнями має ціну, хоча в календарі вона не відображається. Збоку дві короткі розмови виглядають як двадцять хвилин. Усередині складної роботи вони можуть забрати годину, тому що мисленнєву модель доводиться вивантажувати й збирати заново, наче шафу після переїзду, тільки без інструкції та з продакшеном усередині.
16:37. Власний код швидко стає чужим
Я відкриваю створені зміни цілком і читаю їх як рецензент. Поки пишеш код, мозок автоматично добудовує намір. Він знає, навіщо з’явилася перевірка й чому обрано таку назву. За пів року цього знання не буде ні в колег, ні в самого автора. Тому завдання не завершене, доки рішення не зрозуміле людині, яка не була присутня під час його народження.
Я знаходжу метод, який робить одразу три речі, і розділяю його. Перейменовую статус, тому що processed не відповідає на запитання, що саме сталося. Прибираю коментар, який переказує код, і додаю пояснення до нетривіального обмеження: чому стара адреса залишається основною до завершення транзакції підтвердження. Коментарі мають зберігати причину, а не вести аудіодескрипцію операторів if.
Потім запускаю статичний аналіз, тести й локальну перевірку міграції на копії знеособлених даних. Перший прогін падає: у старих записах є адреси з пробілами наприкінці. Другий знаходить два акаунти, які відрізняються лише регістром літер. Це не «брудні користувачі». Це дані, які система колись дозволила зберегти. База не зобов’язана відповідати нашим новим уявленням про пристойність.
Доводиться зупинитися й вирішити, як опрацювати конфліктні записи. Автоматично об’єднувати акаунти небезпечно: у них можуть бути різні замовлення й права. Видаляти не можна. Я формую звіт для підтримки й виключаю такі записи з автоматичної міграції, залишаючи їх для ручної перевірки. Так один рядок CREATE UNIQUE INDEX перетворюється на процес між розробкою, підтримкою та власником продукту. SQL усе ще короткий. Реальність знову не вмістилася в оцінку за кількістю символів.
Я надсилаю pull request. В описі зазначаю мету, ухвалені рішення, ризики, порядок міграції, спосіб відкочування та сценарії перевірки. Це теж частина розробки. Поганий опис змушує рецензента заново проводити розслідування; хороший скорочує час на розуміння й імовірність поверхового погодження. Якщо код — текст для машини й колег, то pull request — супровідний лист до зміни, тільки фраза «комунікабельний і стресостійкий» тут остаточно марна.
17:12. Код-рев’ю власного рішення: неприємне дзеркало
Колега помічає, що токен підтвердження можна запросити повторно, а старі токени при цьому залишаються чинними. Формально строк дії обмежений, але в користувача з’являється кілька робочих посилань. Це не катастрофа, однак поверхня ризику ширша, ніж потрібно. Я змінюю модель так, щоб новий запит відкликав попередній, і додаю тест.
Інший коментар стосується синхронізації з білінгом: я надсилаю подію після підтвердження, але не передбачив порядок подій за швидких послідовних змін. Теоретично старе повідомлення може затриматися й прибути після нового, повернувши зовнішній сервіс до попередньої адреси. Додаю номер версії та перевірку на боці споживача. Розподілені системи рідко ламаються через неможливе. Вони ламаються через малоймовірне, яке отримало достатньо спроб.
Отримувати зауваження неприємно навіть досвідченому розробникові. Мозок бачить не знайдений дефект, а загрозу статусу: «я пропустив очевидне, зараз усі зрозуміють». Якщо підкоритися цій реакції, починається захист рішення, гра словами й пошук зустрічних недоліків. Корисна дисципліна простіша: відокремити себе від коду, перевірити ризик і виправити те, що справді робить систему слабшою. Pull request — не характеристика працівника. Хоча деякі команди докладають чималих зусиль, щоб він нею став.
Я відповідаю на коментарі, оновлюю опис і знову запускаю тести. Тепер зміна технічно готова до тестового середовища, але не до негайного ввімкнення. Треба прогнати міграцію, перевірити шаблони листів, переконатися, що підтримка розуміє нові статуси, і домовитися про спостереження після запуску.
Слово «готово» в backend завжди потребує уточнення: готовий код, готовий реліз, готова функція чи готовий бізнес-процес. Якщо цього не уточнити, кожен обере зручну версію й розчарується в решті.
17:49. Реліз — не фінал, а момент початку спостереження
Зміна потрапляє в тестове середовище. Я перевіряю основний сценарій вручну через API, потім дивлюся, як подія проходить через чергу й доходить до сервісу сповіщень. Лист надходить, посилання працює, повторний перехід повертає зрозумілу відповідь. У логах немає персональних даних, які не повинні там зберігатися. Метрики розрізняють успішне підтвердження, прострочений токен, конфлікт адреси й технічну помилку. Якщо все звалити в один лічильник failed, завтра ми знову лікуватимемо пацієнта з діагнозом «недобре».
У продакшен функція сьогодні не піде. Це правильне рішення, хоча воно погано виглядає у звіті про швидкість. До кінця дня мало часу, частина команди скоро відключиться, а ручну обробку старих конфліктів іще не погоджено. Випустити зміну зараз можна. Спостерігати за нею, швидко реагувати й безпечно відкотити — уже складніше. Реліз увечері заради красивої галочки часто закінчується вранці через некрасиву причину.
Я залишаю план увімкнення на наступний день: спершу внутрішня група, потім невеликий відсоток користувачів, далі поступове розширення за нормальних показників. Для помилок задаю пороги, після яких перемикач вимикається. Це не страх перед релізом. Це визнання простої речі: тестове середовище не містить усього різноманіття продакшену, тому що людство поки не навчилося якісно імітувати саме себе.
Менеджер запитує, чи можна вважати завдання виконаним. Я відповідаю: реалізацію й рев’ю завершено, тестування інтеграцій триває, випуск заплановано після перевірки конфліктних акаунтів. Це довше за слово «так», зате завтра не доведеться пояснювати, що саме вчора означало «так». У професії, де той самий термін може описувати чотири різні стани, точність формулювання є частиною технічної компетентності.
18:11. Що за день зробив backend-розробник
Якщо скласти звіт за видимою активністю, вийде дивна картина. Я розслідував помилку, допоміг frontend-команді, брав участь у стендапі, прочитав чужий код, провів рев’ю, зупинив деградацію сервісу, обговорив вимоги, написав реалізацію, розібрав брудні дані, отримав зауваження й підготував реліз. Нових рядків коду серед усього цього менше, ніж очікує людина, яка вперше знайомиться з професією. Відповідальності — помітно більше.
Backend-розробник щодня працює з наслідками. Умова в коді впливає на дані; дані впливають на інтеграції; інтеграції впливають на інтерфейс; інтерфейс впливає на поведінку користувача; поведінка користувача повертається в систему неочікуваною послідовністю запитів. Не можна оцінювати рішення лише за тим, чи відповідає endpoint статусом 200 зараз. Треба розуміти, що станеться за повтору, затримки, часткового збою, старого клієнта, неправильних даних і зростання навантаження.
Тому сильний backend-розробник — не той, хто друкує найшвидше й знає більше назв фреймворків. Швидкість набору коду майже ніколи не обмежує роботу. Обмежують неповна картина, приховані залежності, ціна помилки й необхідність домовитися з людьми про те, що саме система має гарантувати. Фреймворк допомагає написати обробник. Він не вирішує, чи має підтримка право змінювати ідентифікатор користувача і хто відповідатиме, якщо цим правом скористаються неправильно.
Технічна частина професії вимагає знання мови, баз даних, мережевої взаємодії, конкурентного доступу, безпеки, тестування та спостережуваності. Людська частина вимагає витримувати невизначеність, ставити незручні запитання, пояснювати ризики без театру катастрофи й приймати зауваження без дуелі в коментарях. Ці частини не можна чесно розділити. Помилка комунікації так само легко стає помилкою системи, тільки компілятор її не підсвітить.
Для копірайтера або фахівця із суміжної сфери це, ймовірно, найупізнаваніша частина дня. Вам теж приносять «невелику правку», яка змінює логіку сторінки, тон бренду, структуру аргументу й обіцянку клієнту. Ви теж читаєте чужі рішення, відновлюєте контекст і пояснюєте, чому заміна одного слова вимагає перевірити весь абзац. Різниця в ціні деяких помилок та інструментах, але механізм той самий: невидима робота починається там, де сторонньому спостерігачеві вже все здається очевидним
Чому завдання на п’ять хвилин майже ніколи не займає п’ять хвилин
П’ять хвилин — реальна оцінка лише для дії, ізольованої від наслідків. Змінити локальну константу в навчальному проєкті можна швидко. Змінити поведінку живої системи — означає перевірити, хто залежить від старої поведінки, які дані вже накопичено, як виконати перехід і як зрозуміти, що нічого не зруйнувалося. Більша частина часу йде не на введення команди, а на доведення її допустимості.
Є ще одна неприємна організаційна причина. Людина, яка каже «на п’ять хвилин», зазвичай оцінює видиму частину результату. Вона бачить поле, кнопку, фразу, колір або число. Фахівець оцінює весь шлях зміни: вимоги, реалізацію, крайні випадки, тести, рев’ю, доставку, спостереження й відкат. Вони говорять про один об’єкт, але рахують різні роботи. Звідси народжується не технічна суперечка, а конфлікт карт реальності.
Проблема не вирішується фразою «ви нічого не розумієте». Це зручно для самолюбства й марно для продукту. Розробникові потрібно показати ланцюжок наслідків зрозумілою мовою, а замовникові — перестати видавати бажану тривалість за оцінку. Хороше запитання звучить не «чому так довго?», а «які ризики й залежності роблять завдання таким?» Після нього розмова принаймні отримує шанс стати професійною.
Іноді завдання справді робиться за п’ять хвилин. Потім ще двадцять хвилин займає тестування, п’ятнадцять — рев’ю, десять — випуск і кілька годин — очікування вікна, у якому зміну можна безпечно ввімкнути. Якщо рахувати лише момент редагування, хірургічна операція теж здається короткою: розріз же займає секунди. Чомусь клієнти все одно воліють оплачувати решту процесу.
Неприємна правда про роботу backend-розробника
У цій професії рідко буває день, коли ви закрили ноутбук із відчуттям завершеного світу. Система продовжує працювати, черга приймає повідомлення, нічні завдання запускаються, користувачі створюють нові комбінації даних, а зовнішні сервіси готують черговий неочікуваний формат відповіді. Ви не закінчили продукт. Ви передали його наступній зміні часу.
Результат роботи часто негативний у математичному сенсі: не сталося витоку, не загубилися платежі, не впала база, не пішов дубльований лист, не зламався старий клієнт. Такі досягнення погано виглядають на святковому слайді, тому що на ньому буквально нічого немає. Саме це «нічого» й було метою. Надійність — бізнес, побудований на відсутності подій.
Тут не можна постійно жити на натхненні. Іноді завдання цікаве, архітектура чиста й рішення приємно складається. Іноді ви третю годину з’ясовуєте, чому один користувач створив замовлення без обов’язкового поля, хоча всі перевірки запевняють, що це неможливо. Зрештою виявляється, що старий імпорт обходить публічний API й записує дані безпосередньо. Таємницю розкрито, світ не став красивішим, а у вас з’явився ще один пункт у списку речей, які «ніколи не трапляються».
Є й інша неприємна правда: значна частина якості залишається невидимою навіть усередині компанії. Акуратна міграція виглядає так само, як ризикована, якщо обидві завершилися без збою. Хороша схема повторних спроб не отримує оплесків, тому що користувачі просто отримали свої листи. Погане рішення може місяцями здаватися швидким та ефективним, доки одного дня не збере відсотки одразу за весь період. Backend часто оцінюють за результатом останнього інциденту, а не за кількістю інцидентів, яких не сталося.
Тому професійна гордість тут має спиратися не лише на зовнішню реакцію. Треба самому розуміти, де ви зменшили ризик, зробили поведінку явною, зберегли дані й залишили наступній людині трохи зрозумілішу систему. Це не надихаюча мораль. Це спосіб не почати вимірювати якість кількістю закритих карток, половина з яких закрита лише тому, що проблему перенесли в чужий квартал.
18:34. Останнє повідомлення
Перед тим як вимкнути ноутбук, я бачу нове запитання: «Якщо вже все одно чіпаємо e-mail, можемо заодно додати вхід за номером телефону? Здається, логіка майже така сама». Я не відповідаю одразу. Не тому, що запитання погане, а тому, що мій робочий день уже надав достатньо доказів проти слова «майже».
Вхід за номером телефону зачіпає інші способи підтвердження, вартість повідомлень, їх доставлення в різних країнах, повторне використання номерів, відновлення доступу, шахрайські сценарії й користувацькі акаунти без e-mail. Логіка схожа приблизно так само, як ліфт схожий на сходи: обидва переміщують людину між поверхами, доки не починаєш обговорювати механізм, безпеку й поведінку під час відключення електроенергії.
Я пишу: «Так, можемо оцінити окремо. Спочатку опишемо сценарії та обмеження». Це не відмова й не обіцянка. Це межа між професійною роботою та колективним самообманом. Завтра хтось назве це завдання маленьким. Завтра я знову відкрию код і почну з’ясовувати, наскільки широко воно вміє роззявляти рота.
Один день backend-розробника закінчується не фінальною крапкою, а збереженим контекстом: що перевірено, що залишилося невідомим, які ризики прийнято й за якими ознаками завтра стане зрозуміло, що система поводиться нормально. Код посідає важливе місце в цьому дні. Просто не центральне. У центрі — відповідальність за чужі дані й чужі рішення, зокрема ті, які ще п’ять хвилин тому здавалися простими.
Чому backend-розробники ставлять так багато уточнювальних запитань?
Тому що слова на кшталт «змінити», «видалити», «швидко» й «автоматично» не описують точної поведінки системи. Запитання допомагають визначити права доступу, стани, винятки, джерела даних і реакцію на збій. Якщо розробник мовчки додумує відповіді, продукт однаково отримає конкретну поведінку — тільки вона може виявитися випадковою й розкритися вже після релізу.
