Deploy na Sexta #35: Como resolvo problemas em um software?
Dica para atacar problemas de maneira organizada 🖖
Quando eu estava me preparando para entrar no mercado de trabalho, uma grande preocupação que eu tinha era: será que conseguirei resolver os problemas que me contrataram para resolver? Se hoje tu estás nessa situação, primeiramente fica tranquilo. É normal enfrentarmos algumas dificuldades para aprender sobre um produto que já está construído, especialmente nas nossas primeiras experiências profissionais. Os empregadores costumam compreender e esperam que levaremos algum tempo até que sejamos de fato produtivos. Mas falando em estratégias para atacar problemas, hoje te conto como organizo meus pensamentos ao buscar uma solução.
Conheci essa técnica em palestra muitos anos atrás. A técnica dos 5 Porquês foi inventada por Sakichi Toyoda, o fundador da Toyota, na década de 1930. Ela foi desenvolvida como parte do Sistema de Produção Toyota para explorar as causas raízes dos problemas de fabricação e melhorar os processos de produção.
Primeiro fazemos uma pergunta inicial sobre um problema. As respostas geram novas perguntas. Perguntamos até encontrar a causa do problema. O número "cinco" não é uma regra, podemos olhar para os "cinco" porquês como guia para alcançar a profundidade necessária na análise.
Pegando um problema que encontrei essa semana: minha aplicação começou a levar muito tempo para retornar determinados cadastros do cliente. Isso chamou minha atenção, porque estou iniciando e experimentando arquiteturas de backend. Instantaneamente pensei: "Onde foi que eu errei dessa vez?" — Não seria o meu primeiro erro de arquitetura.
Identifique o Problema: Analisando a situação e logs, cheguei ao problema: “Por que aquela API está demorando tanto para retornar as respostas?”.
Perguntei o Primeiro Porquê: “Por que a resposta está demorando tanto?” Nos logs, vi que os tempos de resposta aumentavam drasticamente em certas horas do dia.
Perguntei o Segundo Porquê: “Por que os tempos de resposta aumentam em horários específicos?” Percebi que coincidia com os horários de pico de acesso, o que me levou a suspeitar de problemas de carga.
Perguntei o Terceiro Porquê: “Por que a carga está impactando tanto a performance?” Nem precisei ir ao nível de configuração do servidor, corri para o que domino: backend e lógica de negócio. Os problemas estavam nas consultas ao banco.
Perguntei o Quarto Porquê: “Por que as queries estão impactando a performance?” Bati o olho nas queries, e vi que nem precisaria ir até o nível de detalhamento de índices ou chaves no desenho do banco para ver o problema. As queries não foram pensadas para aquela API. Várias consultas pesadas sendo executadas sem qualquer tipo de filtragem e retornando inúmeras informações irrelevantes, aumentando muito o tempo de resposta.
Perguntei o Quinto Porquê: “Por que as queries não estavam otimizadas?” Lembrei que, durante o desenvolvimento, estava focada em fazer as funcionalidades funcionarem e reaproveitei as queries de relatórios de outros sistemas para minha API.
Implementei Soluções: Refatorei as queries e apenas isso foi suficiente para contornar o problema de carga. Também fiz uma nota mental que talvez eu nunca coloque em prática: "No próximo projeto, pedirei um tempo extra após os testes de viabilidade técnica para refatorar o produto e subir para produção".
Bons desenvolvedores têm frequentemente o "por quê?" na ponta da língua para buscar as razões subjacentes aos problemas e desafios. Este hábito nos ajuda a identificar problemas e promove uma compreensão mais profunda dos sistemas com os quais trabalhamos.
Questionar "por que" algo aconteceu ou "por que" uma solução é necessária nos ajuda a ir além de simples correções superficiais, ou até mesmo implementar correções superficiais que economizam esforços e dinheiro. Inclusive, um físico famoso, Einstein, lançou a pill:
"Se eu tivesse uma hora para resolver um problema e minha vida dependesse da solução, eu gastaria os primeiros 55 minutos determinando a pergunta apropriada a perguntar, pois uma vez que eu conheço a pergunta correta, eu poderia resolver o problema em menos de cinco minutos."
O resumo é: nunca pare que questionar o porquê? Se tu encontrares a pergunta certa, é possível implementar soluções que abordam diretamente a causa raiz de qualquer problema.
Ah, e vale lembrar que ao utilizar a estratégia dos 5 Porquês em equipe não devemos encarar o processo como um exercício para busca de culpados, como "foi a Gi que escreveu, culpa dela!". Pelo contrário, o foco deve ser nos problemas, numa abordagem construtiva: "Gi, por que tu reaproveitou essas queries? Podemos refatorá-las?".
Além disso, problemas complexos podem ter múltiplas causas, por exemplo, meu problema poderia ser resolvido com otimização das queries e também alocação de recursos para aguentar volume de tráfego em horários de pico. É importante reconhecer que uma única linha de questionamento pode não ser suficiente para desvendar todas as camadas do problema.
Essa dica foi útil? Me conta nos comentários se tu tem outras estratégias para investigar problemas.
💡 Indicações da semana
Estou pensando em como estruturar meu podcast de tecnologia, para isso estou consumindo todos os podcasts da #bolhadev. A dica dessa semana é o Coda+Fala, um podcast semanal que aborda tendências, carreira, tecnologia e inovação com o host Rafael Thomazelli e convidados.
📕 Minha lista na Amazon: Atualizei minhas listas de setup, livros e coisinhas que tenho por aqui e comprei na Amazon. A dica aqui é, não compra nada imediatamente. Coloca no carrinho e esperar as super promoções da Amazon, principalmente quando falamos de livros de programação.
📘 15% OFF na Alura: Lembrando que temos link de desconto para estudar na Alura. Por lá tu sai do zero na programação em mais de 1400 cursos em trilhas para diferentes áreas e tecnologias. Tudo em uma só matrícula.
📅 Eventos no Radar
06 e 07/09 CodeConSummit: Um dos maiores encontros dev do sul do mundo, para ti ficar por dentro das tendências mais recentes do mercado de desenvolvimento de software em palestras, painéis, desafios de programação e experiências extras.
04 a 08/09 Campus Party: A maior experiência de ciências, tecnologias e empreendedorismo do mundo em uma jornada repleta de inovação, criatividade e disruptividade no Nordeste.
🤓 Túnel do tempo
Há 33 anos atrás, em agosto de 1991 a World Wide Web foi disponibilizada ao público pela primeira vez. Tim Berners-Lee, um físico britânico, publicou um resumo do projeto na Internet, lançando a web como um serviço público acessível. Para aprender mais sobre a história da www, recomendo o documentário "Lo and Behold, Reveries of the Connected World" que explora a evolução da internet desde suas origens até suas possíveis direções futuras.
Nesta edição, adicionei o tópico túnel do tempo, uma dica super legal de conteúdo enviada por um leitor da newsletter. Sempre que tiveres dicas de conteúdos, fique super a vontade para me enviar.
Nos encontramos no próximo deploy, sexta às 6:00. 🖖
Excelente, Gi. Seu post casou com um artigo que li recentemente, que fala que o valor de um profissional, nos tempos de hoje, não está associado somente na eficiência dele, mas muito mais na eficácia. Ou seja, não adianta sair escrevendo milhares de linha de código sem compreender de fato o problema e entender de qual você pode agregar mais valor pro cliente.
Vou deixar o link do artigo aqui. Nele tem algumas partes do que achei meio “encheção de linguiça” mas em linhas gerais achei bem interessante:
https://ehandbook.com/how-to-get-ahead-of-everybody-else-by-behaving-like-an-executive-acccf69dbb46