Шість правил, які допоможуть позбутись затримок під час backend-розробки

Привіт! Я — Каталін Драгутеску, Full Stack Engineer у Railsware. Заздалегідь відповім на ваше питання: так, я не українець (привіт з Румунії!). Утім, багато чув про спільноту DOU і хотів би поділитися з вами своїми думками. Тому я написав, а колеги люб’язно переклали цю статтю.

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

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

Багато людей =/= швидкі зміни

Підвищення продуктивності команди — той випадок, коли сказати простіше, ніж зробити. Для кращого розуміння наведу приклад із власного досвіду.

Ми з командою працювали над великим продуктом, який вже мав частку на ринку. Тоді наша стратегія включала два основні напрямки:

1. збереження якості та доступності наявних послуг для стабільного росту;
2. експериментування з новими напрямами бізнесу.

Команда була досить компактною: чотири розробники, продакт-менеджер та QA-інженер. Тому ми вирішили залучити ще спеціалістів. Щоб працювати над додатковими проєктами, але не втрачати якості роботи та контролю над дрібними помилками. Утім, найм нових людей не розв’язав нашу проблему.

Ми помітили, що навіть з приходом нових спеціалістів (мідлів та сіньйорів) загальна продуктивність команди не зросла. Спочатку припускали, що причина в часі, необхідному новачкам, щоб ознайомитись з проєктом. І це, звісно, частково правда. Проте, пізніше виявили: справа у значному дефіциті чіткої документації. Через це колег постійно «смикали» за допомогою, тому вони почали дратуватися. Також це затримувало роботу інших розробників, які витрачали більше часу на онбординг.

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

Як полегшити онбординг

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

1. Доступна документація процесів. Нову функціональність чи зміну варто описати на зручній для вас платформі. Коли до неї матимуть доступ усі члени команди, кожен з них зможе швидко використовувати довідник. Також спробуйте зробити те саме й для старих функцій, щоб уникнути ситуації «Мабуть, це просто так працює».

Для створення README можна використовувати GitHub. Там ви можете детально та стисло описати всі необхідні кроки для розробників, щоб «запустити» нові функції. Також рекомендую використовувати Swagger/API документацію, яка буде поширена серед всієї команди.

Для опису функціональності для клієнтів можна використовувати Zendesk. Це допоможе вашим юзерам краще зрозуміти, як користуватися певною функцією через користувацький інтерфейс. Таким чином вдасться забезпечити повна доступність та зрозумілість інформації як для команди розробників, так і для клієнтів.

2. Спростіть налаштування проєкту. Найпоширеніший спосіб — це контейнеризація застосунку, але існують й інші варіанти. Головне, щоб проєкт запускався на будь-якій операційній системі без конфліктів з встановленими сервісами. Це налаштування також має містити всі облікові записи для зовнішніх сервісів, якщо це можливо, або кроки для їхнього створення.

3. Будьте в курсі оновлень. На жаль, коли ви вже добре ознайомлені з проєктом, досить легко не помітити та ігнорувати апдейти. Не забувайте: той, хто переглядає документацію, ніколи раніше не користувався вашим продуктом. Тому звертайте уваги на оновлення інструментів, вимог та сервісів. Бо ніхто не хоче втрачати час на застарілі бібліотеки. Для цього раджу використовувати інструменти контролю за оновленнями. Це можуть бути dependabot, AIKIDO, Depfu чи Snyk. Вони допомагатимуть вам стежити за проблемами безпеки й слідкувати за загальними оновленнями залежностей.

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

Це не магічні рішення, але вони полегшать старт роботи над проєктом, принесуть довгострокові переваги та підвищать надійність.

Оптимізація процесу розробки

1. Налаштування робочого процесу: знайомство з описом завдання, критеріями «прийняття» (acceptance criteria)
2. Розробка рішення завдання
3. QA/тестування
4. Деплоймент
5. Вимірювання результатів
6. Моніторинг помилок

Крім того, раджу не забувати, що навіть Agile — це всього-на-всього набір ідей та принципів, які справді можуть вам допомогти, але не розвʼяжуть всі ваші питання. Тому пропоную кожен процес максимально оптимізувати та шукати інструменти й стратегії, які допомагатимуть вашій команді найбільше.

Налаштування робочого процесу

Наведу дуже простий приклад. У вас є інтерфейс з таблицею, що відображає певну інформацію про користувачів. Вам потрібно додати кнопку для експорту цих даних. Ви можете описати це завдання як «додати кнопку експорту до таблиці» і, можливо, навести одну-дві вимоги або обмеження.

