Eu tenho gostado de codar muito ultimamente, trabalhando em pequenos projetos paralelos, como o DNS Spy ou ferramentas open source, como minhas recentes aventuras em Go. Mas como sou só eu e mais ninguém, tenho que priorizar determinados recursos ou tarefas, nos quais achei o conceito de Release Notes Driven Development muito interessante.

É um tópico que surgiu no último podcast do Under the Radar, que levou a este texto.

Priorizando coisas como um único desenvolvedor ou uma equipe pequena

Meu código está cheio de dívidas técnicas. Desde as primeiras ferramentas PHP que escrevi há uma década até recentes projetos open source, como minhas configurações Varnish, todos e cada um deles tinham falhas e melhorias conhecidas.

O fato é que eu conheço essas falhas. Conheço essas dívidas técnicas. Estou ciente delas, então posso encontrar uma solução para elas e ajustá-las dentro da minha cabeça ao desenvolver novos recursos; assim, eu sei como não romper o antigo comportamento do meu código.

A maior parte do meu código também não possui testes unitários por uma razão similar. Não porque não vejo valor neles, mas porque não posso priorizá-los em boa consciência.

Por quê? Porque eles fazem péssimas notas de lançamento.

O fato é que: se eu tiver algumas horas sobrando e trabalhar em meus projetos, eu quero algo significativo como resultado. Eu quero algo para tirar onda no Twitter. Para mostrar aos meus usuários. Para adicionar um recurso que está em alta demanda.

Notas de lançamento que importam

Aqui está o que a maioria das notas de lançamento acaba lendo:

• Correções de desempenho e melhorias
• Correções de bugs menores
• Menos travamentos que antes

 

Tenho certeza de que seus usuários se beneficiam disso, mas aqui está um conjunto de notas de lançamento que vale muito mais:

• Adicionar suporte para recurso X
• Adicionar novo layout para Y
• Melhoria da legibilidade e renderização em Z

 

A diferença? Esses são tangíveis, reais, melhorias para seus usuários. As coisas que os usuários esperam.

Claro, menos acidentes são bons também. Claro, correções de bug menores são também. Mas é o que você espera de todas as versões. O software deve aumentar de qualidade.

O que faz real uma diferença? Adicionar recursos, ampliar a funcionalidade e resolver problemas de usuários.

Escreva as notas de lançamento primeiro

O que eu tento fazer para meus projetos é apresentar as notas de lançamento primeiro. Eu não posso chamá-las de notas de lançamento, per sé, mas sim de uma lista de “recursos vulneráveis” para mostrar. Cada linha de código que escrevo a partir daí vai fazer com que essa meta se torne tão eficiente quanto possível, sem sacrificar a funcionalidade ou a estabilidade existentes.

O releases mais recentes do DNS Spy liberaram funcionalidade melhorada de varredura CAA, corrigiram vários problemas relacionados a TTLs dinâmicas e vários erros de renderização, nos quais os domínios apareceriam como fora de sincronia.

O que eu não fiz? Reescrevi as partes principais do meu aplicativo (mesmo que em algumas partes isso seja necessário, pois estou aprendendo mais sobre o framework Laravel e os atalhos que ele oferece), adicionei testes unitários ou reescrevi partes do framework.

Eu deveria ter feito isso? Sim, no devido tempo, mas isso torna as notas de lançamento péssimas e, neste momento, não é um luxo que eu possa pagar.

***

Mattias Geniar faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://ma.ttias.be/release-notes-driven-development-rndd/