Diferenças e semelhanças entre Bugs e Features
Tags: productivity
Published: 2021-01-23 20:51:24

![grafíte de abelhas voando em bicicletas](https://dev-to-uploads.s3.amazonaws.com/i/3x672gfigp14btik9xae.jpg)

Gostaria de tentar esclarecer dois conceitos próximos que geram algumas interpretações erradas no dia a dia que são as Diferenças e semelhanças entre Bugs e Features. Existe um senso comum sobre o que cada um desses termos significa, entretanto nós fazemos um uso tão frequente deles que acabamos caindo em armadilhas e nem percebemos. 

#### Senso comum: 

Uma **feature** é um recurso novo que está sendo adicionado ao _software_ com o objetivo de complementar ou expandir as funcionalidades existentes. 

Um **bug** geralmente é uma divergência entre o que se espera e o que se tem em um _software_, em outras palavras é quando o _software_ se comporta de forma diferente do que se espera. 

Baseado nessa premissa é bem difícil confundir um bug com uma feature dado que eles possuem significados diferentes e acontecem em momentos diferentes. É baseado nesse senso comum que surgem os problemas. 

 

#### Vamos imaginar o cenário: 

Uma Loja Física de camiseta decide vender seus produtos na web e para isso contrata uma Agência para construir o _e-commerce_ de camisetas. 
 
Ao longo do processo é definido que a página do produto deveria ter:

- Foto da camiseta 
- Descrição da camiseta 
- Botão “comprar” 
- Campo para cálculo de frete 

A Agência desenvolve a página de produto e entrega para o cliente, com o passar do tempo várias camisetas são cadastradas e disponibilizadas no _e-commerce_. 

No decorrer do tempo e com _feedbacks_ recebidos pelos usuários, a Loja Física decide que seria interessante adicionar uma foto da estampa da camiseta como alternativa para seus usuários terem mais clareza sobre o que eles estão comprando. A Agência desenvolve a feature e entrega para o cliente, novos produtos são cadastrados e a imagem alternativa está lá como esperado. 

Mais alguns dias se passam e a Loja Física percebe que a imagem alternativa só aparece nos produtos novos e não nos antigos e decide reportar a situação como um **bug**. A Agência rebate dizendo que a **feature** foi implementada corretamente e caso seja do interesse da Loja Física ter a imagem alternativa nos produtos antigos ela deve fazer um novo contrato. É aqui que começa as divergências. 
<br/>
Afinal, adicionar a imagem alternativa nos produtos antigos é corrigir um bug ou adicionar uma feature? 
<br/>
Esse problema possui pelo menos duas dimensões, a falta de Critérios de Aceite e a forma como que a feature foi implementada originalmente. Analisando com um pouco mais de profundidade, começando pela forma com que a feature foi implementada.  

Frequentemente _e-commerces_ e portais de notícias adotam uma técnica de implementação chamada _static site generator_ que consiste em a partir de dados brutos gerar um site estático em HTML, caso essa abordagem tenha sido adotada a afirmação da Agência está correta, dado que cada página de produto é independente umas das outras e será necessário um _rebuild_ das páginas antigas para ter a feature nova, normalmente essa abordagem é motivada por performance. Caso o _e-commerce_ tenha sido implementado usando um padrão _REST_ que monta a página a cada _request_ a Loja Física está correta em afirmar que é um bug. 

Se analisarmos a partir dos Critérios de Aceite, se no momento em que a feature foi planejada e desenvolvida não foi especificado que ela deveria funcionar para páginas antigas e novas então a Agência está correta. Por sua vez a Loja Física poderia argumentar e com razão que, é óbvio que deveria funcionar para produtos antigos e novos e que esse critério de aceite já está subentendido. Entretanto o óbvio e o subentendido são a causa raiz de vários males, mas este é um assunto para outra conversa. 
<br/>
Outros aspectos que podemos identificar sobre bugs e features:  

Bugs normalmente são impeditivos, em muitos casos demandam ações corretivas imediatas, bugs deveriam ter vida curta para identificá-los e corrigi-los. 

Features não são impeditivas, demandam planejamento e critérios de aceite, features possuem vida longa e se tornam frágeis com o passar do tempo quando desenvolvidas com pressa ou sem reavaliação. 
<br/>

#### Conclusão 

Nem sempre é fácil diferenciar um bug de uma feature e identificar de forma errada pode causar desentendimento entre as partes.  

Uma feature que é tratada como um bug normalmente é desenvolvida com pressa, testes são negligenciados e a qualidade fica abaixo do que se espera. Um bug que é tratado como uma feature demora para ser corrigido, degrada a qualidade do _software_ e gera impacto negativo nos usuários finais. 

Nesse artigo foi adotado um exemplo de apenas duas dimensões, mas no mundo real problemas como esse podem ter muito mais, o importante aqui não é tentar identificar todas elas, mas entender que esses enganos acontecem. Ter um conhecimento mais aprofundado sobre o assunto nos ajuda a se organizar melhor, definir prioridades de forma mais assertiva e por fim diminuir o ruído na comunicação entre o time.

<small>Photo credit: Matt Lively, 27 Beecycles. NEON District Mural. Commissioned by Virginia MOCA. Photograph by Glen McClure. October 2015</small>