Что изучал, когда подключался к проекту

Процесс onboarding при подключении к проекту

Когда я присоединяюсь к новому проекту, я следую структурированному плану изучения, который позволяет быстро продуктивно участвовать в разработке. Вот мой подход с опытом 10+ лет.

1. Понимание бизнес-контекста (День 1-2)

Что я изучаю:

• Продукт и его назначение — что решает это приложение?
• Основные user personas — кто использует продукт?
• Бизнес-метрики — какие KPI важны?
• Roadmap — куда движется продукт?
• Конкуренты — как мы отличаемся?

// Пример: если это платёжная система
// Нужно понять: какие платежи обрабатываем? Какие страны? Какой volume?
// Это влияет на выбор архитектуры и базы данных

Я встречаюсь с product manager и техническим лидом:

• Запрашиваю документацию по продукту
• Смотрю demo или тестирую приложение сам
• Читаю аналитику и бизнес-отчёты

2. Технологический стек (День 2-3)

Выясняю:

• Какой version Java, Spring Boot, других фреймворков?
• Какая СУБД и почему её выбрали?
• Какие internal libraries и frameworks используются?
• Какой message broker (RabbitMQ, Kafka)?
• Как настроены CI/CD, monitoring, logging?

Типичный стек, который я изучаю:
- Java 17, Spring Boot 3.1, Spring Data JPA
- PostgreSQL с Flyway миграциями
- Docker, Kubernetes для deployment
- GitHub Actions для CI/CD
- ELK Stack для логирования
- Redis для кэширования

Я читаю:

• pom.xml или build.gradle для зависимостей
• README.md и другую документацию
• Документацию фреймворков (особенно версию, которую используют)

3. Архитектура приложения (День 3-5)

Что я изучаю:

Структура проекта

src/
├── main/
│   ├── java/
│   │   └── com/company/app/
│   │       ├── controller/     # REST endpoints
│   │       ├── service/        # Бизнес-логика
│   │       ├── repository/     # Работа с БД
│   │       ├── domain/         # Сущности
│   │       ├── dto/            # Data Transfer Objects
│   │       ├── exception/      # Custom exceptions
│   │       ├── config/         # Spring конфиги
│   │       └── util/           # Утилиты
│   └── resources/
│       ├── application.yml     # Конфигурация
│       ├── application-dev.yml # Dev переменные
│       └── db/migration/       # Flyway миграции
└── test/
    └── java/ → mirror структура с тестами

C4 диаграммы (если есть)

Я прошу:

• System Context Diagram — как мой сервис взаимодействует с другими?
• Container Diagram — какие компоненты (API, DB, cache)?
• Component Diagram — как организованы классы?

4. Изучение кода (День 5-10)

Читаю в порядке приоритета:

Критичные модули

// 1. Основные сущности и relationships
@Entity
public class Order {
    @Id
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "user_id")
    private User user;
    
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> items;
}

// 2. Ключевые сервисы
@Service
public class OrderService {
    // Бизнес-логика
}

// 3. REST API endpoints
@RestController
public class OrderController {
    // Interfaces с внешним миром
}

Миграции БД

Я читаю миграции в порядке их создания:

-- migrations/0001_create_users_table.sql
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- migrations/0002_create_orders_table.sql
CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL,
    total_amount DECIMAL(10, 2),
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    FOREIGN KEY (user_id) REFERENCES users(id)
);

Это даёт мне полное понимание схемы БД.

Конфигурация

# application.yml
spring:
  application:
    name: order-service
  jpa:
    hibernate:
      ddl-auto: validate  # Never create, only validate
  datasource:
    url: jdbc:postgresql://${DB_HOST}:5432/${DB_NAME}
    username: ${DB_USER}
    password: ${DB_PASSWORD}
  redis:
    host: ${REDIS_HOST}
    port: 6379

server:
  port: 8080
  servlet:
    context-path: /api/v1

5. Развёртывание и запуск (День 10-11)

Я делаю:

# 1. Клонирую репозиторий
git clone <repo>

# 2. Запускаю локальную БД и зависимости
docker-compose up -d

# 3. Собираю проект
mvn clean install

# 4. Запускаю приложение
mvn spring-boot:run

# 5. Проверяю, что работает
curl http://localhost:8080/api/v1/orders

На этом этапе я убеждаюсь, что:

• Локальная разработка работает
• Тесты проходят
• Приложение запускается без ошибок

6. Изучение процессов разработки (День 11-15)

Что я узнаю:

• Git workflow — как работает branching? Требования для PR?
• Code review процесс — сколько approvals нужно?
• Testing requirements — какой coverage нужен? Какие тесты писать?
• Deployment процесс — как код попадает в production?
• Monitoring и alerting — как отслеживаем ошибки?

# Типичный workflow
git checkout -b feature/JIRA-123-new-feature
# ... разработка ...
git push origin feature/JIRA-123-new-feature
# Создаю PR, жду code review
# После 2 approvals — merge в main
# CI/CD автоматически запускает: lint, test, build, deploy to staging

7. Первые задачи (День 15+)

Я выбираю:

• Small bugs в Known Issues
• Documentation improvements — добавляю примеры, исправляю
• Refactoring тестов — улучшаю существующие тесты
• Setup tasks — улучшу локальную разработку

НЕ беру: ✗ Большие фичи с критичной бизнес-логикой ✗ Production hotfixes без supervision
✗ Архитектурные решения

8. Документирование того, что я изучил (День 15+)

Я создаю для себя личные заметки:

# Onboarding Notes

## Проект
- Платёжная система для e-commerce
- Java 17, Spring Boot 3.1, PostgreSQL
- Микросервисная архитектура

## Ключевые компоненты

### OrderService
- Создаёт заказы
- Интегрируется с PaymentService
- Публикует события в Kafka

## Запуск локально
```bash
docker-compose up -d
mvn spring-boot:run

Git Workflow

• feature/* для новых фич
• Требует 2 approvals
• CI/CD раннер на GitHub Actions

Контакты

• Tech Lead: John (john@company.com)
• PM: Sarah (sarah@company.com)

Впоследствии я обновляю основную документацию проекта если нашёл неточности или пробелы.

### Типичный timeline

| Время | Активность | Статус |
|-------|------------|--------|
| День 1-2 | Бизнес-контекст, встречи | Ориентирование |
| День 2-3 | Технологический стек | Понимание |
| День 3-5 | Архитектура, диаграммы | Глубокое изучение |
| День 5-10 | Чтение кода, миграции БД | Детальное понимание |
| День 10-11 | Локальный запуск, тесты | Hands-on |
| День 11-15 | Процессы разработки, code review | Интеграция в команду |
| День 15+ | Первые задачи | Продуктивная разработка |

### Что я спрашиваю у менторов

1. Почему выбрали именно этот фреймворк/БД?
2. Какие были основные технические решения?
3. Какие pain points сейчас есть в коде?
4. Что из планов на архитектуру на следующие 6 месяцев?
5. Как обычно работают спринты и планирование?
6. Кто эксперты по разным модулям?
7. Какие инструменты используем для профилирования и debugging?
8. Как обычно выглядит PR review?

### Инструменты, которые я использую

- **IntelliJ IDEA** — для навигации по коду, quick search, refactoring
- **git log / git blame** — для понимания истории изменений
- **Swagger/OpenAPI** — для понимания API
- **Database tools** — для изучения схемы БД
- **Postman / curl** — для тестирования endpoints

Грамотный onboarding — это инвестиция в продуктивность на длительный период. Лучше потратить 2 недели на качественное изучение, чем 2 месяца на исправление ошибок.