Был ли опыт, когда несколько разработчиков работали над одной частью

Опыт совместной разработки в команде

Контекст проекта

Да, у меня был значительный опыт работы в командах, где несколько разработчиков одновременно разрабатывали одну часть системы. Это особенно актуально при разработке высоконагруженных бэкенд-сервисов на C++, где над одним модулем могут работать несколько специалистов в параллель.

Конкретный пример: Network I/O Layer

Был проект, где нам нужно было переписать сетевой слой микросервиса, обслуживающего 100K+ RPS. В команде было 3 разработчика, и работа была разделена так:

1. Архитектур (я)

• Определил интерфейсы и контракты между компонентами
• Спроектировал асинхронный I/O с использованием epoll/ioctl
• Создал базовые классы и абстракции

2. Разработчик 2: TCP Connection Manager

• Реализовал управление жизненным циклом соединений
• Работал с handshake, keepalive, graceful shutdown
• Паралельно я разрабатывал event loop

3. Разработчик 3: Protocol Handler

• Реализовал парсинг протокола (protobuf + custom framing)
• Работал с обработкой ошибок и разных версий протокола

Вызовы и решения

Проблема 1: Конфликты в интерфейсах

В начале каждый разработчик имел своё видение интерфейса:

// ❌ Мой вариант
class Connection {
public:
    virtual void send(const Message& msg) = 0;
    virtual void close() = 0;
};

// ❌ Вариант разработчика 2
class Connection {
public:
    virtual int send(const Message& msg, ErrorCode& error) = 0;
    virtual ErrorCode close() = 0;
};

// ❌ Вариант разработчика 3
class Connection {
public:
    virtual SendResult send(const Message& msg) = 0;
    virtual CloseResult close() = 0;
};

Решение:

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

// ✅ Согласованный интерфейс
class Connection {
public:
    virtual ~Connection() = default;
    virtual void send(const Message& msg) throw(NetworkError) = 0;
    virtual void close() noexcept = 0;
    virtual bool is_connected() const noexcept = 0;
};

Проблема 2: Состояние соединения

Каждый разработчик по-своему управлял состояниями:

// ❌ Разработчик 2 использовал enum
enum class ConnectionState { Idle, Connecting, Connected, Closing, Closed };

// ❌ Разработчик 3 использовал флаги
bool connected;
bool closing;
bool is_client;

// Это привело к race conditions при параллельной работе

Решение:

• Централизовали управление состоянием
• Использовали atomic<ConnectionState> для thread-safe доступа
• Документировали переходы состояний в диаграмме

// ✅ Единое управление
class Connection {
private:
    std::atomic<ConnectionState> state{ConnectionState::Idle};
    std::mutex state_mtx;  // Для сложных переходов
    
    bool try_transition(ConnectionState from, ConnectionState to) noexcept {
        ConnectionState expected = from;
        return state.compare_exchange_strong(expected, to);
    }
};

Проблема 3: Обработка ошибок

Одного из разработчиков выбросил исключение в деструкторе (неправильное):

// ❌ ОШИБКА в коде разработчика 2
Connection::~Connection() {
    if (is_connected()) {
        close();  // может выбросить исключение!
    }
}

Решение:

• Провели code review, нашли проблему
• Установили rule: деструкторы ВСЕГДА noexcept
• Добавили в pre-commit hooks проверку

// ✅ ПРАВИЛЬНО
Connection::~Connection() noexcept {
    try {
        if (is_connected()) {
            close();
        }
    } catch (const exception& e) {
        log("Error closing connection: " + string(e.what()));
    }
}

Инструменты и процессы

Code Review

• Перед merge в главную ветку ВСЕГДА code review
• Минимум 2 одобрения
• Требование: понимание влияния изменений на другие модули

Version Control Strategy

# Каждый разработчик в своей feature-ветке
git checkout -b feature/connection-manager

# Частые commits с осмысленными сообщениями
git commit -m "feat(connection): add keepalive mechanism"

# Ребейсим перед мержем
git rebase main
git push origin feature/connection-manager

Тестирование

// Unit тесты для каждого компонента
TEST(ConnectionTest, EstablishConnection) {
    MockEventLoop event_loop;
    auto conn = make_shared<Connection>(&event_loop);
    EXPECT_FALSE(conn->is_connected());
}

// Integration тесты для взаимодействия модулей
TEST(NetworkLayerIntegration, SendMessageThroughStack) {
    Server server;
    Client client;
    
    server.start();
    auto conn = client.connect(server.address());
    conn->send(test_message);
    
    auto received = server.receive(timeout);
    EXPECT_EQ(received, test_message);
}

// Stress тесты для проверки race conditions
TEST(ConnectionStress, ConcurrentSends) {
    auto conn = make_shared<Connection>();
    vector<thread> threads;
    
    for (int i = 0; i < 100; ++i) {
        threads.emplace_back([conn] {
            for (int j = 0; j < 1000; ++j) {
                conn->send(create_message(j));
            }
        });
    }
}

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

Ключевой момент — хорошая документация:

# Network I/O Layer Architecture

## Components

### EventLoop
- **Owner**: Developer 1
- **Responsibility**: epoll-based async event dispatching
- **Thread Safety**: All public methods are thread-safe

### Connection
- **Owner**: Developer 2
- **Responsibility**: TCP connection lifecycle
- **State Machine**: [diagram]

### ProtocolHandler
- **Owner**: Developer 3
- **Responsibility**: Message encoding/decoding
- **Dependencies**: Connection interface (stable)

Сложные ситуации, которые мы решали

Deadlock между потоками

Когда разработчик 2 вызывал close() из EventLoop потока, а разработчик 3 в то же время пытался отправить сообщение:

// ❌ Race condition
// EventLoop thread: lock(mtx) -> close() -> unlock()
// Main thread:     lock(mtx) -> send() -> unlock()

Решение: Используем lock-free структуры где возможно, минимизируем время под блокировкой:

// ✅ Правильная синхронизация
void Connection::send(const Message& msg) {
    {
        unique_lock<mutex> lock(mtx);
        if (state != ConnectionState::Connected) {
            throw ConnectionError("Not connected");
        }
        pending_messages.enqueue(msg);  // O(1) lockfree queue
    }
    // Отпустили блокировку, EventLoop продолжит работу
    event_loop->wake_up();
}

Версионирование интерфейсов

Когда нужно было добавить новый параметр к сообщению:

// v1
struct Message {
    uint32_t id;
    vector<uint8_t> data;
};

// v2 — с расширением (backward compatible)
struct Message {
    uint32_t id;
    uint32_t version = 1;  // новое поле
    vector<uint8_t> data;
};

Вывод: Опыт показал важность:

• Чёткой архитектуры с определением интерфейсов до разработки
• Code review и pair programming для синхронизации
• Comprehensive testing включая stress тесты
• Хорошей документации и communication в команде
• Версионирования API для гибкого развития

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