Як приймати проєкт після іншої команди
Підхопити чужий проєкт — це не «розібратись у коді». Це відновити знання, яких ніхто не записав, і зробити систему передбачуваною раніше, ніж вас попросять додати функцію. Ось послідовність, яка працює.
Крок 0: доступи, і саме всі
До того як відкрити редактор, зберіть повний список: репозиторій, реєстр образів, сервер, база, DNS, домен, поштовий провайдер, платіжний шлюз, аналітика, сховище файлів, CI. Кожен пункт має бути на ваш обліковий запис або на акаунт замовника, а не на особисту пошту людини, яка пішла.
Це найнудніший крок і найчастіша причина зупинки через місяць: домен продовжується з картки колишнього підрядника, і в день закінчення сайт зникає.
Крок 1: запустити локально, з нуля, за інструкцією
Мета — не «запрацювало на моїй машині», а відтворюваний запуск: свіжа копія репозиторію, описані змінні середовища, одна команда. Усе, що ви робили руками, щоб воно піднялось, — це те, чого немає в документації. Запишіть це одразу, поки пам’ятаєте.
Якщо локально підняти неможливо, це перший ризик у звіті. Проєкт, який існує лише на проді, не можна ані змінити безпечно, ані відновити після збою.
Крок 2: аудит, який читає замовник
Технічний аудит для замовника — це не список зауважень до коду. Це список ризиків із наслідками й приблизною вартістю. Розділіть на три групи:
- Може зупинити бізнес. Немає бекапів. Секрети в репозиторії. Термін дії сертифіката без автопродовження. Залежність, яка більше не оновлюється.
- Сповільнює будь-яку зміну. Немає тестів. Немає локального запуску. Логіка продубльована в трьох місцях. Міграцій немає, схему правили руками.
- Косметика. Стиль коду, назви, структура папок.
Третю групу не чіпайте перші місяці. Рефакторинг заради краси на незнайомому коді — це найшвидший спосіб зламати те, чого ви ще не розумієте.
Перше завдання нової команди — не покращити код, а зробити систему передбачуваною. Красивою вона стане потім.
Крок 3: стабілізація
Порядок тут майже завжди однаковий:
- Бекапи з розкладом і перевіркою відновлення. Відновіть базу в тестове середовище й переконайтесь, що дані на місці.
- Моніторинг і сповіщення. Поки ви не бачите падінь, ви дізнаєтесь про них від замовника — це найдорожчий канал.
- Секрети з коду в середовище. Заодно ротуйте: усе, що лежало в репозиторії, вважайте скомпрометованим.
- CI із лінтом, типами й збіркою. Навіть без тестів це ловить половину випадкових поломок.
- Тести на найважливіший сценарій. Один e2e на оплату або на заявку вартий сотні юніт-тестів на утиліти.
Крок 4: перша функція
Беріть маленьку, але наскрізну: від форми до бази й назад. Вона покаже реальний стан усіх шарів краще, ніж тиждень читання коду. І дасть замовнику видимий результат, поки ви робите невидиму роботу зі стабілізації.
Як говорити із замовником
Дві помилки, обидві дорогі. Перша — сказати «тут усе погано, треба переписати». Це майже завжди неправда й завжди звучить як спроба продати більший чек. Друга — мовчки гасити пожежі, показуючи нуль прогресу за перший місяць.
Робочий варіант: звіт із трьома групами ризиків, оцінка кожного пункту й запропонований порядок. Замовник ухвалює рішення, а не отримує вирок. І кожні два тижні — коротке «зробили це, залишилось те».
- Доступи збирають до того, як відкривають редактор
- Відтворюваний локальний запуск важливіший за читання коду
- Аудит — це ризики з наслідками й ціною, а не зауваження до стилю
- Косметичний рефакторинг на незнайомому коді відкладають на місяці
Для середнього проєкту — від трьох днів до двох тижнів, залежно від того, чи вдається підняти його локально. Головний множник — не обсяг коду, а кількість недокументованих ручних кроків.
Коли вартість однієї зміни перевищує вартість написання заново, і це видно на кількох задачах поспіль. До того це припущення, а не висновок.
