Se você é aquele tipo de programador que pensa que o seu código está pronto quando você faz o commit para o repositório, sinto lhe dizer mas você está errado.
Eu sei disso porque eu também já pensei dessa maneira. Por muitos anos eu pensei da seguinte forma: Eu sou programador, portanto meu papel é escrever código. Já que esse é meu papel, a partir do momento que eu entrego o código, significa que o meu trabalho está feito.
Existe um problema de premissa nessa lógica (torta) de pensamento. Seu papel como programador não é escrever código. Seu papel como programador é resolver problema.
Se levarmos ao pé da letra, um software não estará pronto nunca. A única constante no mundo é a mudança. O software, de uma maneira genérica, tem como objetivo facilitar processos do mundo real. Se o mundo está mudando a todo instante, o software deve, necessariamente, mudar também para continuar gerando valor.
Mas meu objetivo não é falar do software como uma forma abstrata. Eu quero descer um pouco mais o nível e falar sobre as funcionalidades que compõem um software. Mais especificamente sobre o código que compõe essa funcionalidade.
Quando a gente pode considerar que um código foi entregue?
Porque escrevemos código…
O software sempre nasce com o objetivo de resolver um problema da vida real. Ele é feito de humanos, para humanos.
A funcionalidade surge, geralmente, no momento em que o usuário de um software identifica um problema e entende que esse problema pode ser resolvido pelo software.
Vamos imaginar o cenário: Seu cliente tem um problema. Você conversa com o cliente, entende o problema dele. Feito isso, você imagina qual a melhor solução para isso. Com a solução mais ou menos desenhada na sua cabeça, você senta a bunda na cadeira e vai para a parte mais divertida, que é codar. No final do dia você fez algo super legal. Faz o commit para o repositório e termina de codar.
Seu código foi entregue? Para responder é simples, basta fazer outra pergunta: Neste exato momento, o cliente tem o problema dele resolvido? Não! Portanto, seu código ainda não está pronto.
Seu código só vai estar pronto no momento em que resolver o problema do seu cliente. Seu código só vai estar pronto no momento em que gerar valor ao seu cliente.
E quando acontece isso? Quando ele vai para produção, seu cliente começa a utilizá-lo e então percebe que teve seu problema resolvido.
Ou seja: Código pronto é código em produção sendo usado.
Como entregar código que resolve problema?
O grande erro de todos nós programadores sempre é o mesmo: achar que sabemos o que o nosso cliente quer. Não, a gente não sabe. Nós, no máximo, temos hipóteses.
Para contornar este problema, a solução é entregar o código o mais rápido possível para que o cliente possa utilizar e entender se aquela solução resolve o problema dele ou não.
Com isso, nós estamos validando uma hipótese de solução.
Então, quanto mais rápido nós produzirmos código, mais rápido vamos entregar o código, certo? ERRADO!
O objetivo não é produzir código rápido, o objetivo é entregar o código rápido. Entregar esse código significa entregá-lo funcionando sem que o resto do sistema tenha sido afetado. Devemos resolver problemas, e não gerar mais problemas.
O software precisa ser sustentável. O código precisa ser sustentável. Para desenvolver código sustentável é preciso parar de pensar em quantidade e começar a pensar em qualidade.
Escrever código com qualidade é mais demorado no curto prazo, porém nos poupa tempo (dinheiro) de manutenção no futuro. No longo prazo, temos menos desperdício de recursos.
Software sustentável é um software que tem a capacidade de reagir bem a mudanças. Para garantir isso, precisamos criar código, testar o código que criamos e garantir que este novo código funcione bem junto aos códigos antigos.
