Arte da Guerra e Desenvolvimento de Softwares

Arte da guerra nova capa
Tempo de leitura: 4 minuto(s)

Assista, do YouTube, a um fascinante documentário do History Channel com uma hora e meia de duração, seguindo uma trilha histórica sobre a trajetória de Sun Tzu, um estrategista oriental que documentou suas vitórias em guerras: relatos que perduraram desde sua concepção, até os dias de hoje.

As instruções de Sun Tzu nos permitem refletir ao que concerne o mundo do desenvolvimento de software, uma vez que a profissão exige a tomada de decisões constantemente. Você provavelmente já passou por alguma situação pela qual resolveria melhor se já soubesse desses mandamentos, então prepare-se para os próximos desafios, sabendo responder melhor a eles:

1. Alguns exércitos não devem ser enfrentados

O estrategista reconhece que o orgulho e prepotência são erros fatais. Há mais sabedoria em recuar diante de uma derrota eminente do que em enfrentar um problema com dimensões maiores do que se pode suportar.

Da mesma forma, pode-se exemplificar por uma mudança radical de linguagem, quando se tem pouco a ganhar.
Manter um código perfeito, também, pode ser um oponente invencível.
Pegar um projeto grande com um grau de dificuldade alto sozinho é uma armadilha a se evitar. É preciso haver previsão, gestão e alocação inteligente de mão de obra ao longo do projeto.

2. 4 fatores são determinantes para o sucesso:

Clima

É necessário manter um ambiente com foco na solução. Distrações inoportunas podem vir a ser um problema, reduzindo drasticamente a produtividade e a qualidade do código.

Território

O local de trabalho deve favorecer aspectos como raciocínio e cooperação. Devem ser claros, aos colaboradores dos demais setores, a razão de existência e a relevância do núcleo de desenvolvimento.

Doutrina militar

É importante que se definam princípios e metas para os projetos, como tão bem detalhados em metodologias ágeis.

Influência moral

É preciso conquistar o respeito dos que o cercam, com seriedade no trabalho e uma conduta exemplar.

Para web, eu nomearia os 4 fatores de sucesso: RESTful, Design Patterns, TDD e Componentização.

3. Gerencie com inteligência:

Conte com ferramentas como, por exemplo Gulp (automatizar tarefas); Trello (Kanban); MediaWiki (Base de Conhecimento) e BitBucket (Versionamento privado na nuvem), de tal forma que consiga ter uma visão geral sobre o progresso do trabalho, sozinho ou em equipe.

4. Estratégia

Que seja baseada em informações de valor, experiências passadas, protótipos e projeções. Que seja norteada por um líder flexível e empático. De preferência um líder que já foi desenvolvedor e compreenda as limitações do trabalho de desenvolvimento na prática. O Code Review não é apenas burocracia. É uma forma inteligente pra previnir problemas em produção.

5. Tática

Habitue-se com ações de cautela, de tal forma que as ações sejam tomadas objetivando a entrega contínua de valor.

Se você ainda não se habituou a projetar classes com Design Patterns, comece por aqui.

6. Conheça os seus concorrentes!

Não se compare pensando em depreciar seu trabalho. Se você está perdendo, aprenda logo a jogar como quem está ganhando. Não perca a oportunidade de conhecer os recursos que seu concorrente utiliza. Aquela funcionalidade que sua diretoria tanto admira do “quintal do vizinho” pode ser um simples plugin jQuery.

7. Deixe espaço para realizar manobras

Seja fiel ao sprint e concentre-se em entregar o que está em pauta. Sem contradizer esse objetivo, codifique visando uma expansão futura das funcionalidades. Siga trilhas para a reutilização, coesão e desacoplamento. Assim, expansão e manutenção serão mais produtivas.

8. Tenha uma estrutura sólida:

Eureca! um paradigma já formulado, SOLID, nos diz tudo.

