<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Bibi @debugadora</title>
    <description>The latest articles on DEV Community by Bibi @debugadora (@leticiabibiano).</description>
    <link>https://dev.to/leticiabibiano</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1011954%2F65583f55-5ee3-4f7e-9af5-e20e3d556411.png</url>
      <title>DEV Community: Bibi @debugadora</title>
      <link>https://dev.to/leticiabibiano</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/leticiabibiano"/>
    <language>en</language>
    <item>
      <title>Feature Toggle or Feature Flag</title>
      <dc:creator>Bibi @debugadora</dc:creator>
      <pubDate>Tue, 12 Mar 2024 00:10:44 +0000</pubDate>
      <link>https://dev.to/leticiabibiano/feature-toggle-or-feature-flag-3i79</link>
      <guid>https://dev.to/leticiabibiano/feature-toggle-or-feature-flag-3i79</guid>
      <description>&lt;p&gt;These are two different names for the same practice, much like a light switch. When turned on, a feature is active; when turned off, it's inactive. This is a good technique for testing new features in a real-time production environment.&lt;/p&gt;

&lt;p&gt;It's not just about hiding unfinished code; it's a way to alter the system's behavior and test new solutions without meddling with the codebase or project infrastructure.&lt;/p&gt;

&lt;p&gt;A classic example: when a social network updates its interface, users have the option to "Enable" the new look or stick with the old one. Technically, this is facilitated by a feature toggle. Users simply activate or deactivate this little button called Feature Toggle/Flag as they wish.&lt;/p&gt;

&lt;p&gt;This approach lends itself perfectly to A/B testing and experiments, allowing you to gather data and metrics to determine the most effective approach.&lt;/p&gt;

&lt;p&gt;However, it should be used in moderation. Having a usability plan for Feature Toggles is crucial. Sometimes, toggles may not be the best option, especially if it's more expensive to implement a toggle than to simply rewrite the code. And if your application integrates with external services, carefully mapping out the toggles is necessary to avoid confusion.&lt;/p&gt;

&lt;p&gt;It's often said that Feature Toggles are disguised technical debt, so it's essential to plan their end alongside their creation. Good Feature Toggles have an expiration date: if the solution is effective, it stays; otherwise, it's discarded. Best practices recommend having a limited number of active toggles in production to simplify code maintenance and ensure team sanity.&lt;/p&gt;

&lt;p&gt;The use of Feature Toggles should be carefully analyzed because, after all, our mission as professionals is to solve problems and implement effective solutions.&lt;/p&gt;

&lt;p&gt;In the Ruby programming world, tools like the &lt;em&gt;Flipper gem&lt;/em&gt; simplify toggle management. If you know better alternatives, feel free to share!&lt;/p&gt;

&lt;p&gt;For other technologies, it's essential to research the best tools for using Feature Toggles. &lt;strong&gt;GOOD USE IS LINKED TO A GOOD TOOL&lt;/strong&gt;, here are some examples:&lt;/p&gt;

&lt;p&gt;React/JavaScript: the library &lt;em&gt;react-feature-toggle&lt;/em&gt;.&lt;br&gt;
Java: the library &lt;em&gt;Togglz&lt;/em&gt;.&lt;br&gt;
Flutter: the package &lt;em&gt;feature_flags&lt;/em&gt;.&lt;br&gt;
Python: the library &lt;em&gt;toggler&lt;/em&gt;.&lt;br&gt;
If you know of other tools, share them!&lt;/p&gt;

&lt;p&gt;Remember, although Feature Toggles are a good practice, USE THEM SPARINGLY!&lt;/p&gt;