Але можна також сформулювати його як «як адміністратор даних, я хочу мати можливість експортувати інформацію з таблиці Х». У цьому випадку історія краще передає інформацію про те, хто цей користувач і що він хоче зробити. Що дозволяє розробнику мати більше свободи у виборі способу реалізації завдання, а не просто фокусуватися на створенні кнопки.

Розробка рішення завдання

На цьому етапі кілька інструментів допоможуть вам зробити код кращим і зрозумілішим для всієї команди. А також — швидше вносити зміни в проєкт у майбутньому.

Налаштуйте автоматичне тестування

• тести для окремих функцій,
• для контролерів,
• для перевірки взаємодії між різними частинами коду,
• для візуальної частини тощо.

Кращий варіант: вони запускаються із кожним пул-реквестом чи апрувом. Проте також можете виконувати нічні збірки для складніших завдань. Є дуже практичні інструменти для запуску ваших тестів — CircleCI або Jenkins. Оскільки після запуску всі вони будуть використовуватись та зберігатись на хмарі, можна просто визначити певний набір правил та забути про них.

Щодо інструментів для написання тестів. У кожному фреймворку повинно бути щось корисне та поширене, яке можна використовувати. Наприклад, у Rails є rspec. Це досить потужний інструмент з великою кількістю додаткових можливостей, тому ми використовуємо його здебільшого для модульних тестів. Але його також можна розширити функціями для інтерфейсних тестів. Він допоможе вам зручно створювати описи для тестів. Тобто коли один тест виявиться невдалим, ви матимете змогу точно зрозуміти, що саме пішло не так за форматом: опис функціональності як пояснення контексту, як повинно поводитися. Якщо запровадите тести для документації, раджу узгоджувати їх разом з кодом.

Щодо fron-end та end-to-end тестування, я б обрав щось на кшталт Playwright. Він полегшує запуск тестів на різних браузерах та конфігураціях, а також допомагає писати сценарії для них. Це зручний інструмент, який можуть використовувати як розробники, так і QA-інженери.

Включіть інструменти статичного аналізу

Існує декілька категорій, хоча іноді один інструмент може виконувати декілька функцій:

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

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

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

Ідея полягає в тому, щоб ці інструменти працювали автоматично, виконуючи перевірки при кожній зміні коду. Тоді не доведеться окремо звертатись до тестувальників і дізнаватись, що інженер виявив загрозу SQL-ін’єкції — більшість інструментів виявлення вразливостей можуть попередити про це.

QA, deploy, вимірювання

У тестуванні немає нічого визначеного. Утім, наявність тестового середовища, яке можна легко створити та видалити, грає важливу роль. Це повертає нас до моєї попередньої думки про легке налаштування проєкту. Важливими є також початкові дані. Вам слід мати стандартні дані для будь-яких комбінацій функцій. Створивши один раз, ви будете використовувати їх і в майбутньому, що заощаджуватиме вам час. Крім того, важливою є можливість проведення тестів кількома тестувальниками одночасно.

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

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

Можу запропонувати кілька таких фреймворків. Наприклад, AWS Beanstalk, AWS Cloudformation або така інтеграція інфраструктури, як CircleCI. Оскільки ваша кінцева мета — визначити свою інфраструктуру як код, а не використовувати список команд чи вручну вживати заходів. Тому підхід «інфраструктура як код» повинен містити документацію щодо того, що робить кожен крок. Щоб було легше зменшувати кількість помилок або дефектів.

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

Щодо вимірювання результатів, мені подобається дивитися на це з двох сторін: що ви використовуєте і як ви це використовуєте. Почнімо з останнього, щоб легше було описати перше. Будь-яка ваша робота повинна мати очікуваний результат. Це може бути збільшення користувачів на сторінці, кращий коефіцієнт конверсії у воронці або покращення продуктивності. Для вимірювання кожного з цих результатів, ймовірно, потрібні різні інструменти. Однак найважливіше — як ви їх використовуєте.

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

Відстежування збоїв/дефектів

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

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

Що можна зробити? Встановіть «періоди тиші» для сповіщень. При цьому можна скористатися інструментами Honeybadger, Datadog або ScoutAPM, які дають можливість надсилати сповіщення різними шляхами. Також можна розглянути створення у Slack окремих каналів для сповіщень залежно від серйозності помилки. Це допоможе зосередитися на важливому і сприятиме зручному сприйняттю інформації.

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

Висновок

Насамкінець хотів би підкреслити, що наша мета — це постійні, надійні результати, а не швидкі розв’язання проблем. У цій статті я спробував розглянути широкий спектр способів покращення роботи, що підійде для будь-якої команди. Раджу вам експериментувати та вдосконалювати свій процес за цими порадами.

Пам’ятайте: для хороших спеціалістів немає межі у покращенні результатів.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті