Что такое RFC, зачем он нужен и как его писать #1

В сфере искусственного интеллекта произошло заметное событие. Bez_Sahara 25 минут назад Что такое RFC, зачем он нужен и как его писать #1 Простой 10 мин 682 Программирование * Проектирование и рефакторинг * IT-стандарты * IT-инфраструктура * IT-компании Туториал Дисклеймер: Сразу предупрежу, что все мои статьи в этой серии это лишь описание моего опыта и мои знания могут быть не полными в некоторых областях или не подходить вашей ситуации. Всем привет, это начало серии обучающих статей на разные темы, как часто и на какие темы они будут выходить я не знаю, особенно первое, а по темам, можете предлагать сами в комментариях, буду помогать разобраться. Если вы с чем-то не согласны или у вас есть что добавить (например в этой статье это будет про личный опыт неудач без RFC), напишите, в случае если это конструктивная правка, я внесу корректировку в статью с указанием автора, поскольку цель этой серии создать в СНГ комьюнити базу по стандартам Биг Теха запада и дать разработчикам новые знания.

Про RFC статьи будут разделены на 2 части:В первой я расскажу о том что такое RFC, чем отличается от дизайн документа, почему вообще они появились, что будет если их не писать когда надо (личный и крайне не приятный опыт), к каким принципам написания я пришел, когда их стоит писать, а когда нет. Во второй части же я прямо в статье напишу RFC по системе поисковика на Go и дам мини дз на написания своего RFC, который вы сможете кинуть как PR в репозиторий и я объясню что стоит исправить. Начнем с ответа на вопрос, что такое вообще RFC.

Технические детали

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

А дальше начинаются различия:В первом случае RFC становится финальным артефактом и по нему идет реализация, то есть получается гибрид RFC и дизайн документа. Лично я и придерживаюсь этого стиля, поскольку в основном работаю в одиночку, у меня смешиваются RFC и дизайн документ в единое целоеВо втором случае RFC остается самостоятельным документом как таковым, но так же и становится базой для написания дизайн документа, по которому и будет сделана реализация далее. Добавлю что нет единого правильного способа писать RFC и пути его развития, это все остается на усмотрение авторов, компании, ситуации и тд.

Чем отличается RFC от Дизайн документа.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.