A depuração talvez seja a habilidade que eu acho que os programadores têm mais dificuldade em exercitar. É também a mais difícil de ensinar. Depuração, para mim, é tanto uma disciplina científica quanto uma arte. Ela muitas vezes exige que você vá além do pensamento analítico e confie em sua própria intuição para resolver um problema.
Muitos desenvolvedores usam abordagens empíricas, abordando sistematicamente cada problema possível de branch. Se A, então B. Se B, então C. Se C, então D. Essa abordagem analítica funciona bem e é fácil de ensinar. Entretanto, o problema que eu encontrei é que muitos focam na identificação de soluções antes de fazer um grokking total no problema. Isso leva a abordagens que começam com D e abrem caminho de volta a A, resultando em tempo perdido.
Essa não é geralmente a forma como eu abordo depuração. Para mim, uma abordagem baseada em intuição é fundamental. Mas a intuição é uma coisa complicada, não é? Afinal, ter um pressentimento sobre algo parece místico e um pouco paranormal. No entanto, eu acho que não é. O Wiktionary define intuição como “cognição imediata, sem a utilização de processos racionais conscientes”. Veja como eu acho que funciona. Seu cérebro está constantemente fazendo cálculos, bem como um mentat de Frank Herbert. Ele tem os dados necessários, faz o cálculo mais rápido do que você pode piscar os olhos, tira conclusões, e te dá a resposta de forma rápida e instintivamente. Isso é cognição imediata, e você não estava consciente de qualquer processo racional sendo usado.
Esse cálculo constante é algo que todo mundo faz, mas na civilização ocidental nós o suprimimos em favor de uma abordagem racional. Podemos aprender a desenvolvê-lo, ouvi-lo, e, juntamente com o pensamento analítico, torná-lo uma parte de nossos processos de pensamento padrão. Aqui estão algumas maneiras de tornar a intuição uma parte de seus hábitos de depuração.
Desacelere
Como desenvolvedores, quando nos deparamos com problemas que exigem depuração intensa, muitas vezes estamos com pressa, especialmente se for algo que afeta um ambiente de produção. Essa mentalidade apressada cria as piores condições possíveis, o que lhe permite focar efetivamente no problema e encontrar uma solução. Quando está apressado, você não pensa com clareza sobre onde começar, muito menos sobre como resolver o problema. Para pensar claramente, você deve desacelerar.
Quando você se vê correndo para corrigir um erro, é melhor parar o que está fazendo, fechar os olhos, respirar fundo e deixar o ar sair lentamente. Eu sei que soa piegas, mas isso não é meditação transcendental. É perspectiva. É foco. Quando você toma o tempo para desacelerar e focar, você pode tocar em sua intuição, utilizando-a para descobrir por onde começar e como resolver o problema.
Em sua biografia de Steve Jobs, Walter Isaacson cita Jobs dizendo isso sobre intuição e desacelerar sua mente:
Se você simplesmente sentar e observar, você verá como a sua mente é inquieta. Se você tentar acalmá-la, isso só piora a situação, mas com o tempo ela realmente se acalma, e quando o faz, há espaço para ouvir coisas mais sutis – que é quando a sua intuição começa a florescer e você começa a ver as coisas mais claramente e a estar mais no presente. Sua mente apenas desacelera, e você vê uma expansão tremenda no momento. Você vê muito mais do que você poderia antes. É uma disciplina, você tem que praticá-la.
Pare de dizer “eu não sei”
Como desenvolvedores, nós gostaríamos de focar em limitações. A construção de software é toda sobre encontrar as limitações de um domínio de problema e programar uma solução para atender a essas limitações. Não é de admirar que as nossas vidas e os nossos trabalhos giram em torno de limitações, e nós gostamos assim. Mas as limitações podem nos deter e esmagar a nossa intuição. Quando assumimos que não sabemos a resposta para um problema, nós impomos uma limitações sobre nós mesmos, o que torna mais difícil para que encontremos a resposta.
Em seu livro, Grow Your Intuition: 6 Simple Steps, Suzan Bond diz que desligamos a nossa intuição quando respondemos a perguntas com “Eu não sei”. Ela prossegue dizendo: “Quando você parar de usar muito essa frase, você vai abrir a sua intuição. Você vai ser capaz de ver mais possibilidades, ao invés de limitações”.
Não é errado admitir a falta de conhecimento em uma área, e eu não estou defendendo o fato de que você deva inventar respostas, mas a verdade é que você já pode saber a solução. Seu cérebro já tem os dados de que necessita. Vá mais devagar. Tome fôlego. Reflita sobre isso. Deixe a sua intuição falar com você. Se você tem dificuldade em encontrar uma solução, pergunte-se o que pode estar bloqueando-o de vê-la. Não aceite que você não sabe a resposta, e sim que deve descobri-la.
O problema está no seu código
Aqui está uma noção humilde, mas crucial. Nunca é divertido aceitar a culpa por alguma coisa, então é mais fácil apontar o dedo para alguém ou alguma coisa. Vamos encarar os fatos, os desenvolvedores são pessoas orgulhosas e mestres de hipérbole. Aprendi, porém, que o problema é encontrado mais frequentemente no seu próprio código, por isso é melhor começar com essa suposição.
Bem no começo da minha carreira, eu trabalhei com um desenvolvedor – vamos chamá-lo de John – que sempre culpava o código de outra pessoa quando ele encontrava um bug. Ele adorava fazer isso, tanto que ele pulava de sua mesa, rindo e correndo para o meu escritório para se vangloriar por encontrar um bug em alguma biblioteca de terceiros ou até mesmo na linguagem de programação que estávamos usando. John adorava poder dizer que a linguagem estava com um problema e que ele era responsável por encontrá-lo. Em mais de uma ocasião, ele tinha o formulário do relatório de bug da linguagem de programação aberto e preenchido antes mesmo de eu ser capaz de pegá-lo e forçá-lo a reexaminar a questão com cuidado olhando para o seu próprio código. Toda vez, a falha estava em seu código.
Quando começar com a suposição de que é o código de outra pessoa que tem o problema, você vai prejudicar a si mesmo de várias maneiras. Antes de qualquer coisa, você está impedindo a sua própria capacidade de encontrar o real problema, porque você começa olhando no lugar errado. Isso te custa tempo. Em segundo lugar, você está se preparando para parecer um idiota quando vier à tona que o seu código é que foi a causa de todo o problema e você perdeu tempo, energia e recursos tentando culpar outra coisa. Por fim, você suja a sua reputação como um solucionador de problemas por passar a responsabilidade para outros.
Quando você começar com a suposição de que o problema está no seu código, mostre então humildade e liderança ao aceitar a responsabilidade de resolver o problema. Se, de repente, acontecer de descobrir que o problema estava, de fato, no código de outra pessoa, então você incitou em outros uma grande dose de confiança em sua capacidade de buscar ativamente soluções para os problemas.
Foco no problema, não uma solução
Quando se concentrar em identificar uma solução antes de grokking (?) completamente o problema, você coloca os carros na frente dos bois. Comece pelo começo. Comece com o problema. Acho que isso é difícil para muitos desenvolvedores, porque nós gostamos de tirar conclusões precipitadas. Vejo ambos A e B, por isso deve ser C, portanto D! Encontrar e implementar soluções é emocionante e gratificante para nós. Encontrar problemas? Não muito.
Tenha em mente que os sintomas podem não indicar o problema real. Nós sabemos o que são, então nós corrigimos o problema por meio de testes para tratarmos os sintomas. Uma vez que os sintomas não aparecem mais, o problema está resolvido, certo? Não, agora você enterrou o problema mais profundo, e vai ser mais difícil de encontrar da próxima vez.
Uma história específica da minha carreira vem à mente, na qual vários registros idênticos foram adicionados a uma tabela de banco de dados para uma ação específica que deveria ter acrescentado apenas um registro de cada vez. Isso resultou em clientes gerando relatórios que continham vários registros idênticos. Esse foi o sintoma. Em um esforço para acalmar o cliente, uma solução foi concebida para combinar os registros no ponto em que o relatório foi gerado. Isso fez o cliente feliz, mas não resolveu o problema. Na verdade, agora que o problema foi enterrado, ficou mais difícil de ver, e o banco de dados continuou a se encher de registros falsos.
Sempre chegue ao coração do problema. Não basta olhar para os sintomas superficiais e assumir que eles são o que você precisa resolver. Focar na solução não vai fazer você chegar nela. Você precisa se concentrar no problema. Eu acho que quando eu entender o problema – uma vez que eu completamente grok (?) ele – a minha intuição entrará em ação com uma solução acessível.
Em seu livro, O universo em um átomo, o Dalai Lama escreve:
A diferença entre a ciência que temos hoje e a tradição budista investigativa reside reside na dominância da terceira pessoa, métodos objetivos e no refinamento e na utilização da primeira pessoa, métodos introspectivos na contemplação budista. Em minha opinião, a combinação do método em primeira pessoa com o método de terceira pessoa oferece a promessa de um avanço real no estudo científico da consciência.
Enquanto o Dalai Lama se refere ao estudo da consciência nessa declaração, o argumento central de seu livro é que o método científico empírico pode se beneficiar da intuição experimental em primeira mão e deve se beneficiar dele, se estivermos fazendo avanços éticos nas ciências e na compreensão de nosso universo. Eu concordo, e acredito que a intuição pode beneficiar inclusive a ciência da computação e a engenharia de software.
Eu não posso fingir para entender todos os mistérios da mente, nem me propor a te ensinar tudo sobre a intuição. Estou aprendendo essas coisas sozinho. No entanto, eu sei que a intuição é algo que todos podem aproveitar. Conto com ela diariamente. Eu notei como ela salvou o dia em inúmeras sessões de depuração ao longo da minha carreira, e quando eu soube do papel que ela desempenha o tempo todo, senti que era hora de aceitar e compartilhar minhas experiências usando-a.
Então, seja um melhor solucionador de problemas e depurador recorrendo à sua intuição. Aprenda a desacelerar. Tenha certeza de que você já sabe a resposta. Mostre humildade ao assumir primeiro que o problema está dentro de seu próprio código. Concentre-se na identificação do problema e, uma vez identificado, a solução virá para você. Combine o uso da intuição com processos analíticos padrões.
Você se tornará um desenvolvedor melhor!
***
Texto original disponível em http://webadvent.org/2012/debugging-zen-by-ben-ramsey








