2021-11-19 11:20:10
Якість коду — відповідальність розробників. Як Grammarly працює без QA-інженерів Grammarly — головний ньюзмейкер тижня. Днями компанія випустила безкоштовний десктопний застосунок для Windows і Mac, а вчора оголосила про раунд інвестицій, який підняв оцінку компанії до приголомшливих $13 млрд.
Grammarly розробляє платформу штучного інтелекту для покращення англомовних текстів. Сервіс об’єднує онлайн-редактор, розширення для браузерів, десктопні застосунки тощо. Щоденно продуктами компанії користуються 30 млн людей.
В Grammarly працює понад 600 людей. Посади QA-інженера у компанії немає: тестуванням займаються безпосередньо самі розробники продуктів та функцій. У компанії стверджують, що це дозволяє вчасно виявляти більшість технічних проблем і пришвидшувати релізи.
11 листопада компанія проводила онлайн-мітап, де техлід фронтенд-команди Олексій Левжинський розповів про процес розробки у Grammarly. SPEKA обрала найцікавіше.
Спочатку команда продакт-менеджерів формулює
ідею. Потім разом із дизайнерами визначає
специфікацію — вимоги до нової фічі або продукту. Коли є загальне розуміння, що ми хочемо зробити і в якому вигляді, до обговорення долучаються інженери-розробники і надають перший фідбек стосовно того, наскільки складно буде реалізувати задумане. Наприклад, вони можуть сказати: «Наразі ми проводимо глобальний рефакторинг і не маємо ресурсів для оперативного розроблення запропонованої фічі. Але за кілька місяців ми зможемо швидко її втілити разом із низкою інших нових функцій».
Коли специфікація готова, інженери разом із продакт-менеджерами переходять до
планування і розбивають завдання на окремі майлстоуни. Зазначу, що у Grammarly зазвичай немає жорстких дедлайнів, тож інженери мають певну свободу у визначенні термінів розробки.
Після планування запускається процес реалізації. Його розпочинає
архітектурне рев’ю. Група інженерів докладно вивчає, яким чином запланована фіча вплине на загальну архітектуру. Якщо йдеться про масштабні зміни, до рев’ю долучаються розробники суміжних проєктів Grammarly і діляться власними рекомендаціями.
Далі ми, нарешті, розпочинаємо
написання коду. Процес відбувається одночасно із тестуванням: програмісти одразу розробляють
юніт-тести для перевірки простих елементів. Також ми використовуємо
інтеграційні тести — комбінуємо окремі модулі програми і випробовуємо їхню взаємодію.
Найважливіший момент —
наскрізне тестування, коли ми кілька разів запускаємо програму в браузері, робимо скриншоти і пересвідчуємося, що вони виглядають однаково. Також перевіряємо, чи не розповзлася верстка.
Фінальний етап імплементації —
код-рев’ю та дослідницьке тестування. Ми виділяємо сервер під кожну гілку, рев’юєри можуть перейти за посиланням і впевнитися, що все працює як треба.
Потім відбувається або
реліз фічі одразу на 100% користувачів, або ж попереднє
А/Б-тестування. У другому варіанті, якщо нашим юзерам не сподобалися зміни, ми можемо повернутися до будь-кого етапу, навіть переробити специфікацію.
Коли продукт виходить у продакшн, ми розпочинаємо
моніторинг: збираємо метрики щодо багів у різних браузерах, мобільних клавіатурах тощо. Якщо помилок забагато, робимо багфікс або відкочуємо зміни.
327 views08:20