Rust В 2019 Году И Далее: Пределы Роста

В соответствии с просьбой, вот мои предложения по продвижению Rust в 2019 году и далее.

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

Более того, эти предложения во многом применимы ко многим проектам.

Rust — особый случай, но именно он сейчас заставляет меня задуматься.

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

ТЛ;ДР: Важно признать проблему и спланировать четкие механизмы, чтобы ограничить рост двух вещей:

1. Обязательны общие технические артефакты, особенно само определение языка.

2. Бремя лежит на людях, участвующих в обсуждении этих артефактов.

Есть естественные пределы.

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

Обратите внимание, я не пишу о пределах роста многих других направлений.

Например, индекс пакета, размер сайта или даже сообщество пользователей.

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

Ограничивающие факторы и бегство Каждая природная система имеет пределы роста.

Вот почему Вселенная — это не (например) одна амеба, расширяющаяся со скоростью света.

Система растет (и часто скорость расширения тоже растет!), пока не сталкивается с ограничивающими факторами, а затем постепенно рост замедляется, пока общий размер системы не достигнет плато.

Типичные закономерности роста в этом случае выглядят примерно как сигмовидная или «S-образная кривая», постепенно приближающаяся к определенной асимптоте.

По крайней мере, если ограничивающие факторы проявляются постепенно и контролируемо.

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

S-кривая поднимается до пика, за которым следует коллапс.

Я хотел бы избежать этого.

Примеры хорошего контроля В проекте Rust есть несколько форм управления процессами, которые по своей сути ограничивают скорость изменений и/или роста.

Я считаю эти меры очень разумными: отчасти благодаря им проект до сих пор успешен.

По аналогии с ними хотелось бы сформулировать следующие рекомендации.

Современные формы управления:

• Очередь Борса пропускает изменения из-за корректности программы.

• Кратер пропускает релизы из-за корректности для экосистемы.

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

  Решение принимается вовремя, а все, что не готово, отсекается.

• Нормы поведения .

  Не все помнят, но он не просто так постулирует социальную справедливость и так далее.

  Он также устанавливает ограничения на соотношение сигнал/шум при разговоре, использование внимания и времени других людей и подталкивает к компромиссу (в конце концов, не каждое решение имеет нулевую сумму).

• RFC-процесс .

  Правила о форме, содержании, сроках, наборе участников, разрешенных и ожидаемых формах дискурса при обсуждении существенных изменений.

• Модель управления .

  Разграничение сфер ответственности, иерархическое делегирование там, где это необходимо, роли и ожидания участников и так далее.

Там, где это возможно, контроль является автоматическим и полностью беспристрастным (чтобы свести к минимуму недоброжелательность и субъективные суждения, искушение срезать углы и т. д.).

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

.

Проблемные места Давайте вернемся к двум проблемным областям, где проект на данный момент не имеет адекватных механизмов или политик для контроля Rust, что несет в себе риск возможной дисфункции или даже кризиса.

В обоих случаях не совсем понятно, насколько далек сейчас проект от такого кризиса.

Но в любом случае лучше проявить инициативу, чем опоздать.

1. Сам язык .

   Его определение.

   Это (в отличие от многих частей проекта) обязательный общий технический артефакт. В этом заинтересованы все, и каждое изменение потенциально затрагивает всех.

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

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

   • Возможность для новичка выучить язык.

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

   • Способность эксперта или специалиста по сопровождению знать все (или большую часть) изменений.

   • Соотношение затрат и выгод каждого нового изменения с точки зрения новой и текущей работы.

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

     Затраты являются комбинаторными по многим параметрам дизайна и размера языка.

     Они почти всегда увеличиваются.

   Если вы не соблюдаете эти ограничения, вы можете столкнуться с очень серьезными рисками:
   • Необоснованные изменения формулировок вплоть до неспособности обеспечить критически важные гарантии безопасности.

   • Репутация чрезмерной сложности, потеря пользователей.

     Риск стать следующим C++ или Haskell.

   • Некачественные функции с неполным определением, тестами, документацией.

   • Малоиспользуемые функции, которые тратят усилия, необходимые в другом месте.

   • Раздробленность на диалекты, изолированные программы, снижение стоимости.

2. Нагрузка на людей работаю над языком.

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

   Это не обычные технические артефакты.

   В той или иной степени для многих людей (а их становится все больше и больше) придется участвовать почти во всех изменения.

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

   • Количество часов в день.

   • Количество оплаченный часов в день.

   • Ответственность и интересы вне проекта.

   • Запасите умственную энергию, чтобы понять, что происходит.
   • Доверяйте мнению всех участников разговора.

   • Оставьте психологическую и эмоциональную энергию для чтения и обсуждения.

   • Презумпция добросовестности всех участников разговора.

   Риски превышения этих лимитов также потенциально очень серьезны:
   • Неверные решения, принятые из-за утомления или выгорания.

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

   • Сужение дискурса: от внимательного рассмотрения к «победе в споре».

   • Люди дурачатся, выгорают, ведут себя плохо и уходят из проекта.

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

   Хочу подчеркнуть, что описанные ограничения и риски вовсе не касаются конкретных людей или даже проекта Rust в целом.

   Они встречаются повсюду в разной степени.

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

   Единственное решение — разумное управление при достижении предела.

   Взять под контроль.

