Breaking Changes em Aplicações

Belchior Oliveira — Thu, 28 Jan 2021 01:36:36 +0000

Gostaria de tentar esclarecer o significado de um termo frequentemente usado no desenvolvimento de software que é o Breaking Changes

Breaking Changes é uma comunicação entre criadores de libraries/frameworks e seus usuários afim de informar que houve mudanças nas API públicas do softwares e dependendo que como a tecnologia for usada pode causar comportamentos inesperados, não necessariamente erros.

Do ponto de vista de uma aplicação os criadores são os times (squads) que são compostos de pessoas de diferentes áreas não apenas desenvolvedores, já os usuários normalmente são os clientes da empresa e/ou pessoas internas de outras áreas. Dentro desse escopo uma breaking changes é uma mudança no uso da aplicação que pode gerar um resultado inesperado.

No nosso dia a dia nós usamos o termo para se referir a:

Inclusão de funcionalidades
Correções de bugs
Mudanças internas da qual os usuários não conhecem ou não usam

Sendo que nenhum desses casos representam uma breaking change.

Mudanças internas mesmo aquelas que podem quebrar algum código existente não representam uma breaking change, dado que é de responsabilidade dos criadores manter as API internas do software funcionando com o passar do tempo.

Um uso correto do termo seria:

Informar a remoção de uma funcionalidade pública.
Informar que houve mudanças de regras de uma funcionalidade pública de tal forma que possa gerar um comportamento inesperado.

Em linhas gerais, deveria ser raros os casos onde uma aplicação gera uma breaking change.

Diferenças e semelhanças entre Bugs e Features

Belchior Oliveira — Sat, 23 Jan 2021 20:51:24 +0000

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.

Afinal, adicionar a imagem alternativa nos produtos antigos é corrigir um bug ou adicionar uma feature?

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.

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.

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.

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

DEV Community: Belchior Oliveira

Breaking Changes em Aplicações

Diferenças e semelhanças entre Bugs e Features

Senso comum:

Vamos imaginar o cenário:

Conclusão