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