RFC: как фиксировать технические решения, чтобы их не переобсуждали
От RFC 1 в 1969 году до практики внутренних RFC в командах: решение пишется один раз, обсуждается по документу и остаётся в журнале решений.
Решения обсуждаются по тексту, а не в устных спорах
Журнал решений отвечает на вопрос «почему мы так сделали»
Прозрачность: затронутые команды видят изменения заранее
RFC (Request for Comments, «запрос комментариев») — формат документов, появившийся в 1969 году в проекте ARPANET: RFC 1 написал Стив Крокер как записку «заинтересованным лицам» с просьбой прокомментировать. Сегодня это официальный канал публикаций IETF: через RFC описаны технические основы интернета — от адресации и маршрутизации до TLS 1.3, QUIC и WebRTC. В серии больше 9000 документов.
Что важно в модели RFC
- Документ — предмет обсуждения. Предложение пишется заранее и целиком, комментарии даются по тексту, а не в устной дискуссии.
- Статусы и зрелость. У RFC есть статусы: Informational, Experimental, Proposed Standard, Internet Standard, BCP, Historic. Видно, на какой стадии зрелости находится спецификация.
- Архивность. Опубликованный RFC никогда не меняется: ошибки исправляются через публичные errata, а устаревание — через новый RFC, который обновляет (updates) или отменяет (obsoletes) прежний. История решений не переписывается.
- Прозрачность процесса. Каждый документ сопровождается видимым следом обсуждения.
RFC как практика внутри команды
Инженерные команды переняли формат для внутренних решений (это зафиксировано и в паттернах InnerSource): перед значимым изменением — архитектуры, схемы данных, процесса — автор пишет RFC и открывает его на комментарии. Ценность даёт не один документ, а их хронологическая коллекция: журнал решений. Код и тесты отвечают «что система делает сейчас», журнал RFC — «как мы сюда пришли».
Минимальный состав RFC: контекст и проблема (драйвер), рассмотренные варианты, предлагаемое решение, последствия, план внедрения, статус (draft → review → accepted/rejected).
Как мы это используем
Мы ведём RFC в собственных проектах (каталог docs/rfc/ этого сайта — пример) и внедряем практику у клиентов: сквозная нумерация, статусы, хранение рядом с кодом. Эффект заметен через пару месяцев: новые участники команды читают журнал вместо расспросов, а повторные обсуждения уже принятых решений почти исчезают.