Введение

Вы посреди отладки мерзкой гонки или проектирования тонкого API. Наконец щёлкает правильная идея — тот самый крайний случай, инвариант или поток данных, который делает всё осмысленным. Вы говорите себе: «Сделаю это сразу, как только закончу вот эту одну вещь».

Через двадцать минут идея исчезла.

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

• Заново выводите ту же мысль (дольше и не факт, что так же хорошо), или
• Пожимаете плечами и идёте дальше, надеясь, что это не было критично.

Это — технический долг на уровне рабочего процесса: вы теряете сложные идеи просто потому, что в голове одновременно слишком много движущихся частей.

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

Основная мысль: правило трёх напоминаний

Правило трёх напоминаний — это маленькая система с большим эффектом:

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

Эти три места:

1. У вас в голове – активная идея, над которой вы прямо сейчас размышляете.
2. В быстрой фиксации – сообщение, черновая заметка или карточка, где достаточно деталей, чтобы восстановить мысль.
3. В вашей системе знаний – помеченная тегами, перекрёстно связанная заметка, которую вы сможете надёжно найти потом.

Вам не нужна огромная система управления знаниями. Нужны всего лишь:

• Одно место для быстрой фиксации (чат, черновик, файл заметок), и
• Одно место, которое работает как внешняя память (простая картотека или система заметок с тегами и ссылками).

Цель — не писать красивую документацию. Цель в другом:

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

Почему вы теряете хорошие идеи (и почему скорость — не решение)

Большинство пытается решить это так: «нужно просто писать код быстрее»:

• «Как только пойму правильный API, сразу же его реализую».

Но здесь две большие проблемы:

1. Скорость реализации важна только тогда, когда вы реализуете правильную вещь. Если понимание ещё формируется, бросаться сразу к коду — это преждевременная оптимизация на уровне рабочего процесса. Вы оптимизируете пропускную способность до того, как стабилизировали корректность.
2. Ваш мозг — ужасный черновик. Когда вы пишете код, отлаживаете, переключаетесь между контекстами, читаете логи и общаетесь с командой, ваша рабочая память забита под завязку. Тонкие логические ограничения и инсайты — первые кандидаты на вылет.

Вместо попытки одновременно думать и реализовывать, правило трёх напоминаний заставляет разделить процесс:

• Сначала продумать и зафиксировать идею.
• Потом, когда она достаточно стабилизировалась, реализовать её.

Именно это разделение делает сложные идеи устойчивыми.

Шаг 1: доверьте инструментам всю механическую работу

Одна из тихих причин перегруза: записывать мысли кажется дорогой операцией. Вы думаете:

• «У меня нет времени сейчас расписывать всё подробно».
• «Если уж фиксировать, надо сделать аккуратно, документировано и красиво».

Откажитесь от этого ожидания. Современные инструменты могут взять на себя механику позже:

• AI-ассистенты могут превратить сырые буллеты в документацию или комментарии.
• Форматтеры и линтеры поддержат единый стиль кода без вашего участия.
• Шаблоны и сниппет‑инструменты позволяют за секунды накидать повторяющиеся конструкции.

Ваша задача в моменте — сфокусироваться на логической структуре идеи:

• Какую проблему это решает?
• Какие инварианты должны выполняться?
• Какие есть edge cases или режимы отказа?
• Как это влияет на другие части системы?

Пишите ровно столько, чтобы вы, будущий вы (или коллега) смогли восстановить ход логики. Не полируйте. Не переобъясняйте. Фиксируйте логику; полировку потом доверите инструментам.

Шаг 2: используйте удобные для разработчика каналы для быстрой фиксации

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

Хорошие варианты:

• Отдельный канал в Slack/Discord, например #scratch-ideas
• Личный диалог «сам себе» в командном чате
• Локальный файл scratch.md или ideas.md
• Заметка в Obsidian/Notion с горячей клавишей

Ключевое требование: хорошая поддержка форматирования кода и быстрый доступ.

Быстрая фиксация может выглядеть так:

[IDEA] multi-tenant cache invalidation
- Problem: per-tenant cache entries overlap; invalidation is currently global.
- Insight: key-space can be (tenant_id, resource_id) + version token
- Invariant: tenant A’s invalidation never touches B’s keys
- Edge case: tenant deletion -> must sweep all keys w/ their tenant_id
- Question: how does this interact with background warm-up jobs?

