З'ясуйте стек, розгорніть локально, знайдіть техборг. Як безболісно передати та отримати проєкт
Привіт! Мене звуть Антон Яценюк, я працюю на позиції Front-end Competence Lead в компанії Rolique. Пишу код, веду проєкти — переважно на початкових етапах допомагаю організувати роботу команд, розважаю та розвиваю їх, а до COVID-19 кілька разів виступав на невеликих мітапах та конференціях, які присвячені JavaScript.
Ця стаття — про те, як зробити передачу/отримання проєкту great again. Вперше описані тези я озвучив на ChernivtsiJS 2018. Стаття буде корисна молодим командам, які ще не пройшли всі перешкоди на своєму шляху, або лідерам команд, які тільки опановують цю роль.
Я постарався зібрати та структурувати те, що ми найчастіше використовуємо під час отримання проєкту, й те, про що найчастіше забуваємо. Це необхідний мінімум для того, щоб максимально швидко та безболісно для всіх учасників передати/отримати проєкт.
Як боротися з кодом, який написали інші люди в іншій галактиці? Як швидко опанувати проєкт, якщо в нього «hype stack» технологій? Як швидко знайти технічний борг? На ці питання відповідей не буде. Натомість будуть поради, які кожен може спробувати адаптувати під власну ситуацію та отримати з них користь для себе.
Дисклеймер: рекомендації, наведені в публікації, сформовані через особистий досвід і протестовані, але не претендують на звання посібника з успішної передачі ІТ-проєктів.
Завжди дізнавайтесь повний технологічний стек
Зазвичай вам не кидають проєкт і не кажуть щось на кшталт: «Дописуйте функціонал тут і щоб він був такий...» (якщо це відбувається саме так, мені вас шкода). Перед тим, як ви зможете побачити його, мине кілька тижнів листувань, співбесід, попередніх інтерв’ю. Коли до вас прийде Sales Manager чи Project Manager сказати, що скоро дзвінок з потенційним клієнтом щодо проєкту, поставте їм основне питання — який повний технологічний стек?
Це допоможе добре підготуватися до співбесіди чи просто розмови та оцінити ваші сили — як швидко ви зможете почати релізити функціонал, а не витрачати тікети на investigation чи освоєння нових технологій.
У мене ситуація була такою: зайшов проєкт і нашій команді оголосили стек — React, Node.js, MongoDB. Попередили, що буде співбесіда. І на ній уже показали справжній стек проєкту. Він нас трохи шокував, бо досвіду в цих технологіях, м’яко кажучи, бракувало.
Отже, реальний стек проєкту: React, Node.js, MongoDB, AWS S3, AWS Lambda, Docker, Redis, TypeScript, MobX, Fetch, Shell scripts (а як виявилося ще пізніше, і це не було повним стеком).
Розгортайте проєкт локально, щойно отримали до нього доступ
Рівень проєктів, їхньої документації та організації Developer Experience за останні 5 років значно поліпшився. Зараз рідко натрапиш на проєкт без README-документа з чіткими кроками «як поставити цей корабель на воду». Проте, як і завжди, бувають винятки.
Чому важливо розгортати проєкт одразу? Відповідь проста: тоді у вас ще є можливість комунікувати з попередньою командою. Якщо щось піде не так (а ймовірність цього висока), вам є в кого попросити допомоги. Якщо всі мости вже спалено, всі контракти перепідписано й усі розійшлися по світу, а вам завтра потрібно починати новий спринт і ви розумієте, що просто не можете локально підняти проєкт, це означає одне — ви залишилися наодинці з цією проблемою.
Які труднощі виникли з вищезгаданим проєктом:
- проєкт запускався лише на версії Node v6.10.11;
- @typings для react-router мали бути версії v0.14.17;
- docker machine, який ми мали використати, розташовувався в іншому репозиторії (на особистому акаунті іншого розробника), до якого ми б ніколи не отримали доступ;
- багато додаткової, але дуже потрібної нам інформації не було взагалі задокументовано. Розробники «просто це знали», для них це був локальний common sense.
На іншому проєкті, який наша команда теж отримала в спадок, ми витратили ~30 годин, тільки щоб підняти всю мікросервісну архітектуру локально. Запускався проєкт лише на машині з 16GB RAM.
Отже, що раніше ви почнете цей процес, то швидше зможете:
- скласти список проблем і запитань, з якими звернетесь до попередньої команди;
- задокументувати всі відповіді хоча б в README і спростити життя собі та людям, які приєднаються до команди пізніше;
- створити хорошу базу для повноцінної документації/Wiki проєкту.
Що треба знати, щоб працювати над проєктом
Час, коли клієнти шукають просто голову та руки, які писатимуть код, що задовольняє Acceptance Criteria, для більшості компаній навіть на локальному ринку минув. Інженерна культура набирає обертів і в Україні. Клієнт починає шукати не тільки людей, які кодять, а й тих, хто може допомогти бізнесу проаналізувати, чи справді йому потрібен цей код, чи можна зробити щось по-іншому тощо. Це все ще залишається в межах технічної відповідальності, але ці межі значно розширились.
Саме тому, коли починаєте новий проєкт, вам як інженеру важливо зрозуміти правильні відповіді на такі прості запитання:
- Що робить бізнес клієнта?
- Як він це робить?
- Для чого він це робить?
- Для кого він це робить?
З Project X нам пощастило провести три дні з клієнтом офлайн, під час яких він зробив презентацію бізнесу, пояснив, з чого вони починали, та навіть розповів коротку особисту історію. Це допомогло нам краще познайомитись і полегшило подальшу комунікацію, а найважливіше — дало відповідь на всі вищезазначені питання. Ми змогли довести, що долучилися не просто для того, щоб писати код, а щоб стати їхнім технічним партнером.
Саме такі примітивні питання дадуть змогу швидко і за короткий час зрозуміти суть бізнес-домену, роль проєкту та які проблеми він вирішує. І добре побудувати його з технічного боку, підвищити рівень співпраці з клієнтом. Де кінцевий результат — якісно наданий сервіс і клієнтський досвід, а не коміти. Принаймні ми працюємо саме за такою моделлю.
Pair programming
Цей пункт допоможе набагато швидше зрозуміти кодову базу проєкту, зв’язки та бізнес-логіку. Це ефективний прийом, яким багато команд нехтує. Ми використовуємо його навіть у межах однієї команди на тривалих проєктах, так зони відповідальності не замикаються на одній людині.
Щоб почати парне програмування з командою, котру ви бачите вперше, яка, найімовірніше, з іншої культури та розмовляє іншою мовою, треба докласти зусиль, застосувати soft skills, вище ми вже говорили про інженерну культуру :) Повірте, це зекономить вам десятки годин, які дуже критичні на початку нової співпраці.
Усе зводиться до того, чи зможете ви організувати pair programming сесії, оскільки ентузіазму від попередньої команди розробників годі чекати, але знов-таки тут головне — вміння комунікувати.
Одразу зазначу: якщо інша команда відмовилася, це не трагедія. Просто вам доведеться витратити трохи більше часу на те, що в народі називають «просто дивитися код» :)
Варто не забувати, що ці сесії для вас слугуватимуть і як Q/A-сесії, де можна додатково дізнатись усе, що цікавить з технічної частини.
Code review
Завершуючи співпрацю з минулою командою, потрібно домовитись про review вашої роботи у перші кілька тижнів. Тут усе впирається в те, щоб правильно прокомунікувати цей момент.
У будь-якому разі можна укласти окремий контракт з командою чи кимось з інженерів. І краще вам заплатити за цей час зараз, щоб потім не довелося витрачати удвічі більше годин понаднормово для клієнта після першого ж проваленого дедлайну.
Із Project X ми без зусиль змогли домовитися про два місяці code review з інженерами попередньої команди. Вони охоче погодились і давали нам корисні поради весь цей час. Навіть про такі банальні речі, як внутрішні утиліти, про які ми тоді не здогадувались. Завдяки цьому не довелося створювати схожі утиліти вдруге (що ми, власне, і намагались робити в перший тиждень).
Зберіть всю інфраструктуру «в одні руки»
Хтось із вашої команди має одразу пройтись по всіх доступах, ключах, сторонніх API, з якими працює система, CI/CD тощо і перевести абсолютно все на акаунти клієнта або акаунти вашої компанії.
У нас була ситуація, коли через п’ять тижнів роботи над новим проєктом, який ми отримали в спадок, клієнт звернувся з проблемою, що не працює ключовий функціонал (ніби буває неключовий). Посеред «пожежі» лише за кілька годин ми зрозуміли, що S3 bucket, який використовувався в ньому, був на акаунті одного з інженерів попередньої команди і він того дня вирішив просто його закрити.
Золоте правило всіх проєктів — фіксуйте версії
Щоб новий сетап був безболісним і максимально ефективним, потрібно одразу правильно зафіксувати всі залежності в робочому проєкті.
Проте не забувайте й про оновлення, бо часто їх роблять раз на рік або й взагалі не роблять. Тим паче, коли команда розуміє, що скоро припинить роботу з цим проєктом, то заморочуватись з оновленнями залежностей ніхто не стане.
Оновлення важливі, бо ви отримуєте нові можливості, виправлення помилок минулих версій, інші оптимізації.
Тільки після того, як ми оновили всі залежності, наш front-end build став відбуватися майже утричі швидше й основний bundle зменшився в розмірі на 20%. Без жодного рефакторингу та оптимізацій у наших конфігураціях.
Я прихильник думки, що фікс версії будь-якої залежності одразу створює технічний борг. Що частіше ви будете підтримувати та приймати оновлення — то краще.
Знайдіть технічний борг
На це потрібен час, але ви повинні знайти технічний борг у перші місяці роботи. Так зможете легше планувати новий функціонал чи зміни в наявному. Ще це допоможе скласти рефакторинг-план і почати його імплементувати. Те саме стосується даних, з якими працюєте щодня.
БД може бути спроєктована під MVP-реліз, а проєкту скоро два роки і у вас десятки тисяч користувачів. Вам необхідно виділяти час на ці речі, а не намагатися притулити ваш новий бездоганний код до того, що є (не такого бездоганного, як ваш, звісно :), просто тому, що йде спринт.
Підсумуємо
Варто вчитися на чужих помилках і намагатися з першого ж дня надавати якомога якісніший сервіс клієнту. Навіть ваші пропозиції щодо комунікації з попередньою командою не залишаться непоміченими для клієнта. У майбутньому, коли вам потрібен буде, наприклад, час на рефакторинг, це матиме значення.
Я погоджуюся, що проблеми зі списку очевидні й банальні, але вони банальні лише тоді, коли ви самі пройшли через усе це. Коли ми з командою були залучені до таких процесів, наш середній досвід ледве перевалював за два з половиною роки (а досвід прямої комунікації з клієнтами був ще менший). І це не так багато навіть для локального IT (привіт сеньйорам з чотирма роками досвіду).
У дискусії на цю тему мені поставили дуже цікаве питання: «Якщо клієнт шукає нову команду, це означає, що попередня максимально облажалася і її вирішили позбутись. Не страшно брати такі проєкти?».
Проєкт, на основі якого були побудовані ці правила, мав трішки іншу історію, минула команда просто розпалась, усі пішли займатися власними стартапами. Хоча якби нам у руки потрапив бездоганний проєкт, де просто «запустив і працюєш», то деяких пунктів у списку не було б :)
Бажаю всім швидкої та якісної передачі проєктів!
