Design de software: programação tática ou estratégica?

Em diversos times de desenvolvimento de software sempre acontece o planejamento de quais tecnologias utilizar, qual arquitetura, metodologia, qual design de projeto etc, mas raramente se fala em design de software ou qual forma de desenvolvimento devemos seguir: programação tática ou estratégica.

Antes de entender sobre programação tática ou estratégica, precisamos de uma breve introdução sobre design de software. O design de software consiste em isolar complexidades, simplificar o código para futuras manutenções, trabalhar por partes (modularizar), saber identificar pontos críticos de código e trabalhar em cima, ou seja, design de software é algo complexo, é algo que tem que estar presente no seu trabalho antes de iniciar um desenvolvimento e mesmo depois de já termos código implementado (identificar futuros problemas, aplicar melhorias e corrigir débitos técnicos).

Por isso o design de software combina muito bem com a metodologia ágil, pois você acaba trabalhando em pequenas partes do produto, as falhas irão surgir e você já irá atuar em cima da solução e já pensar em isolar a solução para futuros problemas.

“Software é maleável, diferente de sistemas físicos. Você pode alterar o software no meio da sua construção, mas não pode mudar o número de torres que sustentam uma ponte, por exemplo.”

A Philosophy of software design.

Sintomas de complexidade

• Problemas de repetição de código.
• Carga cognitiva: Quanto o programador precisa saber para terminar uma tarefa?
• Em que parte do código tem que modificar?

Um dos objetivos do bom design é que um sistema seja óbvio. Fácil entendimento e saber onde mexer.

Complexidade é causada por duas coisas: dependências e obscuridade. Podemos reduzir complexidade cuidando alguns pontos, como:

• Tentar reduzir as dependências.
• Deixar as dependências mais óbvias, exemplo: uma variável ambiente que vários arquivos consomem.
• Obscuridade: quando informações importantes não são óbvias.
• Variáveis com nomes ruins.
• Tipo da variável.
• Inconsistência também é obscuro, por exemplo, o mesmo nome de variável para duas coisas diferentes.
• A complexidade ocorre porque centenas ou milhares de pequenas dependências e obscuridades se acumulam ao longo do tempo.

Agora que entendemos um pouco o fluxo de design de software entram os profissionais programadores, eles aplicam design de software nas suas atividades?

Existem dois tipos de programadores (no conceito de programação tática e estratégica): quem nunca teve no time um “super ágil” ou “ninja”, que termina sua tarefa em poucas horas, resolve todos os bugs magicamente? Pois é, infelizmente este sujeito, muitas vezes, não aplica um bom design em seus códigos e pratica a programação tática, não se preocupa em manutenção futura, tipagens corretas, não realiza testes, ele cria métodos que fazem inúmeras coisas, o importante para ele é que a feature funcione, legitimo “go horse”.

O código desse programador, muitas vezes, virá um “brownfield”. O que é um brownfield? É um terreno infértil, onde não cresce nenhuma vegetação, abandonado, onde houve alguma indústria.

Será difícil dar manutenção a esse código, um pedido de uma nova feature será um pesadelo e, muitas vezes, será mais barato implementar do zero.

“Se você programa iterativamente e não aplica práticas de engenharia ágil, sua base de código morrerá em dois ou três anos… Não se preocupar com o design em um processo iterativo torna o projeto insustentável.”

James Shore

Não preciso falar muito da programação estratégica, seus resultados são o contrário do programador tático: pensa no futuro, em modularizar seus métodos, componentes e até tipos, pensa em reaproveitamento de código, em isolar complexidades e pensa no próximo que irá dar futuras manutenções ao código, deixando o código de simples entendimento.

“Escoteiros deveriam deixar o local melhor do que o encontraram.”

Baden-Powell

Para finalizar, então, vamos seguir esta receitinha de bolo e ser superestratégicos, isolando tudo o que for função e método para reaproveitamento? Não! Erradíssimo.

Temos que aplicar, sim, a programação estratégica, mas com moderação. É válido você sair modularizando lógicas complexas ou métodos, pensando em reaproveitamento futuro, sendo que você sabe e tem certeza que este método será usado apenas uma ou duas vezes? Neste caso, eu acredito que não. Muitas vezes, sair abstraindo tudo pode até demorar mais do que fazer tudo na mesma tela (caso frontend).

Dicas finais:

• Rapidez < Estratégia!
• Um design de software feito com estratégia gera melhores projetos;
• Planejamento para o futuro numa US é prioridade;
• Planejar o futuro, escrever uma boa documentação;
• 10% a 20% investir em programação estratégica e design. Imergir aos poucos, não saber tudo (cascata);
• Evitar ser o ligeirinho “go horse!”.

Obrigado pela leitura e até a próxima!