День з життя розробника

Ранок. Пріоритети та вибір задачі

Робота Олексія починається з того, що він відкриває ноутбук і заходить у Jira. Перше завдання — дослідити беклог і зрозуміти, які задачі зараз найпріоритетніші.

Jira — це система для управління задачами в команді.
Простими словами: це електронна дошка, де команда бачить, хто що робить і що вже зроблено.

Беклог — список усіх задач, які заплановані до виконання, але ще не взяті в роботу.

Він переглядає опис задачі, дивиться на теги, оцінки, залежності. Далі обирає одну задачу — або ту, що виглядає найбільш зрозумілою, або ту, що є критичною в межах поточного скоупу.

Скоуп — це перелік конкретних задач, які команда домовилась зробити, наприклад, протягом двох тижнів.

Після цього Олексій пише тімліду:
«Можу взяти цю задачу?».
Якщо заперечень немає — переводить її у статус In Progress і починає працювати.

‍

‍

Дослідження. Зрозуміти бізнес — перш ніж писати код

Перш ніж щось імплементувати, потрібно чітко зрозуміти, як фіча має працювати з точки зору бізнесу клієнта.
Наприклад, якщо користувач не має платної підписки, він не може зберігати більше 3 гігабайт файлів. Або якщо документ не заповнений повністю, його не можна відправити на погодження.

Фіча — функціональна можливість системи.

Ідеальний сценарій — усе зрозуміло з опису задачі та документації. Але так буває не завжди. Якщо виникають питання, їх потрібно обов’язково уточнити у тімліда або команди ДО початку роботи.

Неправильне припущення на старті може зекономити 5 хвилин і коштувати кілька годин переробок.

Коли бізнес-логіка стає зрозумілою, починається технічний етап: потрібно визначити, які саме модулі в кодовій базі доведеться змінювати.

Кодова база — весь існуючий код проєкту.

У великих проєктах кодова база може складатися з тисяч файлів. Наприклад, кожні 20-30 файлів можуть бути окремим модулем системи. Тому важливо розуміти, де саме вносити зміни.

Іноді змінювати доводиться тільки один модуль. А іноді — кілька взаємозалежних модулів одночасно.

‍

‍

Імплементація. Найвідповідальніша частина

Починається друга половина дня. Далі — імплементація.

Імплементація — безпосереднє написання коду для реалізації функціоналу.

Кожна стрічка коду має бути продуманою. Розробник думає не тільки про те, щоб «воно працювало». Він враховує:

– чи не зламаються інші частини системи;
– як код вплине на швидкість роботи продукту;
– чи буде його легко зрозуміти іншим розробникам;
– чи вийде просто змінити цю логіку в майбутньому.

Розробник постійно балансує між швидкістю і якістю. Написати «щоб працювало» — недостатньо. Потрібно написати так, щоб це не зламало нічого іншого.

‍

‍

Тести та перевірки

Коли код написаний, наступний крок — тести.

Тести перевіряють, чи правильно працює нова логіка і чи не зламалися існуючі сценарії.

Після цього Олексій:

• перевіряє типи даних;
• запускає лінтери;
• проганяє тестовий набір;
• перевіряє фічу вручну.

Перевірка типів — це контроль того, щоб у функцію, яка працює з текстом, випадково не передали число або інший невідповідний тип даних.

Лінтер — інструмент для перевірки стилю та якості коду.

Тільки коли все працює стабільно, можна переходити до наступного етапу.

‍

‍

Pull Request і ревʼю

Олексій закінчив писати код. Але просто додати його в основну версію проєкту не можна.

Щоб працювати безпечно, кожен розробник створює окрему гілку — це як копія основного коду, у якій можна експериментувати і нічого не зламати для інших.

Коли задача готова, Олексій створює Pull Request (або скорочено PR).

Pull Request — це запит до команди:

«Я зробив зміни. Подивіться, будь ласка, чи все ок, і чи можна додати їх у основний код».

Тепер Олексій може очікувати код-ревʼю.
Код переглядають:

• розробники з команди Олексія;
• розробники з суміжних команд;
• іноді архітектори;
• а також — автоматичні боти (аналізатори коду).

Ревʼю — це не критика, а спосіб покращити якість рішення. Іноді це швидкий апрув. Іноді — кілька раундів коментарів і доопрацювань.

‍

‍

Кінець робочого дня. Мерж і завершення задачі

Коли зміни заапрувлені, Олексій мерджить гілку в main.

Main — основна гілка репозиторію, що містить актуальну версію продукту.

Merge — це додавання змін з гілки Олексія до основної версії продукту.

Після цього:

• задача закривається в Jira;
• зміни потрапляють у релізний процес;
• команда рухається далі.

І так — день за днем.

‍

‍

Що це означає для початківця?

Розробник — це не просто «людина, яка пише код». Це спеціаліст, який:

• розуміє бізнес-логіку;
• аналізує систему;
• приймає технічні рішення;
• відповідає за якість змін;
• працює в команді.

Навички, які допомагають найшвидше:

• аналітичне мислення;
• уважність до деталей;
• комунікація;
• системність.

Професія розробника — це постійне навчання, відповідальність і робота з невизначеністю. Але й велике задоволення, коли твоя фіча потрапляє в реальний бізнес і починає приносити користь клієнтам.

‍