«Лучшие» практики Rust, которые вас подведут. Часть 2

В январе мы разбирали пять привычек, которые звучат разумно, а на деле мешают: дженерики на каждый параметр, Arc<Mutex>

Пока их читал, до меня дошло, чего не хватало той статье. Все пять историй по сути про одно и то же, просто я тогда этого не увидел. Мы везде платим сейчас за что-то, что, скорее всего, не случится никогда. Строим абстракцию под вторую реализацию. Обобщаем под тип, который никто не подставит.

Сегодня — ещё пять таких же «лучших» практик. Трейт на случай смены базы. Лайфтаймы в структурах ради аллокаций, которые никто не считал. Строка #[derive(...)], которую копируют не глядя и однажды сливают пароль в лог. Newtype на каждое число. И оптимизации, которые воткнули до того, как кто-нибудь вообще открыл профилировщик.

Трейт на случай, если мы поменяем базу

Начну с самого частого. В проекте один способ ходить в хранилище, и он будет один ещё три года. Но пишут так:

#[async_trait]
pub trait UserRepository: Send + Sync {
    async fn find(&self, id: u64) -> Result<Option<User>, RepoError>;
    async fn find_by_email(&self, email: &str) -> Result<Option<User>, RepoError>;
    async fn save(&self, user: &User) -> Result<(), RepoError>;
    async fn delete(&self, id: u64) -> Result<(), RepoError>;
    async fn list_active(&self, limit: u32) -> Result<Vec<User>, RepoError>;
}

pub struct PostgresUserRepository { pool: PgPool }

#[async_trait]
impl UserRepository for PostgresUserRepository {
    async fn find(&self, id: u64) -> Result<Option<User>, RepoError> {
        sqlx::query_as!(User, "SELECT * FROM users WHERE id = $1", id as i64)
            .fetch_optional(&self.pool)
            .await
            .map_err(RepoError::from)
    }
    // ещё четыре метода
}

pub struct Service {
    repo: Arc<dyn UserRepository>,
}

Выглядит хорошо. Аргументов обычно три: вдруг переедем на другую базу, вдруг нужен мок в тестах, вдруг появится вторая реализация. Проходит год, а второй реализации все нет и нет.

Первое, что может сломаться — транзакции. У вас три метода, которые должны выполниться атомарно, а трейт про транзакции ничего не знает.

Дальше два пути:

// либо тащим транзакцию в трейт и хороним абстракцию
async fn save_tx(&self, user: &User, tx: &mut Transaction<'_, Postgres>) -> Result<(), RepoError>;

// либо пишем в обход собственного трейта
impl Service {
    async fn transfer(&self) -> Result<()> {
        let pg = self.repo.as_any().downcast_ref::<PostgresUserRepository>().unwrap();
        let mut tx = pg.pool.begin().await?;
        // ...
    }
}

В первом варианте Postgres оказывается прямо в сигнатуре абстрактного хранилища. Во втором — downcast с unwrap посреди бизнес-логики. И то и другое не очень.

Второе — dyn. С Rust 1.75 асинхронные методы в трейтах работают без макросов, и это отличная новость. Только вот такой трейт перестаёт быть dyn-совместимым, тот же Arc<dyn UserRepository> вы не напишете. Возвращаетесь к #[async_trait], а он боксит каждый вызов, то есть кладёт future в кучу на каждый поход в базу.

Для похода в Postgres эта аллокация — вообще ничто. А потом кто-то заводит CacheRepository с тем же трейтом, кладёт данные в память, и получите Box в куче на каждое чтение из хеш-таблицы.

Поэтому если реализация одна, пишите структуру:

pub struct UserRepository { pool: PgPool }

impl UserRepository {
    pub async fn find(&self, id: u64) -> Result<Option<User>> { /* ... */ }

    pub async fn tx(&self) -> Result<Transaction<'_, Postgres>> {
        Ok(self.pool.begin().await?)
    }
}

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

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

// было: чтобы протестировать правило, нужен мок репозитория
async fn can_promote(&self, id: u64) -> Result<bool> {
    let user = self.repo.find(id).await?.ok_or(NotFound)?;
    Ok(user.karma > 100 && user.days_active > 30 && !user.banned)
}

// стало: правило тестируется без всего
fn can_promote(user: &User) -> bool {
    user.karma > 100 && user.days_active > 30 && !user.banned
}

Вторая версия тестируется десятью строчками без единой зависимости. А поход в базу проверяется интеграционным тестом на настоящем Postgres в контейнере, где он и должен проверяться.

Правило такое: трейт стоит заводить, когда у вас уже есть две реализации и видно, что у них общего. Пока реализация одна, вы не выделяете общее, а угадываете.

Следующая привычка тоже про будущее.

Лайфтаймы ради аллокаций, которых никто не считал

Rust умеет держать в структуре ссылки вместо копий. Это подают как способ обойтись без лишних аллокаций, и так оно и есть. Применяют вот так:

pub struct Config<'a> {
    name: &'a str,
    hosts: Vec<&'a str>,
    tags: HashMap<&'a str, &'a str>,
}

impl<'a> Config<'a> {
    pub fn parse(raw: &'a str) -> Result<Self, ParseError> { /* ... */ }
}

Ни одной лишней аллокации. Пока не понадобится вернуть это из функции:

fn load() -> Config<'static> {
    let s = std::fs::read_to_string("config.toml").unwrap();
    Config::parse(&s)
}

error[E0515]: cannot return value referencing local variable `s`

Тут начинается то, за что Rust чаще всего обзывают. Лайфтайм не остаётся внутри структуры.

Функция, работающая с Config<'a>, получает параметр. Структура, хранящая Config<'a>, получает параметр. Трейт, принимающий её, тоже. Через неделю лайфтаймы в половине сигнатур проекта, а положить конфиг в Arc и отдать в фоновую задачу нельзя, он живёт столько, сколько живёт исходная строка.

Дальше обычно одно из двух. Либо человек плюёт и меняет все ссылки на String, переписывая половину кода. Либо вообще тащит Box::leak ради 'static....

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

Ссылки в структурах хороши там, где структура живёт недолго и никуда не уезжает. Временный вид на чужие данные внутри функции:

// нормально: живёт ровно один разбор
struct Token<'a> { kind: TokenKind, text: &'a str }

// а конфиг пусть владеет своим
pub struct Config {
    name: String,
    hosts: Vec<String>,
    tags: HashMap<String, String>,
}

Если аллокации правда мешают, между этими крайностями есть Cow — он хранит либо ссылку, либо копию и решает по ситуации. Есть Arc<str> для строк, которые расшариваются между потоками и не меняются. Ни то, ни другое не требует тащить лайфтайм наружу.

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

А теперь привычка настолько безобидная, что о ней вообще не думают.

Строка derive, которую копируют не глядя

В каждом втором проекте есть структуры, украшенные полным набором:

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord, Default, Serialize, Deserialize)]

Ставят в первой структуре, дальше копипастят в остальные, потому что так уже принято в проекте. Проблемы две.

Первая — время сборки. Я собрал шестьдесят структур по двенадцать полей в трёх вариантах и померил:

без derive                    25 мс
Debug + Clone                 95 мс
полный набор из восьми       250 мс

А если собирать до объектного файла, а не до метаданных, разрыв ещё больше: 43 мс против 533. При этом объектники получились одинакового размера, 624 байта оба. То есть полсекунды компиляции ушли на код, который в бинарник даже не попал, потому что его никто не вызывает.

Умножьте на число структур в живом проекте и на то, сколько раз вы пересобираете за день.

Вторая проблема серьёзнее:

#[derive(Debug)]
struct DbConfig { host: String, port: u16, password: String }

#[derive(Debug)]
struct User { id: u64, email: String, password_hash: String, session_token: String }

Обычный код и обычное логирование:

eprintln!("[error] не удалось подключиться: {:?}", cfg);
eprintln!("[debug] пользователь: {u:?}");

Что уезжает в лог:

[error] не удалось подключиться: DbConfig { host: "db.internal", port: 5432, password: "hunter2" }
[debug] пользователь: User { id: 7, email: "a@b.c", password_hash: "$2b$12$abc", session_token: "eyJhbGci" }

Пароль от базы, хеш пароля пользователя, токен сессии. Всё открытым текстом. Дальше этот лог попадает в общее хранилище, где его читает вся команда, а нередко и подрядчики.

И главное, никто этого специально не делал. Один поставил #[derive(Debug)], потому что без него в отладчике неудобно. Второй через год добавил поле с секретом. Третий залогировал структуру целиком, так быстрее, чем перечислять поля руками.

Исправляем так:

impl fmt::Debug for DbConfig {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        f.debug_struct("DbConfig")
            .field("host", &self.host)
            .field("port", &self.port)
            .field("password", &"[скрыто]")
            .finish()
    }
}

Пять строк, и секрет никуда не утечёт, даже если кто-то залогирует структуру целиком. Если секретов в проекте много, проще взять secrecy с готовым типом-обёрткой.

По остальным derive критерий тот же: ставьте то, чем пользуетесь. Clone на структуре, которую никто не клонирует, ничего не ломает, но и не даёт. А вот PartialEq на типе с f64 внутри уже не очень. Сравнивать числа с плавающей точкой на равенство почти всегда ошибка, но derive её разрешает, и компилятор больше не ругается.

Newtype на каждое число

Идея, вроде, звучит классно — заворачиваем примитив в свой тип, компилятор перестаёт пускать идентификатор заказа туда, где ждали идентификатор пользователя.

Стоит это мало, что легко проверить. Две функции, одна на голых u64, другая на обёртках, смотрим в промежуточное представление:

sum_nt(i64 noundef %a, i64 noundef %b)
@sum_raw = alias ... @sum_nt

