Quem trabalha com desenvolvimento de software, provavelmente em algum momento já recebeu ou deu como resposta a palavra depende!
Parece uma resposta rápida que na prática não resolve nada! Mas o fato desta resposta não resolver nada de imediato, não significa que seu uso seja inadequado.
Na prática é comum que ao usar tal resposta a pessoa esteja realmente interessada em oferecer uma resposta mais adequada e não simplesmente indicar um caminho sem compreender mais detalhes que podem envolver a questão.
A experiência e maturidade traz a capacidade de maior análise e reflexão, a ponto de fazer profissionais entenderem que é mais barato avaliar os detalhes que envolvem uma questão para gerar uma resposta mais próxima de uma resolução real, do que simplesmente dar rapidamente uma resposta concreta que pode não levar a uma resolução real do problema e no prazo imaginado.
Desenvolver um software envolve muitos detalhes, as variações possíveis na composição do negócio/produto, arquiteturas, linguagens, ferramentas, forma de programar, integrar o código e entregar o software em produção geram um número incontável de possibilidades. É por este motivo que para muitas perguntas a resposta inicial mais sensata é depende.
Porém o depende não deve ser a resposta final, ela precisa vir acompanhada do itens a qual a resposta mais adequada de fato depende. Nesse ponto é onde entra o conhecimento e a experiência para saber coletar os detalhes que serão relevantes para aprofundar a resposta.
Vamos a alguns exemplos comuns:
Como resolver o problema de performance da aplicação?
É comum ver respostas como:
- Mude de linguagem.
- Mude a arquitetura.
- Mude para outra Cloud.
- Mude a forma de persistência de dados.
Essas são respostas simplistas, com soluções que podem custar caro e não resolver o problema real. É aí que entra o depende:
- Com relação a linguagem de programação, depende:
- Se os algoritmos implementados usam o potencial máximo da linguagem.
- Se fazem uso adequado dos frameworks utilizados.
- Se usufruem de paralelismo quando a linguagem dá suporte.
- Com relação a arquitetura, depende:
- Há organização de camadas físicas e lógicas e se o código as respeita.
- Se há baixo acoplamento e alta coesão.
- Se não há excesso de requisições entre frontend, backend e fonte de dados.
- Das estratégias utilizadas na integração com soluções de terceiros.
- Com relação ao uso de Cloud:
- Se a configuração do ambiente e estratégia de execução é a mais adequada.
- Como a aplicação carrega dados para memória.
- Como a aplicação gerencia conexões, transações e outras requisições.
- Como os algoritmos trabalham com as iterações de dados.
- Com relação a banco de dados:
- Se é utilizado ORM, como está feito o mapeamento.
- Se há excesso de normalização ou replicação de dados.
- Se as consultas trazem apenas as informações necessárias.
- Se o banco de dados está configurado para o máximo de performance.
O exemplo mostra que para entender o real problema de performance em uma aplicação é necessário avaliar todos esses detalhes, pois o problema pode ser um deles, a junção de vaŕios, ou outro não listado.
Partir para modificações sem a clareza dos pontos relacionados à questão pode simplesmente ser um gasto de tempo com soluções que não resolverão o problema, ou que ainda demandam um tempo maior do que o esperado.
Um segundo exemplo:
Como reduzir os bugs da aplicação?
É comum respostas como:
- Crie testes automatizados.
- Faça revisão de código.
- Homologue a solução antes de ir para produção.
Neste exemplo o depende começa com:
- O que é considerado “bug” na aplicação?
- Somente os erros ou inconformidades da aplicação com relação ao especificado?
- Itens que agora parecem errados, mas que não foram especificados?
- Limitações de usabilidade que não foram avaliadas?
E sobre as respostas comuns, deve-se ponderar:
- Com relação a testes:
- Os testes existentes cobrem todos os casos de uso da aplicação?
- Eles validam o sistema como um todo, ou só partes ou camadas de forma isolada?
- Testes quebrados ou baixa cobertura impedem a atualização em produção?
- Com relação a revisão de código:
- A revisão é criteriosa, ou o time apenas aprova sem fazer considerações?
- As melhorias apontadas são realmente ajustadas antes da aprovação?
- Há orientações adequadas sobre como avaliar e validar as modificações?
- Com relação à homologação:
- É feita manualmente ou de forma automatizada?
- Considera só as modificações realizadas ou toda a aplicação?
- Problemas impedem a atualização em produção?
O exemplo mostra que é necessário antes de tudo compreender o que de fato é registrado como bug, e que alguns itens, mesmo que já aplicados no dia a dia, precisam seguir um conjunto de práticas, pois a simples adoção deles pode não entregar o resultado esperado.
Um último exemplo:
Como faço para aumentar a capacidade de entrega do time?
É comum respostas como:
- Adote processos ágeis.
- Mude para uma linguagem mais simples.
- Contrate mais pessoas.
O depende nessa questão está em:
- O que é considerado uma entrega?
- Como é organizado o roadmap e as tarefas a serem realizadas?
- Como é feito o detalhamento do que precisa ser entregue?
- Qual a experiência do time com a stack utilizada?
- O código existente facilita modificações e/ou novas implementações?
- Mais pessoas no time conseguirão trabalhar bem sem conflitar com as já existentes?
O exemplo mostra que não basta apenas contratar mais pessoas ou atuar em um ou outro ponto para acelerar entregas, é preciso melhorar um conjunto de coisas.
Estes exemplos são comuns no dia a dia em times de desenvolvimento e destacam a quantidade de detalhes que podem derivar de um depende.
Desenvolver software envolve muitas questões que não são visíveis ou compreendidas por todos. O ser humano por natureza busca sempre soluções rápidas e fáceis que possam solucionar seus problemas, e quando buscamos soluções desta forma sem ver ou entender o todo, aumentamos a chance de seguir por caminhos que prometem resolver o problema, mas que no final não trarão o resultado esperado.
Sempre que fazemos isso, gastamos tempo, dinheiro e energia das pessoas sem um retorno real e isso a médio e longo prazo pode determinar o fracasso de projetos, produtos ou até empresas.
Ao receber depende como resposta, lembre que é algo válido se isso vem acompanhado do detalhamento para chegar a uma resposta mais adequada.
Ao dar depende como resposta, lembre de todos os detalhes que podem estar envolvidos, para não dar respostas que ao final não gerem o resultado real esperado.
Por fim, caso você se pergunte: como esse artigo ajuda no desenvolvimento de software? Já sabe a resposta!
A imagem principal foi composta a partir de ilustrações de: Fundo vetor criado por macrovector - br.freepik.com