Кто решает, как будут называться поля в проекте

Кто решает, как называются поля в проекте

Это вопрос о командной культуре, дизайне архитектуры и управлении кодовой базой. Ответ зависит от того, на каком уровне мы говорим о названиях.

1. Соглашения и стандарты команды

Решение принимает: Техлид или Архитектор вместе с командой.

Это устанавливается в самом начале проекта:

// Соглашение 1: camelCase для Java
public class User {
    private String firstName;
    private String lastName;
    private LocalDateTime createdAt;
}

// Соглашение 2: snake_case в БД
// first_name в таблице users

// Соглашение 3: PascalCase для классов
public class UserRepository { }
public interface UserService { }

// Соглашение 4: UPPER_CASE для констант
public static final int MAX_LENGTH = 128;

Хорошая практика: документировать в CODE_STYLE.md

2. Архитектурные решения

Решение принимает: Архитектор или Senior разработчик.

Это касается структуры полей в контексте бизнес-логики:

// Вариант 1: Одна таблица
public class User {
    private String firstName;
    private String lastName;
    private String email;
    private String phone;
    private String address;
}

// Вариант 2: Value Objects (DDD подход)
public class User {
    private Name name;
    private ContactInfo contact;
    private Address address;
}

public class Name {
    private String firstName;
    private String lastName;
}

Это архитектурное решение, принимает техлид.

3. API контракты

Решение принимает: API архитектор или Backend лид с согласованием фронтенда.

Поля в REST API могут отличаться от внутреннего формата:

// Внутренний класс (Java)
public class User {
    private String firstName;
}

// JSON в API (snake_case)
@JsonProperty("first_name")
private String firstName;

// Результат JSON:
// { "first_name": "John" }

Бэкенд и фронтенд договариваются о JSON структуре.

4. Именование в базе данных

Решение принимает: DBA или Lead разработчик.

Миграции определяют имена столбцов:

CREATE TABLE users (
    id UUID PRIMARY KEY,
    first_name VARCHAR(100) NOT NULL,
    last_name VARCHAR(100) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMPTZ NOT NULL
);

5. Бизнес-доменные имена

Решение принимает: Product Owner с архитектором.

Какие сущности нужны в системе:

public class Campaign {
    private String name;
    private String description;
    private LocalDateTime startDate;
    private LocalDateTime endDate;
    private CampaignStatus status;
    private BigDecimal budget;
}

public class Order {
    private String orderNumber;
    private OrderStatus status;
    private List<OrderItem> items;
}

Это определяет бизнес-язык (Ubiquitous Language в DDD).

Процесс принятия решения

Новое поле нужно добавить?
    │
    ├─→ Это стиль?
    │   └─→ Проверь CODE_STYLE.md
    │       └─→ Следуй конвенции
    │
    └─→ Это архитектура?
        └─→ Согласуй с архитектором
            └─→ Следуй решению

Принципы Чистого кода

// Плохо
public class User {
    private String n;
    private String d;
    private String ed;
}

// Хорошо
public class User {
    private String firstName;
    private String description;
    private LocalDateTime enrolledDate;
}

Реальный пример

Девелопер: Добавить поле lastModifiedAt?

Техлид: Да, согласно соглашениям:
- Java: lastModifiedAt (camelCase)
- БД: last_modified_at (snake_case)
- JSON API: last_modified_at (snake_case)

Синхронизируй с фронтом!

Иерархия решений

1. LANGUAGE CONVENTION (Java standard)
2. TEAM CODE STYLE (CODE_STYLE.md)
3. DATABASE SCHEMA (миграции)
4. ARCHITECTURE DESIGN (техлид)
5. BUSINESS DOMAIN (Product Owner)
6. API CONTRACT (фронт + бэк договор)

Вывод

• Стиль кода (camelCase) → вся команда следует соглашению
• Архитектура (Value Objects) → техлид
• API (JSON structure) → договор между фронтом и бэком
• Бизнес-домен → Product Owner

Главное: договаривайся с командой, документируй решения, следуй соглашениям.