Это всего лишь один из инструментов, который может быть полезен, если правильно им пользоваться. Полезно иметь переключатель, когда надо что-нибудь запустить в определенное время, например, с началом рекламной кампании.
Feature toggling — это необязательно инструмент организации совместной разработки. Зачастую это способ внедрения бизнес-задач, запуск которых не зависит от разработчика.
Например, нужно запустить продажу билетов на чемпионат мира по футболу. Сделать это надо по отмашке какой-нибудь "фифы", точно в указанное время, не раньше и не позже. За любой фальстарт или опоздание придется штрафы платить. Тогда заранее выкатываешь обновление всех своих сервисов с выключенной фичей. А когда время окончательно утвердят, то просто в нужный момент щелкаешь тумблер. Если же подготовить отдельную версию с продажей билетов, то надо всем дежурить, ожидая команды на раскатку, да и сама раскатка может занять долгое время, а потенциальные покупатели к конкурентам убегут. У серьезных бизнесов таких фишек может быть одновременно несколько штук, а то и несколько десятков.
if (configurationManager.getParameter("is.some.functionality.enabled")) {
// do some stuff
} else {
// do default logic
}
Такие ветвления вносят неразбериху. С одной стороны, ветка else сделана автором фичи, с другой стороны, она работает, когда фича выключена. Непонятно, кто и как должен обеспечить, чтобы else отработал корректно. Автор фичи не может точно знать, как должен работать код, который разрабатывают другие разработчики, а те в свою очередь понятия не имеют о том, что какая-то часть кода выполняется не всегда.
Надо организовать код таким образом, чтобы ветка else всегда была пустая.
Например
if (featureProvider.isFeatureEnabled("JIRA-TICKET-1234")) {
registerEverywhere(SomeBrandNewFeature.class);
}
или
if (featureProvider.isFeatureEnabledInContext(context, "JIRA-TICKET-4321")) {
executionPipeline = executionPipeline.next(SomeBrandNewFeature::doSomething);
}
И еще хочу добавить, что состояние хорошей фичи проверяется не более чем в одном месте. 2-3 условия — уже повод задуматься о рефакторинге. Если же проверки разбросаны по десяткам файлов, то фичетогглинг будет только мешать.
Вот когда Ассанж что-то опубликует, тогда и посмотрим. Он, кстати, что-то уже выложил. Особой реакции ни у кого не вызвало, так как кадры очень низкого качества и подвергнуты монтажу.
Вы совершенно правы. Становится просто опасно что-либо писать на Хабре.
Я, например, никогда не минусую комментарии, с которыми не согласен. Минус могу поставить только если там оффтоп, ненормативная лексика, эмоции, политота, и иногда, когда что-то совершенно не соответствующее действительности.
А если вижу, что какой-то вполне приличный комментарий, как ваш например, заминусовали, даже если я с ним не согласен, то ставлю плюс.
Большое спасибо за развернутое разъяснение. Абсолютно согласен с вами насчет того, что это не просто выстрел в ногу, это скорее мина в рюкзаке, готовая взорваться от любой встряски.
Помнится, когда еще не было таких хороших компиляторов и статических анализаторов, я писал свои кастомные free, malloc, delete и new, где принудительно после выделения памяти, заполнял ее символами ‘+’, а после освобождения — символами ‘-‘, и это позволяло быстро обнаружить такие косяки, как и выход за границы буфера.
Потом, когда я все эти косяки отловил, то переписал весь свой код на смартпоинтерах, чтобы вообще нигде явно не вызывать ни delete, ни free.
Вообще-то после вызова delete содержимое памяти по указанном адресу останется прежним, поэтому его еще можно безопасно использовать. Проблемы могут возникнуть только после следующего вызова new.
</irony-mode-off>
Э-э-э. Вы не поняли фишку. Это психологический прием. Чувак написал идеальный код. Ждет заслуженную похвалу. А вместо этого бац: "Почему импорты со звездочками?" Его переполняют эмоции. Он вместо того, чтобы спокойно выбирать между похожими оферами, сидит и думает, как же это возможно. И тут ему предлагают все замечания конструктивно обсудить, обсуждают, у него появляется возможность проявить свои софт-скиллы, он побеждает в деловом споре, и позиция в нашей команде для него начинает ассоциироваться с победой.
На мой взгляд, идеального кода не бывает. Но даже если кто-то думает, что он такой код написал, он должен уметь обосновать эту оценку и аргументированно отвергнуть придирки, а иначе от его перфекционизма будет мало толку.
А сейчас что, нельзя?
Если хотите проявить заботу о родителях, покажите им, как отправлять таких "поздравляторов" в блок.
Это всего лишь один из инструментов, который может быть полезен, если правильно им пользоваться. Полезно иметь переключатель, когда надо что-нибудь запустить в определенное время, например, с началом рекламной кампании.
Feature toggling — это необязательно инструмент организации совместной разработки. Зачастую это способ внедрения бизнес-задач, запуск которых не зависит от разработчика.
Например, нужно запустить продажу билетов на чемпионат мира по футболу. Сделать это надо по отмашке какой-нибудь "фифы", точно в указанное время, не раньше и не позже. За любой фальстарт или опоздание придется штрафы платить. Тогда заранее выкатываешь обновление всех своих сервисов с выключенной фичей. А когда время окончательно утвердят, то просто в нужный момент щелкаешь тумблер. Если же подготовить отдельную версию с продажей билетов, то надо всем дежурить, ожидая команды на раскатку, да и сама раскатка может занять долгое время, а потенциальные покупатели к конкурентам убегут. У серьезных бизнесов таких фишек может быть одновременно несколько штук, а то и несколько десятков.
Я бы вот так делать не стал.
Такие ветвления вносят неразбериху. С одной стороны, ветка else сделана автором фичи, с другой стороны, она работает, когда фича выключена. Непонятно, кто и как должен обеспечить, чтобы else отработал корректно. Автор фичи не может точно знать, как должен работать код, который разрабатывают другие разработчики, а те в свою очередь понятия не имеют о том, что какая-то часть кода выполняется не всегда.
Надо организовать код таким образом, чтобы ветка else всегда была пустая.
Например
или
И еще хочу добавить, что состояние хорошей фичи проверяется не более чем в одном месте. 2-3 условия — уже повод задуматься о рефакторинге. Если же проверки разбросаны по десяткам файлов, то фичетогглинг будет только мешать.
Что такое «спортивное программирование»? Чем там меряются? У кого exe-шник компактнее?
Круть
А так тоже нельзя делать?
Спасибо. А что будет, если присвоить этому параметру новое значение?
Напомните, пожалуйста, что означает такая запись
Я на С++ не пишу, но с интересом слежу за его развитием.
По-моему, тоже.
Вот когда Ассанж что-то опубликует, тогда и посмотрим. Он, кстати, что-то уже выложил. Особой реакции ни у кого не вызвало, так как кадры очень низкого качества и подвергнуты монтажу.
Если так, как вы показали, считать, то на Земле жизни нет.
Вы совершенно правы. Становится просто опасно что-либо писать на Хабре.
Я, например, никогда не минусую комментарии, с которыми не согласен. Минус могу поставить только если там оффтоп, ненормативная лексика, эмоции, политота, и иногда, когда что-то совершенно не соответствующее действительности.
А если вижу, что какой-то вполне приличный комментарий, как ваш например, заминусовали, даже если я с ним не согласен, то ставлю плюс.
Большое спасибо за развернутое разъяснение. Абсолютно согласен с вами насчет того, что это не просто выстрел в ногу, это скорее мина в рюкзаке, готовая взорваться от любой встряски.
Помнится, когда еще не было таких хороших компиляторов и статических анализаторов, я писал свои кастомные free, malloc, delete и new, где принудительно после выделения памяти, заполнял ее символами ‘+’, а после освобождения — символами ‘-‘, и это позволяло быстро обнаружить такие косяки, как и выход за границы буфера.
Потом, когда я все эти косяки отловил, то переписал весь свой код на смартпоинтерах, чтобы вообще нигде явно не вызывать ни delete, ни free.
Вообще-то после вызова delete содержимое памяти по указанном адресу останется прежним, поэтому его еще можно безопасно использовать. Проблемы могут возникнуть только после следующего вызова new.
</irony-mode-off>
Э-э-э. Вы не поняли фишку. Это психологический прием. Чувак написал идеальный код. Ждет заслуженную похвалу. А вместо этого бац: "Почему импорты со звездочками?" Его переполняют эмоции. Он вместо того, чтобы спокойно выбирать между похожими оферами, сидит и думает, как же это возможно. И тут ему предлагают все замечания конструктивно обсудить, обсуждают, у него появляется возможность проявить свои софт-скиллы, он побеждает в деловом споре, и позиция в нашей команде для него начинает ассоциироваться с победой.
На мой взгляд, идеального кода не бывает. Но даже если кто-то думает, что он такой код написал, он должен уметь обосновать эту оценку и аргументированно отвергнуть придирки, а иначе от его перфекционизма будет мало толку.
Почему? Не воспринимаете критику?
Можно мне к вам на собеседование прийти?