Принимал ли проект не с нуля

Опыт работы с legacy-проектами и code handover

Это важный вопрос для собеседования, так как большинство backend-разработчиков в своей карьере работают с уже существующими проектами, которые кто-то создал до них.

Типичная ситуация: получить проект "не с нуля"

Сценарий:

• Коллега уходит из компании
• Появилась новая задача в existing проекте
• Наследование старого legacy кода
• Включение в команду разработчиков
• Поддержка production системы

Что нужно сделать при handover проекта

1. Изучение кодовой базы

# Начальный анализ проекта
git log --oneline -10           # Последние коммиты
git log --stat --decorate main  # История изменений
git show <commit-hash>          # Что изменилось в коммите
git blame app.js                # Кто что писал

# Размер проекта
wc -l **/*.js                   # Количество строк
find . -type f -name "*.js" | wc -l # Количество файлов

2. Понимание архитектуры

# Структура проекта
tree -L 2 -I 'node_modules'    # Древовидное представление
ls -la                          # Главные файлы
cat package.json | grep -A 20 '"dependencies"'  # Зависимости

Вопросы которые нужно задать себе:

• Какой фреймворк используется? (Express, Fastify, NestJS?)
• Какая архитектура? (MVC, Layered, Microservices?)
• Какая БД? (PostgreSQL, MongoDB, Redis?)
• Есть ли тесты?
• Какие внешние сервисы интегрированы? (AWS, Google Cloud, stripe?)

3. Запуск проекта локально

# Установка зависимостей
git clone <repo-url>
cd project
npm install

# Проверка версии Node.js
node --version
npm --version

# Настройка env файлов
cp .env.example .env           # Или попросить .env

# Запуск в development режиме
npm run dev

# Проверка на ошибках
npm run lint
npm test

# Build production
npm run build

4. Документация и знания

Что найти и прочитать:

• README.md — базовая информация
• ARCHITECTURE.md или docs folder — структура проекта
• DEPLOY.md или CONTRIBUTING.md — как разворачивать
• Комментарии в коде — особенно в сложных местах
• Git history — почему были сделаны определенные решения
• Backlog/Issues — какие проблемы известны

5. Общение с предыдущим разработчиком

Какие вопросы задать:
1. Архитектурные решения: почему так, а не иначе?
2. Известные проблемы (technical debt)?
3. Как деплоится в production?
4. Какие критичные части требуют осторожности?
5. Что планируется в ближайшем будущем?
6. Какие инструменты нужны? (Postman, DB client, etc?)
7. Как поднять development окружение?
8. Как подключиться к staging/production?
9. Как работает CI/CD?
10. Кто ответит на вопросы по бизнес-логике?

Типичные проблемы legacy кода

1. Отсутствие тестов

// Плохо: функция без тестов, непонятно что она делает
function processOrder(order) {
  if (order.items.length === 0) return null;
  
  let total = 0;
  for (let i = 0; i < order.items.length; i++) {
    total += order.items[i].price * order.items[i].quantity;
    if (order.items[i].discount) {
      total *= (1 - order.items[i].discount / 100);
    }
  }
  
  // Есть ли налоги? Где они применяются?
  // Какие граничные случаи?
  return total;
}

// Хорошо: с тестами
test('should calculate order total with discounts', () => {
  const order = {
    items: [
      { price: 100, quantity: 2, discount: 10 }
    ]
  };
  
  const result = calculateOrderTotal(order);
  expect(result).toBe(180); // 200 - 20 discount
});

2. Слабая документация

// Плохо: непонятный код
const cache = {};
const ttl = 3600;
const prefix = 'user:';

// Хорошо: понятный код с комментариями
const userCache = {}
  // TTL в секундах для user кэша
  const USER_CACHE_TTL_SECONDS = 3600;
  const CACHE_KEY_PREFIX = 'user:';
  
  /**
   * Получить пользователя из кэша
   * @param {string} userId - ID пользователя
   * @returns {User | null} - User объект или null если истек TTL
   */
  function getCachedUser(userId) {
    // ...
  }

3. Не соблюдаются стандарты

# Проверить что используется
cat package.json | grep -E "eslint|prettier|husky"

# Запустить linter
npm run lint

# Форматировать код
npm run format

# Или установить если нет
npm install --save-dev eslint prettier husky

4. Производственные долги (technical debt)

// Пример: нужно переделать
// TODO: Этот код очень медленный, нужно оптимизировать
// FIXME: Есть баг при пустом значении
// HACK: Временное решение, нужно переделать правильно
// DEPRECATED: Используй newFunction вместо этой

// Найти все такие места
grep -r "TODO\|FIXME\|HACK" src/

Практический план включения в проект

Неделя 1: Понимание

• Запустить проект локально
• Пройтись по основным файлам
• Запустить тесты
• Встреча с предыдущим разработчиком
• Прочитать документацию

Неделя 2: Первая задача

• Выбрать простую задачу (bug fix лучше всего)
• Написать тест для этой задачи
• Реализовать fix
• Запустить все тесты
• Создать PR и получить review

Неделя 3-4: Углубление

• Изучить критичные части кода
• Понять CI/CD процесс
• Работать над более сложными задачами
• Задавать вопросы

Взаимодействие с историей проекта

# Понять почему было сделано так
git log --grep="key phrase" --oneline

# Просмотреть коммит с комментариями
git show <hash>

# Кто последний трогал файл?
git log -p --follow -- src/users/handler.js

# Когда был внесен bug?
git bisect start
git bisect bad HEAD
git bisect good v1.0

Как задавать вопросы

Плохо: "Что делает эта функция?"

Хорошо: "Я вижу что функция processOrder вычисляет total, но непонятно:

1. Как применяются налоги?
2. Есть ли максимальный лимит скидки?
3. Почему здесь используется вложенный цикл?"

Типичные метрики для нового разработчика

1-2 недели: Базовое понимание структуры
2-4 недели: Может исправлять простые bugs
1-2 месяца: Может брать регулярные задачи
2-3 месяца: Полностью интегрирован в процесс
6 месяцев: Может mentorить новичков

Инструменты для анализа проекта

# Красивая статистика
git log --stat

# Кто сколько написал
git log --shortstat --summary | grep "files changed"

# Анализ сложности кода
npm install -g complexity-report
complex-report -d src

# Зависимости между модулями
npm install -g depcheck
depcheck

Заключение

Работать с существующим проектом — это нормальная ситуация в профессиональной разработке:

1. Это не стыдно — почти все проекты legacy в какой-то степени
2. Требует терпения — понимание кодовой базы занимает время
3. Развивает навыки — нужно быстро адаптироваться
4. Ценится в industry — способность быстро onboard в существующий проект очень котируется

Хороший разработчик может быстро:

• Разобраться в чужом коде
• Внести изменения без регрессий
• Улучшить кодовую базу
• Передать знания другим

Это важная компетенция для backend-разработчика!