Estratégia e Tática — na programação
Quando usar a estratégia e a tática na programação
Em 2022 assisti uma palestra ministrada pelo Elton Minetto na Codecon onde ele falava de "Reflexão sobre design de software" e citava esses dois tipos de formas de programar. Na palestra ele comenta que uma não é o contrario da outra, e convida as pessoas a entender qual é a melhor forma para o contexto que você está inserido.
Inspirado nesta palestra, decidi trazer neste artigo alguns pontos para nos ajudar a entender essas duas palavras na programação.
Tática vs Estratégia — Conceitos
Fazendo algumas pesquisas na internet você consegue achar rapidamente comparações, com exemplos, entre tática e a estratégia.
Muitos dizendo que a tática não existe sem a estratégia, ou que a estratégia define a tática e não o contrario. Eu acredito em tudo isso, mas neste artigo a definição que usarei é:
A tática é para o curto prazo e a estratégia é para o longo prazo.
Quando pensamos assim conseguimos entender uma diferença grande entre essas duas palavras.
As consequências de uma tática sem estratégia
Quando pensamos apenas na tática e esquecemos da estratégia, estamos falando de correr sem direção no meio da tempestade.
A tática vai servir muito bem para resolver algo do momento.
Podemos usar o exemplo de um problema que precisa ser resolvido em produção, mas não temos tempo para pensar em alguma estratégia, muitas vezes faremos soluções paliativas que não exploram a profundidade do problema.
E não precisa de muito tempo para logo encontramos novos furos e problemas nas nossas implementações.
Isso tudo ilustra uma trabalho tático sem estratégia, que resolve o problema e que não se aprofunda nele, não entende, não melhora, não explora novos problemas dentro do problema.
É algo que não leva tempo, algo pensado para o curto prazo!
Definindo sua estratégia
Sun Tzu, general, estrategista e filósofo chinês disse:
Se você conhece o inimigo e conhece a si mesmo, não precisa temer o resultado de cem batalhas. Se você se conhece mas não conhece o inimigo, para cada vitória ganha sofrerá também uma derrota. Se você não conhece nem o inimigo nem a si mesmo, perderá todas as batalhas…
Você está indo para suas batalhas sem uma estratégia? E até o momento não deu nada errado? Você está, com toda a certeza, contando com a sorte!
Com estratégia eu quero dizer soluções abstratas ou previamente definidas. São soluções que não resolvem o problema, mas que te fazem ter uma noção previa do que estar por vir e ajudam a resolver.
"Conheça seu inimi, digo, problema!"
Alguns passos para ter uma estratégia para a maioria dos problemas:
Conheça o problema
Pode parecer um conselho óbvio mas é muito importante!!
Sem esse primeiro passo qualquer outro ponto vai parecer muito vago, então primeiro você precisa conhecer o problema que você vai atuar!
Nos processos de gerência de projetos mais comuns as demandas chegaram a partir do time de produto ou negócio. Garanta que essas demandas estejam bem escritas, com exemplos, casos de testes e requisitos bem definidos.
Não consegue ter essas informações? Escreva o que te passaram e apresente novamente para o time, use esse momento de apresentar para validar o que te foi passado e para alinhar o que deve ser feito!
Abstraia uma possível solução
Conhecendo o problema, pense e trace a solução, por mais abstrata que ela seja! Uma dica é buscar por fontes e problemas parecidos, não existe problema que já não foi resolvido!
Dificuldades para fazer uma soluções abstrata? De um passo atrás e revise o problema.
Richard Feynman, em seu artigo sobre abstrações, comenta:
You know, I couldn’t do it. I couldn’t reduce it to the freshman level. That means we really don’t understand it. — Richard Feynman
Significa, ao pé da letra: se você não consegue explicar a solução de forma simples, pode ser que seja porquê você não entendeu o problema.
Se antecipe para os riscos
Não é certo que esses riscos realmente vão acontecer, mas se antecipe, pense sobre possíveis consequências da sua solução. O seu eu do futuro agradece!
Usufrua das metodologias
Daily, Refinamento, Planning, Kickoff, DeskCheck, Review, não perca nenhum momento, fale, mostre, apresente, repita sobre sua tarefa em todos os momentos para os seus colegas lembrarem e relembrarem sobre, até o momento em que, se você esquecer de algo, alguém te ajudará a lembrar!
Um dica interessante, que o Thiago Carnevalli, desenvolvedor Android no iFood, sugeriu para lembrar da sua tarefa é a criação de uma documentação, não para o time, mas como um processo de entendimento.
Casos de Teste
Crie casos de teste com cenários hipotéticos, isso vai te ajudar a ter uma visão de usuário, e te lembrar do que cobrir na hora de desenvolver.
Uma dica é usar o método: GIVEN/WHEN/THEN
DADO um certo cenário QUANDO certa coisa acontecer ENTÃO o sistema deve se comportar dessa forma.
Estratégia e depois Tática
Depois de definir uma estratégia é o momento da tática.
Como comentado no início: A estratégia é para o longo prazo, então pensamos nela como uma forma teórica, para se preparar para o momento da tática que, consequentemente, servirá para o curto prazo.
Quando estamos falando de ações voltadas para o curto prazo, estamos querendo fazer essa ações serem mais tangíveis e mais próximas da realidade.
Mapas e Abstrações
Trago um exemplo sobre mapas e abstrações do artigo What Are Abstractions in Software Engineering que podemos usar no exemplo de estratégias e táticas!
Usando a frase: “Um mapa não é um território[…]” de Alfred Korzybski, filósofo e engenheiro polonês, o artigo nos explica o seguinte:
Isso significa que as abstrações não são os objetos que elas abstraem. O rio que você vê no mapa é muito diferente de um rio real. Parece óbvio para um mapa, mas não tão óbvio quando usamos abstração na engenharia de software.
Ou seja, as suas estratégias nem sempre irão refletir a sua realidade, isso é um papel para as ações de curto prazo, para as táticas!
Gosto de ver as táticas como pequenos passos que você da rumo ao destino que você quer chegar.
Constantemente você da esse passo e revisa sua estratégia, se ela está certa, da outro passo e revisa novamente.
Estratégias também dão errado
É muito comum você pensar algo sobre o código, ler sobre ele superficialmente, escrever uma boa estratégia e na hora de colocar a mão na massa cair em um buraco sem fundo.
Definir os caminhos existentes faz parte da estratégia, escolher qual é o melhor caminho, isso, só quem está na linha de frente pode fazer, só a tática pode definir.
Sun Tzu novamente previu esse momento:
Para vencer, deve conhecer perfeitamente a terra e os inimigos. O resto é uma questão de cálculo. Eis a arte da guerra.
E nesse ponto que você vai precisar de uma boa tática:
Minha estratégia principal não deu certo, e agora?
Conhecendo o problema, conhecendo a estratégia que foi definida e não deu certo, você tem os poderes de decisão na mão. Ou você segue com as informações que você tem ou você volta a tarefa para a mesa e refina uma nova estratégia.
Minha estratégia parece estar correta, e agora?
De pequenos passos rumo a vitória! Se você está nitidamente em vantagem, não é hora para se afobar e dar um passo maior que a perna. Continue em vantagem, revisite cada passo que você der em busca de refinar o máximo possível a sua solução.
Então a tática, na programação, deveria ser esses pequenos passos e decisões que devem ser feitos após a estratégia estar dando certo ou ter dado errado.
Conclusão
Vimos como trabalhar com a estratégia e a tática e como pode ser benéfico para criar um fluxo de trabalho organizado.
Espero ter inspirado desenvolvedores a melhorar seu processo pré e pós programático e também ajudado a utilizar a estratégia e a tática de certa forma no seu dia a dia!
Referências
Agradecimentos
Deixando agradecimentos a pessoas incríveis que me ajudaram a revisar o conteúdo desse artigo ❤
Contatos
Mais conteúdos de tecnologia no meu perfil do medium!
Github: https://github.com/Wottrich