Letra Sigla Nome Definição
S  SRP Principio da Responsabilidade Única Uma classe deve ter um, e somente um, motivo para mudar.
O  OCP Princípio Aberto-Fechado Você deve ser capaz de estender um comportamento de uma classe, sem modificá-lo.
L  LSP Princípio da Substituição de Liskov As classes derivadas devem ser substituíveis por suas classes base.
I  ISP Princípio da Segregação da Interface Muitas interfaces específicas são melhores do que uma interface única.
D  DIP Princípio da inversão da dependência Dependa de uma abstração e não de uma implementação.

Fonte (SOLID)

9. Use um ataque indireto

É comum tentar resolver de uma vez só o problema. Mas não se pode deixar de pensar na necessidade da reutilização de código e futuras manutenções. Em código, pode-se considerar ataque indireto a criação de classes fracamente acopladas, com responsabilidades estritamente definidas por interfaces.

Siga o D do paradigma SOLID: dependa de uma abstração, e não de uma implementação.

Crie abstrações de classes. Ataque indiretamente o problema: deixe que as classes herdeiras reutilizem sua estrutura já existente, seguindo o princípio DRY.

10. Considere algumas razões de ataques estratégicos

Nunca ataque quando estiver por baixo

Adote uma estratégia de defesa e prevenção. Refatore o código o quanto antes for possível ao identificar irregularidades em seu funcionamento. Não é possível saber sempre qual a forma mais perfeita de uma implementação, mas é necessário ter consciência do objetivo de sua codificação e as condições necessárias para que atinja a meta.

Nunca ataque em terreno desconhecido

Lidar com sistemas legados exige um cuidado especial quanto a dependências e detalhes particulares. Cada programador vislumbra a solução de um problema de uma forma. Entenda o padrão aplicado pelo programador da solução antes de aplicar alterações sobre um sistema legado. Saiba exatamente quais funcionalidades serão afetadas.

Procure primeiramente conhecer o conceito aplicado. Fazer alterações em códigos de linguagens desconhecidas ou com conceitos muito abstratos demanda estudos aprofundados.

E resolva todo o problema antes de sua codificação! O esforço aplicado na codificação imprudente pode significar prejuízos e retrabalho. Busque constantemente rever as metas da solução, mantendo o processo iterativo.

Proteja-se em terrenos perigosos

Prepare a aplicação com testes de unidade. Esteja pronto para as ações do usuário mal-intencionado, e para as ações acidentais do usuário bem-intencionado. Trate os dados (máscaras,tipos,criptografias) e responda a erros o quanto antes. Lance exceções e utilize um eficaz validador de formulários em client-side, como o JS Validation Engine.

11. Quando não houver alternativa, arrisque

É utopia imaginar um cronograma onde se tem o tempo necessário para defnir a ferramenta adequada a determinado fim. Quando seu conhecimento prévio ou soluções conhecidas falharem, dê uma chance àquela nova biblioteca/plugin até então desconhecido(a) e crie seu fork. Não se esqueça de enviar suas contribuições de código como agradecimento!

Pude perceber que as lições de estratégia de guerra do livro de Sun Tzu, muito dizem a respeito do nosso cotidiano ao lidar com a solução de problemas, e desde então tenho buscado sintetizar as idéias da obra “A Arte da Guerra” em correlação com a rotina de trabalho enquanto desenvolvedor web. As dicas podem otimizar sua rotina de programação tanto quanto otimizaram a minha!

Quer saber mais sobre como funciona? Fale com um desenvolvedor agora mesmo!
Este artigo foi lido 2396+ vezes. Obrigado por ler até aqui! Fique à vontade pra copiar e compartilhar. Ajude sempre seus colegas. O conhecimento muda vidas!

O conteudo foi útil? Isso é fantástico. Quer incentivar mais posts como esse? Mostre seu apoio com qualquer valor.
Chave PIX: d0311e58-cb6e-4d47-b3d8-3d4254763ce7