</description>
      <category>development</category>
      <category>feature</category>
      <category>toggle</category>
      <category>flag</category>
    </item>
    <item>
      <title>Feature Toggle ou Feature Flag</title>
      <dc:creator>Bibi @debugadora</dc:creator>
      <pubDate>Tue, 12 Mar 2024 00:07:37 +0000</pubDate>
      <link>https://dev.to/leticiabibiano/feature-toggle-ou-feature-flag-4g2</link>
      <guid>https://dev.to/leticiabibiano/feature-toggle-ou-feature-flag-4g2</guid>
      <description>&lt;p&gt;Esses são dois nomes diferentes para a mesma prática, semelhante a um interruptor de luz. Quando ligado, uma funcionalidade está ativa; quando desligado, está inativa. Essa é uma boa técnica para testar novas funcionalidades em um ambiente de produção em tempo real.&lt;/p&gt;

&lt;p&gt;Não se trata apenas de ocultar códigos ainda inacabados; é uma maneira de alterar o comportamento do sistema e testar novas soluções sem mexer na base de código ou na infraestrutura do projeto.&lt;/p&gt;

&lt;p&gt;Um exemplo clássico: quando uma rede social atualiza sua interface, os usuários têm a opção de "Ativar" o novo visual ou continuar com o antigo. Tecnicamente, isso é facilitado por um &lt;em&gt;feature toggle&lt;/em&gt;. Os usuários simplesmente ativam ou desativam esse botãozinho chamado Feature Toggle/Flag, de acordo com o que querem.&lt;/p&gt;

&lt;p&gt;Essa abordagem se adequa perfeitamente a testes A/B e experimentos, permitindo coletar dados e métricas para determinar qual a abordagem mais eficaz.&lt;/p&gt;

&lt;p&gt;No entanto, deve ser usado com moderação. Ter um plano de usabilidade para os &lt;em&gt;Feature Toggles&lt;/em&gt; é crucial. Às vezes, os toggles podem não ser a melhor opção, especialmente se for mais caro implementar um toggle do que simplesmente apagar o código antigo e escrever um novo. E, se sua aplicação se integra a serviços externos, é necessário mapear cuidadosamente os toggles para evitar confusão.&lt;/p&gt;

&lt;p&gt;Costuma-se dizer que &lt;em&gt;Feature Toggles&lt;/em&gt; são débitos técnicos disfarçados, então é essencial planejar o seu fim junto com sua criação. Bons &lt;em&gt;Feature Toggles&lt;/em&gt; têm data de validade: se a solução for eficaz, ela permanece; caso contrário, é descartada. &lt;br&gt;
Boas práticas recomendam ter um número limitado de toggles ativos em produção para simplificar a manutenção do código e garantir a sanidade da equipe.&lt;/p&gt;

&lt;p&gt;O uso dos ou das Feature Toggles deve ser muito bem analisado, afinal, essa é a nossa missão como profissionais: resolver problemas e implementar soluções eficazes.&lt;/p&gt;

&lt;p&gt;No mundo da programação Ruby, ferramentas como a gem Flipper simplificam o gerenciamento de toggles. Se conhecer melhores alternativas, sinta-se à vontade para compartilhar!&lt;/p&gt;

&lt;p&gt;Para outras tecnologias, é essencial pesquisar as melhores ferramentas para usar Feature Toggles, &lt;strong&gt;O BOM USO ESTÁ LIGADO A BOA FERRAMENTA&lt;/strong&gt;, aqui estão alguns exemplos:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;React/JavaScript: a biblioteca &lt;em&gt;react-feature-toggle&lt;/em&gt;.&lt;/li&gt;
&lt;li&gt;Java: a biblioteca &lt;em&gt;Togglz&lt;/em&gt;.&lt;/li&gt;
&lt;li&gt;Flutter: o package &lt;em&gt;feature_flags&lt;/em&gt;.&lt;/li&gt;
&lt;li&gt;Pytho: a biblioteca &lt;em&gt;toggler&lt;/em&gt;.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Se souber de outras ferramentas, compartilha aí!&lt;/p&gt;

&lt;p&gt;Lembre-se, embora Feature Toggles sejam uma boa prática, USE COM MODERAÇÃO! &lt;/p&gt;

</description>
      <category>feature</category>
      <category>toggle</category>
      <category>flag</category>
      <category>development</category>
    </item>
  </channel>
</rss>
