Código perfeito existe sim. E tartarugas não sobem em árvores.

Código perfeito existe sim!

Ontem eu li um artigo que dizia aos programadores para não procurarem o código perfeito por que ele não existia do Jim Bird e e sinceramente eu discordo: É claro que existe.

Código perfeito existe sim, o problema é a definição de perfeição.

Perfeição em código não é a mesma coisa que a perfeição de uma peça usinada com espaço para erro de meio mícron, perfeição em software é uma medida de dureza, eu explico.

Perfeição em software é uma medida de dureza.

Um software ruim todo mundo consegue definir, colecionar adjetivos para classificar o ruim é fácil por que as pessoas tendem a cooperar nesse tipo de atividade e basta que uma pessoa bem qualificada diga que o código é ruim para muita gente surgir com o mesmo conceito, mais ou menos como aquele efeito que o scrum poker tenta controlar.

Vende cerveja quente X tem cerveja muito gelada 90% do tempo?

Dizer que um software é ruim é fácil do ponto de vista da argumentação, parecemos ser equipados para ver o ruim. Coloque 10 cervejas geladas na mesa do bar e se uma delas não estiver muito gelada o bar vai ser aquele que vende cerveja quente e não aquele que tem cerveja muito gelada 90% do tempo. As pessoas se apoiam quando falam mal por que na maior parte do tempo você não precisa falar, basta soltar uma interjeição aqui e ali, um “vixiii”, um “putz”, e vários “nooossaaa”.

Na maioria das vezes não é necessário argumentar sobre o por que de um software ser ruim. Isso diz muito dos profissionais que dizem “precisa reescrever tudo”.

E software bom, como dizer que um software é bom? Que características definem a perfeição de um software? Escolhi duas e você escolhe se é uma escolha subjetiva ou não.

Entrega o valor
A primeira coisa que um software perfeito não abre mão é realizar com sucesso a tarefa a que se propõe. Veja, o código não é perfeito mas o software executa a tarefa e faz isso no tempo necessário, com os recursos disponíveis e de maneira estável.Perfeito!

Maleável
Vou falar primeiro de rigidez, aquele software que não consegue responder a uma mudança requisitada.

Aquele software que exige do programador que ele lute contra seu código ao invés de construir com seu código.

Se um código é maleável então é capaz de aderir as mudanças dentro de um tempo aceitável(racionalmente aceitável, sem subjetividade) de trabalho. A arquitetura e o código colaboram para isso e o programador encontra ferramentas para desenvolver a nova funcionalidade.

Ao invés de batalhas a cada passo do caminho, o código maleável oferece uma estalagem com cerveja amanteigada e uma erva especial do condado.

Pronto, entregar o valor e ser maleável são o suficiente para criar o cenário da perfeição. Você pode parar de ler aqui se quiser, ou pode praticar comigo o esquecido ritual da reflexão sobre as consequências de uma declaração.

Exemplo, um script de processamento de um csv entrega o valor de processar um csv e gravar no sgdb? Sim? Ele é perfeito? Sim! Mas ele não é Orientado a objeto! Não importa!

Pediram para esse mesmo script começar a processar arquivos csv de um formato diferente e o programador adicionou condições no código. O script continua rodando estável? Sim. O script processa os dois formatos? Sim. O script é perfeito? Sim.

Pediram para o script começar a processar mais 3 formatos diferentes. O programador adicionou condições no código para fazer a entrega mas pediu um mês para isso (cada um dos formatos anteriores levou 4 horas). Esse tempo é aceitável? Não. O script continua estável? Não. O script é perfeito? Não. Ahhhh, mas por queee????!!!

Por que ele não entrega o valor prometido e não tem um tempo de desenvolvimento aceitável para novas features.

É muito provável que o tempo de um mês seja necessário por que a essa altura já não dá para ler o código e tampouco adicionar uma condição sem quebrar outra.

O que aconteceu para transformar a perfeição em desastre em tão pouco tempo?

Partindo do início, o trabalho de um analista/programador é identificar padrões e nesse caso ele não identificou o padrão de que novos formatos de arquivo continuariam chegando. Ele não conversou com o cliente e por não ter identificado o padrão ele não se preparou para ele e não tomou uma decisão para controlar a complexidade crescente da tarefa de maneira que a complexidade engoliu o tempo e o dinheiro dos envolvidos.

Vestir a camiseta mais gasta do ramones, pegar um copo de café e ir falar com as pessoas do escritório interessadas no produto ou código cuja complexidade você notou que está saindo do controle.

Proposta?Sim. Preste atenção na complexidade de uma tarefa e no ritmo com que essa complexidade cresce. Quanto maior o ritmo mais rápido você precisa reagir coletando dados para poder direcionar seus esforços e quando digo coletar dados eu quero dizer tirar a bunda da cadeira, vestir a camiseta mais gasta do ramones, pegar um copo de café e ir falar com as pessoas do escritório interessadas no produto ou código cuja complexidade você notou que está saindo do controle.

Agora, voltando. A questão da perfeição em software. E se o programador tivesse notado o padrão de novos formatos no script de processamento do csv e reagisse?

Ao notar o padrão de novos arquivos o programador ia se preparar para ele, fornecendo uma código para lidar com a seleção de formato e separar os processos de leitura de cada um deles. Ele começaria a fazer isso de uma maneira simples, extraindo funções, organizando uma estratégia, separando conceitos e administrando um débito técnico aceitável que ele decidiu implementar somente se realmente novos formatos surgissem.

Isso manteria o código capaz de responder a mudanças num tempo aceitável e manteria a estabilidade do software.

Software perfeito mesmo com débito técnico? Sim!!!! Ahhhh mas por queee???!!

Débito técnico não é uma característica ruim, portanto que você tenha colocado ele lá de uma maneira consciente por que definiu postergar uma característica do algoritmo para quando ela fosse realmente necessária.

Débito técnico ruim é mais como tartarugas em cima de árvores. Todo mundo sabe que tartaruga não sobe em árvore e ninguém sabe como elas foram parar lá. Isso é problema.

Da próxima vez que você ouvir alguém falando de código perfeito lembre dessas características: Entrega de valor e Maleabilidade. E pense nas consequências da aplicação desses dois únicos conceitos.

Advertisements

One thought on “Código perfeito existe sim. E tartarugas não sobem em árvores.

  1. Mto bom artigo parabéns!!! Realmente, se o código “entrega” o valor esperado em um tempo de manutenção aceitável ele é perfeito, agora se ele está sob o paradigma X ou Y é outra questão e passa ao largo se código ali é robusto ou não…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s