TODO: try modeling this as a “cache policy object” injected per tenant.

Это не спецификация. Это не финальная документация. Это артефакт мышления:

• Достаточно контекста, чтобы потом «разморозить» идею
• Достаточно структуры, чтобы её можно было найти поиском
• Достаточно деталей, чтобы завтра задавать к ней более точные вопросы

Это — напоминание №2.

Шаг 3: сделайте лёгкую «картотеку» как внешнюю память

Быстрая фиксация — отлична, но чаты и черновики — это хронологические свалки. Хорошие идеи быстро тонут в истории.

Отсюда появляется напоминание №3: картотека или система заметок.

Реализовать её можно так:

• Папка с обычными текстовыми/Markdown‑файлами
• Приложение для заметок (Obsidian, Logseq, Notion и т.п.)
• Даже физические картонные карточки, если вам нравятся аналоговые системы

Каждая «карточка» (заметка) должна быть маленькой и сфокусированной:

• Одна идея, паттерн, баг или edge case на карточку
• Короткий заголовок
• Теги и/или идентификатор
• Ссылки или отсылки к связанным карточкам

Пример (как markdown‑карточка):

# multi-tenant-cache-invalidation

**Type:** pattern
**Tags:** caching, multi-tenant, invariants

## Problem
Global cache invalidation is too coarse for multi-tenant systems. One tenant’s updates shouldn’t evict another tenant’s cache entries.

## Idea
- Cache key: (tenant_id, resource_id, version_token)
- Per-tenant invalidation by bumping tenant-specific token or namespace
- Invariant: invalidation scope must be tenant-bounded.

## Notes
- Related: [cache-invalidation-strategies](2024-03-02-cache-strat)
- Check how this interacts with background warmers.

Это ваша внешняя память. Вам не нужно помнить детали — нужно лишь знать, что идея существует и её можно поднять из архива.

Шаг 4: добавляйте теги и перекрёстные ссылки (чтобы идеи всплывали снова)

Разрозненные напоминания полезны; цельная система знаний — сильна.

Трюк прост: каждый раз, когда вы добавляете или пересматриваете карточку, добавьте минимум один из вариантов:

• Тег (например, #caching, #concurrency, #testing, #migration)
• Перекрёстную ссылку на что‑то связанное

Со временем ваш индекс тегов (или поиск по тегам) превращается в карту вашего мышления:

• Просматривая #caching, вы видите старые баги, паттерны и заметки по дизайну.
• Новая проблема с конкуренцией напоминает проверить все заметки с тегом #race-condition.

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

Здесь правило трёх напоминаний начинает по‑настоящему окупаться:

1. Идея существует у вас в голове, когда вы впервые её находите.
2. Она существует в моментальной фиксации (чат/черновик), так что вы её не теряете посреди сессии.
3. Она существует в устойчивой, связанной карточке, так что вы можете найти её через недели и месяцы.

Собираем всё вместе: практичный рабочий процесс

Реалистичный способ использовать правило трёх напоминаний в повседневной работе:

1. Пока вы продумываете сложную проблему

   • Оставайтесь в своей dev‑среде.
   • Как только всплывает ключевая идея, сразу сбрасывайте черновую заметку в инструмент быстрой фиксации.

2. После сессии (или во время паузы)

   • Пролистайте свои черновые сообщения.
   • Важные из них «поднимите» в отдельные карточки/заметки.
   • Проставьте теги и ссылки.

3. Когда позже начинаете связанную задачу

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

4. Во время реализации

   • Держите карточку под рукой, пока пишете код.
   • Доверьте инструментам (AI, шаблоны, генераторы документации) превращение вашей логики в отполированные комментарии или документацию, если это нужно.

Оверхед маленький — несколько минут в день — но эффект накапливается. Вы меньше тратите времени на повторное изобретение одних и тех же идей и реже допускаете логические откаты.

Заключение: относитесь к идеям как к объектам первого класса

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

Правило трёх напоминаний делает эти идеи объектами первого класса:

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

Вам не нужна сложная PKM‑система или идеально вылизанная внутренняя вики. Нужна простая установка:

Если идея достаточно хитрая, чтобы её потеря была болезненной, дайте ей как минимум три напоминания.

Придерживаясь этого правила, вы начнёте чаще переиспользовать более острые идеи, писать более безопасный код и меньше думать: «Кажется, я уже это когда‑то решал…»