Сталкивались ли вы с техническими разногласиями в команде и как их разрешали?

Да, технические дискуссии — обычная часть работы. Например, в одном проекте возник спор о выборе контейнера для хранения большого набора сущностей, в котором часто происходили вставки и удаления в середине.

• Позиция коллеги: Использовать std::list из-за гарантированно константного времени вставки/удаления.
• Моя позиция: Использовать std::vector с продуманной стратегией резервирования, так как кэш-локальность процессора может дать большее преимущество, несмотря на линейное время копирования при реаллокации.

Мы разрешили спор, написав бенчмарк для измерения производительности в нашем конкретном сценарии:

#include <benchmark/benchmark.h>
#include <vector>
#include <list>

static void BM_VectorInsert(benchmark::State& state) {
    for (auto _ : state) {
        std::vector<int> vec;
        vec.reserve(state.range(0));
        for (int i = 0; i < state.range(0); ++i) {
            // Вставка в середину — наихудший случай для vector
            auto it = vec.begin() + vec.size() / 2;
            vec.insert(it, i);
        }
    }
}
BENCHMARK(BM_VectorInsert)->Arg(1000);

static void BM_ListInsert(benchmark::State& state) {
    for (auto _ : state) {
        std::list<int> lst;
        for (int i = 0; i < state.range(0); ++i) {
            auto it = lst.begin();
            std::advance(it, lst.size() / 2);
            lst.insert(it, i);
        }
    }
}
BENCHMARK(BM_ListInsert)->Arg(1000);

Замеры показали, что для нашего размера данных (~1000 элементов) и паттерна доступа std::vector был быстрее. Мы приняли решение на основе данных, а не предположений. Этот опыт укрепил в команде культуру доказательного подхода к архитектурным решениям.