Заходишь на проект не с нуля, какие действия

Первые действия при входе на существующий проект

При входе на проект, который уже работает в production, нужно действовать методично. Неправильные первые шаги могут привести к потере контекста и ошибкам.

День 1: Информационное погружение

1. Читаю документацию

- README.md (обзор проекта)
- docs/ (если есть)
- CONTRIBUTING.md (как вносить изменения)
- ARCHITECTURE.md или docs/architecture/ (если есть)
- .env.example (какие переменные нужны)

Если документации нет — это красный флаг. Спрашиваю у команды, где информация.

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

# Базовый порядок для Python проекта
git clone <repo>
cd project
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
# или для Poetry
poetry install

# Проверяю, что запускается
python manage.py runserver  # Django
uvicorn main:app --reload   # FastAPI
pytest                       # Тесты должны проходить

Если что-то сломалось — спрашиваю в чате, не тишу в одиночестве.

3. Смотрю git историю

# Последние 20 коммитов
git log --oneline -20

# Кто работал на проекте
git log --format='%h %an %s' | head -50

# Какие файлы чаще меняются
git log --format=%H -- | head -100 | xargs -I {} git diff-tree --no-commit-id --name-only -r {} | sort | uniq -c | sort -rn

Это показывает, где горячие точки кода.

4. Исследую structure проекта

project/
├── app/
│   ├── models/        # Бизнес-логика
│   ├── services/      # Use cases
│   ├── repositories/  # БД access
│   └── handlers/      # HTTP handlers
├── tests/
├── docs/
├── migrations/
└── requirements.txt

Оцениваю, соответствует ли это clean architecture или что-то custom.

День 2-3: Интеграция с командой

1. Встреча с tech lead или senior

Вопросы, которые задаю:

• Какие основные компоненты систему?
• Какие боли/проблемы в кодебазе?
• Какие parts критичные и требуют осторожности?
• Есть ли документация на design decisions?
• Какие technical debt известны?
• Как deploy работает?
• Как мониторинг и логирование?

2. Смотрю CI/CD

# Файлы для автоматизации
.github/workflows/
.gitlab-ci.yml
.circleci/
Jenkinsfile

# Что проходит перед merge
- Linter (ruff, flake8, pylint)
- Tests (pytest)
- Type checking (mypy)
- Coverage (должен быть > 80%)

Это показывает, какие standards у проекта.

3. Изучаю тесты

# Какой coverage сейчас
pytest --cov=app --cov-report=html

# Какие тесты медленные
pytest --durations=10

# Тесты ли падают
pytest -x  # Стоп на первой ошибке

Тесты — лучшая документация проекта.

День 3-5: Вклад в проект

1. Ищу простую задачу

Первый PR не должен быть большим. Нужно понять:

• Как работает review процесс
• Какие standards кодирования
• Как работает deployment

Примеры простых первых PR:

• Добавить тест для uncovered кода
• Исправить typo в документации
• Улучшить error message
• Добавить type hints

2. Создаю feature branch

# Правильное имя branch
git checkout -b feature/add-user-authentication
git checkout -b fix/broken-email-validation
git checkout -b docs/update-deployment-guide

3. Пишу маленький PR

# Пример: добавляю missing type hints
def get_user(user_id: int) -> User:  # Было: def get_user(user_id)
    return db.query(User).get(user_id)

В описании PR:

• Что я меняю и почему
• Как я тестировал
• Любые побочные эффекты

4. Жду code review

Первый feedback очень ценен. Это показывает:

• Какой style в команде
• Какие паттерны используются
• Как нужно мыслить в контексте этого проекта

Практический пример: Первая неделя

День 1 (Понедельник)

• Cloning проекта, запуск локально
• Читаю README, CONTRIBUTING, docs
• Встреча с tech lead (30 мин)
• Запускаю тесты, смотрю coverage

День 2 (Вторник)

• Изучаю git историю, вижу паттерны
• Запускаю локально, экспериментирую
• Встреча с разработчиками, обсуждаю архитектуру

День 3 (Среда)

• Первый PR: добавляю type hints в простой файл
• Code review, исправляю замечания
• Смотрю deployment процесс

День 4-5 (Чт-Пт)

• Несколько маленьких PR (документация, tests)
• Читаю code более сложных частей
• К концу недели: готов к реальным задачам

Red flags, на которые обращаю внимание

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

# Если это видим
code_coverage < 50%
# или даже вообще нет папки tests/

# Это значит:
# - Каждый refactor рискован
# - Много багов в production
# - Сложнее вносить изменения

2. Deprecated dependencies

pip check  # Проверяю, есть ли конфликты
pip list --outdated  # Есть ли очень старые версии

Если Django 3.2 (2021 год), то пора обновляться.

3. Отсутствие документации на архитектуру

Если я не могу найти ответ на "Как работает X?" в документации, это проблема.

4. Плохой код в main branch

# Если встречаю
data = eval(user_input)  # Security issue!
# или
import *  # Anti-pattern
# или
def process(x, y, z, a, b, c, d, e, f):  # Слишком много параметров
    pass

# Это говорит о том, что code review слабый

Мой чеклист для первой недели

• Проект запускается локально
• Тесты проходят
• Я прочитал основную документацию
• Я встретился с tech lead
• Я понял архитектуру (на 70%)
• Я создал первый PR (даже маленький)
• Я получил feedback и исправил
• Я знаю, как deploy работает
• Я знаю, где найти answer на основные вопросы
• Я готов к реальным задачам

Частые ошибки новых разработчиков

1. Спешить с крупными изменениями

# ❌ НЕПРАВИЛЬНО
# День 1: "Я вижу, что код плохой, переделаю всё".
# Результат: сломал что-то, не зная о побочных эффектах

# ✅ ПРАВИЛЬНО
# День 1: Читаю и понимаю
# День 3-5: Маленькие улучшения
# День 2+ недели: Более крупные изменения

2. Не спрашивать

Лучше спросить "глупый" вопрос, чем потратить 2 часа на угадывание.

3. Не смотреть на CI/CD

Тестирование в своей машине не гарантирует, что в production работает.

Заключение:

Вход на новый проект — это marathon, не sprint. Первая неделя для узнавания, вторая неделя для вклада. Спешить не нужно.