В конечном итоге важно принять контроль по собственной воле, а не навязанной извне.

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

Поэтому я просто предложу несколько возможных вариантов, не очень структурированных, но в духе праздничного Рождества: например, кучу потенциально интересных подарков, которые нужно развернуть, посмотреть и решить, оставить себе или обменять на что-то более интересное.

1. Отрицательно определенное пространство .

   Исключите процесс обсуждения функций и концепций из планов будущего развития языка.

   Разрешить (или поощрять) RFC, в которых говорится: «Rust никогда не будет иметь X» для некоторого значения X. Это дает нам единоразовый раунд для честного обсуждения и рассмотрения возражений против долгосрочных изменений («никогда» — это довольно долгий срок).

   время!).

   Тогда эта дискуссия закончится навсегда.

   Оно не станет вечным источником затяжных конфликтов.

   Несколько примеров, когда можно сформулировать отрицательно определенные пространства:

   • навсегда удалить из системы типов определенные категории выразительности (например, зависимые типы, HKT и т.п.

     );

   • из синтаксиса (например, ключи параметров, позиционные или именованные аргументы);
   • из набора типов элементов (например, анонимных типов сообщений);
   • от набора обязательств по выводу до мидлэнда (например, синтез констант, неявных аргументов).

   Установите некоторые жесткие ограничения, чтобы избегать этих объектов, а также людей, которые поставили перед собой цель «сделать все правильно».

2. Затраты на разработку необходимо указать явно.

   Взяв страницу из журнала изменений WebAssembly, заранее дайте понять, что такой RFC потребует соответствующих инвестиций в реализацию, формализацию, пересмотр документации, пересмотр учебных материалов, написание тестов, обслуживание и т. д. Если затраты не могут быть покрыты, на этом этапе отложите меняется «пока не будет найден спонсор».

3. Ставьте цели на скорость обучения и объем материала .

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

   Если «изучить Rust за 21 день» не подходит, найдите подходящий интервал.

   Три месяца? Шесть? Год? Подумайте о языках, изучение которых «определенно занимает слишком много времени», и выберите меньшее число.

   Руководство на 1000 страниц — это нормально? 500? 300?

4. Установить другие автоматические ограничения : количество строк кода в компиляторе, общее время загрузки, долларов в день на экземплярах AWS, количество правил в грамматике, в системе типов, процент покрытия тестами, процент документов, которые можно пометить как «неполные», и т. д. Проявите творческий подход, выясните значимые вещи, которые поддаются измерению, а затем создайте механизмы для их ограничения.

5. Личный лимит времени : примерно сколько часов (или оплачиваемого времени) человек может реально посвятить проекту без утомления и выгорания, включая участников с минимальными полномочиями.

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

   Затем удалите или отложите в сторону все, что не укладывается в пределы.

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

   Иногда со стороны кажется, что дискуссия слишком горячая.

   Для деэскалации конфликта проще установить общий лимит, чем применять санкции к отдельным участникам.

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

   Это может быть эффективно: аудиторская группа поможет людям сказать «нет», когда это необходимо, вместо того, чтобы терпеть, как это делают большинство членов команды, соглашаясь на слишком многое.

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

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

Вас следует похвалить за это.

Надеюсь, эта статья будет встречена в таком же духе конструктивной критики.

С Новым годом и удачи! Теги: #Rust #ограничения роста #Rust #Управление проектами #Управление продуктом

• Ozon Разработал Платформу Tradeup Для Продаж На Сайтах Компаний-Поставщиков

  19 Oct, 24

• Epoll И Порты Завершения Ввода-Вывода Windows: Практическая Разница

  19 Oct, 24

• Kubernetes, Игровая Площадка, Микросервисы И Немного Волшебства

  19 Oct, 24

• О Масках

  19 Oct, 24

• Тестирование Производительности Программного Обеспечения

  19 Oct, 24

• Агент Mail.ru… 007?

  19 Oct, 24

• Как Подключить Официальный Бизнес Api Whatsapp Через Gupshup И Интегрироваться С Битрикс24

  19 Oct, 24

• Как Pandadoc Эффективно Работает С Оценкой Потенциальных Клиентов?

  19 Oct, 24

• Виджет Для Социальных Сетей

  19 Oct, 24

• Socialtext Редактирует Вики В Автономном Режиме

  19 Oct, 24