2018-12-04 Скрытие Экспериментальных Опций

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


<p>
<b>Постановка задачи: </b> Добавить опцию, включающую экспериментальный функционал
</p>

<p>
<b>Проблема: </b> Разработчик решил скрыть опцию из интерфейса конфигурации, чтобы пользователь не смог активировать ее, что может привести к проблемам
</p>

<p>
<b>Ошибка: </b> Нельзя скрывать от пользователей новый функционал продукта, даже экспериментального характера. Наличие опции:
</p>
<ul>
<li class="level1"> показывает развитие продукта пользователю</li>
<li class="level1"> пробуждает интерес к новому функционалу</li>
<li class="level1"> часть пользователей может захотеть им воспользоваться, а мы получим фидбек и баг-репорты по новой опции</li>
<li class="level1"> снижает шанс, что опция "умрет", т.к. ей ни кто не будет пользоваться, а разработчики займутся другими, более важными задачами</li>
</ul>

<p>
<b>Как нужно: </b> Расположить опцию в подменю "Экспериментальные опции" или добавить к опции комментарий: "Внимание! Экспериментальная опция!". Также нужно назвать опцию максимально понятно, чтобы пользователи смогли понять зачем она нужна и добавить пункт об этой опции в рассылку по продукту.
</p>

<p>
<b>P.S.</b> это не относится к разрабатываемому функционалу, когда код, реализующий часть функционала, вливается в основную ветку продукта для ранней обкатки кода на наличие несовместимостей в РУЧНОМ тестовом режиме деплоя. Часто при этом, активация этого кода либо что-то ломает, либо не вносит в продукт ничего полезного. Но мы так не делаем, этот подход применяют при других схемах разработки CI&CD.
</p>

<p>
~~OWNERAPPROVE~~
/*Не удаляйте эту строку и ниже!*/
</p>
{(rater>id=1|name=Прочитал_правила_разработки:как_не_надо_делать:2018-12-04_скрытие_экспериментальных_опций|type=vote|trace=user|tracedetails=1)}