Какие будут первые шаги при подключении к проекту который уже в разработке?

Первые шаги при подключении к проекту в разработке

Онбординг в существующий проект требует систематического подхода. За 7 лет разработки я выработал четкий процесс.

День 1: Основы

Получить доступ:

• GitHub репозиторий
• Документация (внутренняя wiki, Notion, GitHub wiki)
• Ссылка на deployment окружение
• Доступы к инструментам (Jira, Slack, etc)

Запустить проект локально:

# Клонировать и установить
git clone https://github.com/company/project.git
cd project
pip install -r requirements.txt
pip install -r requirements-dev.txt

# Подготовить БД
python manage.py migrate
python manage.py createsuperuser

# Запустить
python manage.py runserver

Если что-то не работает — сразу спрашиваю помощь. Это нормально.

День 2-3: Понимание архитектуры

Основной goal — понять как работает application:

# Основные папки
ls -la

# README
cat README.md

# Главный use case (например, создание заказа)
# Читаю путь: API -> Service -> Model -> Database

Создаю документ с диаграммой в голове:

API Request (POST /api/v1/orders)
    ↓
OrderCreateView (presentation layer)
    ↓
CreateOrderService (application layer)
    ↓
Order.create() (domain layer)
    ↓
OrderRepository.save() (infrastructure layer)
    ↓
PostgreSQL Database

День 3-5: Окружение разработчика

Команды для разработки:

# Посмотреть доступные команды
make help

# Или в Makefile
cat Makefile

# Типичные команды
make test              # Запустить тесты
make lint              # Проверка стиля (black, isort, flake8)
make format            # Автоформатирование
make migrate           # Применить миграции
make seed              # Загрузить тестовые данные

Инструменты в проекте:

• Python framework (Django, FastAPI, Flask?)
• Database (PostgreSQL, MySQL, SQLite?)
• ORM (SQLAlchemy, Django ORM?)
• Testing (pytest, unittest?)
• Task queue (Celery, RQ?)
• Cache (Redis?)

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

Выбираю маленькую задачу:

• Баг фикс (low hanging fruit)
• Простая фича (добавить поле в API)
• Улучшение документации
• Написание тестов для существующего кода

Избегаю:

• Архитектурные переделки
• Миграция на новый фреймворк
• Сложные feature flags

Мой workflow:

# 1. Создаю ветку
git checkout -b feature/my-task

# 2. Читаю код и старые тесты
grep -r "related_functionality" src/

# 3. Пишу тест (TDD)
# tests/unit/test_my_feature.py
def test_my_feature():
    result = my_function(input)
    assert result == expected

# 4. Реализую функцию
# src/application/my_service.py

# 5. Запускаю тесты
make test

# 6. Проверяю стиль
make lint
make format  # Если нужно

# 7. Коммитчу
git commit -m "feat: add my feature"

# 8. Пушу
git push origin feature/my-task

Неделя 2: Code Review и изучение

Делаю code review других PR:

• Учусь на best practices
• Задаю вопросы в комментариях
• Понимаю как разработчики пишут код

Участвую в дизайн сессиях:

• Слушаю как принимаются архитектурные решения
• Позже буду вносить свои идеи (когда лучше разберусь)

Знакомлюсь с людьми:

• Team Lead — что я буду делать
• Tech Lead — архитектурные вопросы
• DevOps / Infra — как развернут проект
• QA — процесс тестирования
• Product Manager — требования

Неделя 2-3: Углубленное изучение

Изучаю важные компоненты:

# Как работает аутентификация?
grep -r "authenticate" src/

# Как работает авторизация?
grep -r "permission" src/

# Как работает кеширование?
grep -r "cache" src/

# Как работает очередь задач?
grep -r "celery" src/

Задаю вопросы в Slack:

• "Почему вы выбрали вот этот подход вместо альтернативы?"
• "Есть ли техдолг в модуле X, который я должен знать?"
• "Можешь объяснить почему здесь вот так сделано?"

Неделя 3-4: Независимая работа

К этому времени я должен:

• Браться за задачи средней сложности самостоятельно
• Знать куда добавить новый код
• Писать тесты для своего кода
• Давать полезные code review
• Знать как deploy'ится код

Важные люди и общение

День 1 — встреча с тимом:

• Знакомство со всеми
• Краткое описание проекта
• Выясняю кто за что отвечает

Первая неделя:

• Индивидуальные встречи с key people
• Вопросы по архитектуре
• Процесс разработки

Документирование

Пишу для будущих разработчиков:

# Заметки от new developer

## Что я делал чтобы запустить
1. `pip install -r requirements.txt`
2. `make migrate`
3. `make seed`
4. `python manage.py runserver`

## Проблемы которые я встретил
1. Redis не запускался — нужно `brew install redis` на Mac
2. Миграции требуют явный `make migrate` каждый раз
3. Env переменные лежат в .env.example

## Полезные команды
- `make test-one file=tests/test_name.py` — один тест
- `pytest --pdb` — debugger при ошибке

## Вопросы для тимлида
- Как часто делается релиз?
- Какой процесс для hotfix'ов?
- Есть ли техдолг в модуле orders?

Это помогает и другим разработчикам позже.

Первый месяц: Чек-лист

• Локальное окружение работает
• Все тесты проходят (и я понимаю почему)
• Прочитал главную документацию
• Понял архитектуру на высоком уровне
• Встретился с ключевыми людьми
• Сделал 1-2 простых PR
• Сделал code review для 5+ PR других людей
• Написал/улучшил документацию
• Знаю как деплоится код
• Могу браться за задачи средней сложности

Ключевой совет

Не спеши менять что-либо. Первый месяц — это обучение. Ты не знаешь всех trade-off'ов, истории решений, причин почему сделано так. Лучше потратить неделю на понимание, чем переделывать работу.