Código funcionando não é o suficiente
O código funcionando importa, mas não é suficiente. Para chegar até esse resultado alguma abordagem foi utilizada para resolver o problema (seja um bug, uma feature).
E qual foi essa abordagem? Foi uma ação direto ao ponto pensando em escrever o código o mais rápido possível ou foi algo mais estratégico procurando investir tempo em escrever um design mais limpo?
Vamos entender porque uma abordagem mais estratégica se paga e produz melhores designs ao longo do tempo. Mas antes, vamos batizar melhor esses termos: Programação Tática e Programação Estratégica.
Programação Tática
Programação tática é nada mais que uma mentalidade da qual o desenvolvedor assume que o principal foco é fazer com que alguma coisa funcione, seja uma nova feature ou um bug. Parece sensato, não? O que seria mais importante do que ter o software funcionando?
O problema dessa maneira de pensar é que vê uma mudança de forma muito micro, míope e sempre simples, direto ao ponto, sem olhar para o sistema/componente na totalidade. A meta é finalizar assim que possível a tarefa, às vezes até por alguma limitação como prazo. Não se está buscando o melhor design, mas sim terminar o trabalho quanto antes.
É com sucessivas condutas como essa que o software se torna complexo. Não será uma ação com esse modus operandi que irá causar problemas, mas a continuidade do hábito será prejudicial e até irreversível para a saúde do projeto.
Situações como essa são infelizmente comuns. Projetos que começam a atrasar e trabalhar com deadlines agressivas são muitas vezes submetidos a uma programação tática.
A maneira tática de escrever software pode também ser cultural, de empresas que valorizam profissionais resultadistas, verdadeiros corredores profissionais. Poderíamos chamá-los também de herois, programadores táticos, tornados táticos.
Por necessidade, um dia esse código terá que ser limpo, arrumando toda bagunça feita por programadores táticos. Essa limpeza vai fazer parecer que os engenheiros que buscam organização, bom design e boas práticas são mais lentos do que os anteriores. Mundo injusto, não?
Programação Estratégica
Programação estratégica é compreender que o código funcionando não é o suficiente. Você não deveria introduzir complexidades para terminar uma tarefa às pressas. É preciso uma visão holística do cenário, pensando em visão médio/longo prazo. Essa abordagem é muito importante em projetos que estão em início de desenvolvimento. A maioria do codebase escrito serão as estruturas-base das evoluções futuras.
E para escrever um bom design, quais perguntas poderíamos nos fazer para encontrar oportunidades? Seguem algumas sugestões que podem ajudar a pensar de forma estratégica o que se está fazendo.
- Esse código poderia ser mais bem escrito?
- Caberia aqui usar algum pattern ou uma boa prática?
- Existe algum caso de teste que esquecemos?
- Nesse contexto, quais os melhores cenários de teste precisamos validar?
- Precisamos pensar em retrocompatibilidade?
- O quão fácil será uma próxima evolução nessa nova feature?
- Já escrevemos documentação para o que estamos fazendo?
Encontrar oportunidades e abordar os problemas dessa forma naturalmente levam mais tempo do que ir direto ao ponto. Porém, é importante entender que se está investindo na saúde do projeto no decorrer de seu desenvolvimento.
De qualquer forma, não importa o quanto se invista, é inevitável encontrar problemas e decisões de design que poderiam ter sido melhores. É um processo natural da evolução do software. Essas são oportunidades de ouro para diminuir complexidades e buscar um bom design utilizando abordagem estratégica.
Bom, então eu preciso sempre pensar de forma estratégica ?
Não necessariamente. É preciso entender que programação estratégica é um investimento. Não é saudável tentar projetar um sistema inteiro de uma única vez. Portanto, pode-se pensar quanto investir em cada ciclo de entregas do projeto.
Para John Ousterhout, a sugestão é utilizar entre 10 e 20% do tempo total de desenvolvimento de uma iteração com abordagem estratégica. Este valor é pequeno o suficiente para não afetar prazos de forma significativa, mas grande o suficiente para produzir benefícios sinificativos ao longo do tempo.
Como pode ser visto na imagem acima, dentro de alguns meses, o projeto irá experimentar um tempo 10 a 20% menor em suas entregas decorrente dos investimentos feitos. Isso comprova que ao longo do tempo os investimentos se pagam.
Se uma abordagem puramente tática tivesse sido aplicada desde o início, é bem provável que o tempo para finalizar o projeto seria menor. Mas aqui vale escolher entre entregar rápido ou com qualidade. Se escolher inteiramente a abordagem tática, é bem provável que ao longo do tempo fique cada vez mais lento para entregar software decorrente da complexidade acumulada.
Conclusão
Bom design não vem de graça. Não é possível desenhar a melhor solução para uma aplicação no dia 0. É necessário que se invista continuamente para que os pequenos problemas não se acumulem em grandes.
Sabemos que essas abordagens têm influências de cultura, pessoas, planejamento, empresas e toda a diversidade que isso produz. Mas qualidade deve ser inegociável.
É importante enxergar abordagens estratégicas como investimentos de longo prazo, ou seja, precisam começar hoje e não amanhã. Quanto mais tempo se esperar para resolver problemas, maiores eles ficarão.
“É claro que um código ruim já lhe atrasou. Mas por que você o escreveu desssa forma?”
Robert C. Martin
Este texto foi inspirado no segundo capítulo do livro “A Philosophy of Software Design”