Обёртка испарилась, в сигнатуре обычные целые. Компилятор к тому же схлопнул обе функции в одну и оставил второе имя псевдонимом.

По скорости вопросов нет. Вопросы начинаются, когда правило лепят вообще ко всему:

pub struct UserId(u64);
pub struct OrderId(u64);
pub struct Email(String);
pub struct Username(String);
pub struct PasswordHash(String);
pub struct CreatedAt(DateTime<Utc>);
pub struct RetryCount(u8);
pub struct TimeoutMs(u64);
pub struct Percentage(f64);

Каждый по отдельности очень даже разумен, но во всей этой каше получается проект, где ни одну строку никуда не передать без обёртки, а чтобы сложить два числа, надо достать оба, сложить и завернуть обратно.

Дальше на эти типы вешают Deref, чтобы не мучиться:

impl Deref for Username {
    type Target = str;
    fn deref(&self) -> &str { &self.0 }
}

И всё, защиты больше нет: через Deref компилятор снова пропускает что угодно.

newtype нужен только там, где путаница возможна и дорого стоит. Два идентификатора одного типа рядом в одной сигнатуре — да, обязательно. Миллисекунды и секунды в одном проекте — тут вообще без вариантов. А Username(String), который едет из формы в базу и обратно, не защищает ни от чего, его не с чем путать.

И взглянем на этот код:

impl Percentage {
    pub fn new(v: f64) -> Result<Self, RangeError> {
        if (0.0..=100.0).contains(&v) { Ok(Self(v)) } else { Err(RangeError) }
    }
}

Вот это осмысленный newtype. Он несёт гарантию, которую примитив нести не может: если у вас на руках Percentage, значение точно в диапазоне. А если конструктор просто заворачивает и всё, вы добавили себе работы и ничего не выиграли.

Оптимизация до профилировщика

Это я видел чаще всего. Человек прочитал, что стандартный HashMap медленный из-за криптостойкого хеша, и меняет его на FxHashMap по всему проекту. Потом узнаёт про SmallVec и заменяет им все векторы, где элементов обычно мало. Потом везде расставляет #[inline(always)].

Каждый шаг может быть правильным.

Про #[inline(always)] у меня есть отдельная статья, поэтому коротко: он не ускоряет код, а отбирает у LLVM право решать. В половине случаев делает хуже, потому что раздувает секцию кода и выбивает горячий цикл из кэша инструкций.

С хеш-таблицей интереснее, там замена быстрым хешем может быть не оптимизацией, а серьезной проблемой. Стандартный HashMap использует SipHash, который медленнее FxHash.

Но у этого выбора есть причина:

// ключи приходят от клиента — оставляем стандартный
let sessions: HashMap<String, Session> = HashMap::new();

// ключи свои, из кода — можно и быстрый
let type_names: FxHashMap<TypeId, &'static str> = FxHashMap::default();

Разница в том, кто выбирает ключи. Если клиент, он может подобрать строки с одинаковым хешем и превратить вашу таблицу в связный список. Пятьдесят тысяч таких ключей, и поиск за константу превращается в пятьдесят тысяч сравнений.

SmallVec устроен похоже. Он держит несколько элементов на стеке и переезжает в кучу, когда их становится больше. Выигрыш есть, когда векторов много и они реально короткие. А если элементов обычно двадцать, а на стеке зарезервировано четыре, вы получили обычный Vec, да еще и плюсом лишнюю ветку на каждой операции. А еще структура с ним внутри стала больше, а значит подорожало всё, что её копирует и передаёт.

Короче, сначала нужно все мерить, потом менять, потом померить снова. И на своих данных, а не на синтетике из README крейта — там условия подобраны так, чтобы разница была видна.

Все три инструмента хорошие.

В итоге

Если собрать всё вместе: сами по себе все эти привычки нормальные, проблема только в том, что их внедряют слишком рано. В итоге платишь за то, что почти наверняка не понадобится: сложнее читать, дольше собирается. Поэтому вместо списка правил лучше спросить себя: а мне это реально нужно сейчас? Если да и ответ конкретный — вторая реализация уже есть, замеры есть — бери, не думай. А если «ну, так принято» — это просто привычка, не более.

И ещё одно. Всё это справедливо для обычного кода — сервисов и внутренних библиотек, которые видит только твоя команда. А вот если пишешь библиотеку для всех и заливаешь на crates.io, там всё наоборот: поменять интерфейс потом — значит сломать чужой код. Так что там лишняя абстракция на старте — это такая вот забота о пользователях.

А у вас как? С чем ловили себя на таких «разумных» практиках? В прошлый раз из ваших комментариев выросла половина этой статьи, так что рассказывайте, почитаю с удовольствием.

Размещайте облачную инфраструктуру и масштабируйте сервисы с надежным облачным провайдером Beget.
Эксклюзивно для читателей Хабра мы даем бонус 10% при первом пополнении.