Bugs de software são uma ocorrência comum no mundo da tecnologia. Se você já escreveu mais de dez linhas de código, é provável que tenha causado uma acidentalmente.  Agora, gostaria que você pensasse sobre a última vez que recebeu uma mensagem de um cliente ou colega surtando com um bug. Como acabou? O bug era tão urgente que você teve que parar o que estava fazendo?  Neste artigo, tentaremos desafiar o pensamento convencional sobre bugs e explorar quanto cada bug está custando para você e sua equipe.  Sobre mim  Olá 👋, meu nome é Krste e sou um desenvolvedor full-stack que trabalha em startups há mais de sete anos. Recentemente, co-fundei   , uma plataforma de monitoramento de bugs que alerta as equipes de software sobre bugs críticos enfrentados pelo usuário. o Bugpilot   Escrevi este artigo com o objetivo de desafiar o pensamento convencional sobre bugs e o “precisamos consertar o mais rápido possível!” mentalidade, questionando a necessidade de explorar o verdadeiro custo de cada questão.  Software 100% livre de bugs. Mito ou Realidade?  O objetivo de alcançar um software 100% livre de bugs sempre foi complicado. A ideia de criar um aplicativo sem bugs pode parecer ideal,  mas é realmente possível?  A verdade é que os bugs de software são inevitáveis devido à complexa lógica de negócios, erros humanos e atualizações contínuas da tecnologia. Mesmo com testes cuidadosos e verificações de qualidade, é difícil eliminá-los completamente.  No entanto, graças a novas ferramentas de desenvolvedor e processos aprimorados, as equipes agora estão lançando novos recursos em um ritmo acelerado para se manterem relevantes e competitivos.  E, com qualquer alteração na base de código, sempre é possível quebrar algo. (Ter que suportar muitos dispositivos e vários navegadores não ajuda em nada.)  Claro, há casos em que os bugs devem ser próximos de zero. Certos setores, como bancário, médico e aeroespacial, devem garantir que os erros sejam reduzidos ao mínimo, pois   . podem custar vidas  Isso explica por que a maioria dos softwares nessas indústrias é escrito em tecnologias de décadas atrás e por que as pessoas agora hesitam em tocá-las.  Mas, no final, temos que nos perguntar:   " Para a maioria de nós, que desenvolve ferramentas de marketing e CRMs, acredito que   Vou tentar explicar por quê. "Vale a pena? consertar bugs costuma ser mais caro do que deixá-los por perto.  Nem todos os erros são iguais  Imagine que você está trabalhando em um site de comércio eletrônico e um bug interrompe o processo de checkout, impossibilitando que os clientes concluam suas compras.  É dolorosamente óbvio que esse bug precisa de atenção imediata, pois afeta diretamente a funcionalidade principal e pode resultar em perda de vendas e clientes insatisfeitos.    . Da mesma forma, não podemos tratar um bug na página de inscrição que está impedindo que novos usuários entrem em nosso novo aplicativo de compartilhamento de viagens da mesma forma que um problema relacionado à atualização da foto do perfil  Esses exemplos em preto e branco mostram que não apenas precisamos detectar, mas   No entanto, na realidade, as coisas não são preto no branco. A maioria das situações se enquadra na área cinzenta.  precisamos entender o impacto dos bugs. A questão então se torna: como sabemos o que consertar?  “TEMOS QUE CORRIGIR AGORA OU O CLIENTE VAI SAIR”  Percebi que tendemos a adicionar um senso de urgência "extra" aos bugs que nossos clientes encontram.  Você provavelmente já passou por uma situação semelhante quando um de seus   clientes está tendo um pequeno problema e toda a sua equipe está sendo inundada com mensagens como se o mundo estivesse pegando fogo 🔥 maiores   ”Giovanni reclamou que não consegue alinhar o texto à direita   1 Eles são um cliente importante. Devemos corrigir o bug AGORA!” 11  - seu chefe  Com base na minha experiência, as funções voltadas para o cliente, como sucesso do cliente, suporte e vendas, tendem a priorizar questões dependendo de como o cliente reage e como isso afeta sua reputação. É por isso que tudo pode parecer grande coisa para eles, o que é compreensível.   Ninguém quer causar uma má impressão ou ter uma reputação negativa, e é exatamente isso que os bugs podem causar.  Quanto mais usuários são afetados por um bug, mais importante (provavelmente) é corrigi-lo  Às vezes, os problemas de produção são tratados à medida que ocorrem. Especialmente nós, desenvolvedores, saltamos imediatamente em qualquer bug ou erro de codificação que chega à sua caixa de entrada.  Você ou sua equipe podem estar usando uma ferramenta como   ou   para monitorar e ser notificado quando ocorrem erros.  Sentry Bugsnag Quando algum erro é encontrado, ele é rapidamente atribuído a um desenvolvedor enquanto todos aguardam impacientemente uma atualização no Slack.  Normalmente, essas ferramentas priorizam erros com base na frequência com que ocorrem e quantos usuários são afetados.  Human.priorizarBugs()  No entanto, a prioridade da maioria dos bugs na maioria das equipes provavelmente é determinada pelo proprietário do produto ou pelo desenvolvedor líder.  Essas funções geralmente compreendem a lógica de negócios, a tecnologia subjacente, a carga de trabalho atual e as prioridades futuras e planejam de acordo.  Seus   podem ser mais ou menos assim: critérios de priorização    Primeira pergunta, mas já está ficando um pouco complicado. O que é   Crítico não tem uma definição clara. Se uma função principal estiver inutilizável, é bastante óbvio que devemos corrigi-la.  É crítico ou não? crítico? No entanto, como você viu no exemplo acima, e se um cliente importante for afetado?    Apenas um? Todos? Será que sabemos? Quando um número significativo de usuários é afetado, convém resolver o problema, mesmo que esteja relacionado a uma funcionalidade menor. Quantos clientes está impactando?    Em seguida, o proprietário do processo   perguntará quanto tempo leva para corrigir o problema. Mesmo que leve apenas algumas horas, eles encontrarão maneiras de espremer isso no trabalho desta semana.  Quanto tempo leva para corrigi-lo? de “Bug Triage”  “Consertar (o mais rápido possível) ou não consertar, eis a questão.”  Os desenvolvedores geralmente enfrentam um dilema ao lidar com um bug "urgente". Eles podem correr para terminar sua tarefa atual e corrigir o bug, possivelmente introduzindo novos bugs no processo; eles freqüentemente ignoram   , pois podem mudar abruptamente sua atenção para o bug, abandonando completamente sua tarefa atual. a sobrecarga de troca de contexto  Há três problemas significativos com esses cenários:  A equipe prioriza incorretamente, possivelmente resultando em perda de tempo e correção de bugs menos relevantes.  Adicionar urgência desnecessária a bugs não críticos faz com que a equipe mude o foco desnecessariamente.  Antes de abordar um bug, é importante considerar seu   . Então, quanto um bug realmente custa à equipe? Consertá-lo é um custo razoável? custo  Quão caro é corrigir um bug?  Você já ouviu falar da frase  "Não existe almoço grátis?"  Quando falamos de custo, a primeira coisa que pensamos como desenvolvedores é o custo de infraestrutura, o custo de um servidor, uma Função Lambda, um Cluster MongoDB e assim por diante.  No entanto, quando se trata de bugs, estou falando de um custo humano:   . atenção  Mudança de Contexto  Se você estudou engenharia da computação ou já leu sobre como os sistemas operacionais funcionam, provavelmente já ouviu falar em troca de contexto.  Na computação, uma   é o processo de armazenar o estado de um processo ou thread, para que possa ser restaurado e retomar a execução posteriormente e, em seguida, restaurar um estado diferente, salvo anteriormente. troca de contexto  (da  [Wikipedia](https://Context switch https://en.wikipedia.org › wiki › Context_switch))  Um caso de alternância de contexto do sistema operacional pode ser multitarefa:  a alternância de contexto é uma característica da multitarefa que permite que o processo seja alternado da CPU para que outro processo possa ser executado.  Onde já ouvi essas palavras antes 🤔? - Ah sim:  “Eu sou um mestre em multitarefa.”  A multitarefa pode ocorrer quando alguém tenta executar duas tarefas simultaneamente, alternar de uma tarefa para outra ou executar duas ou mais tarefas em rápida sucessão.  Lavar a roupa enquanto conversa com um amigo provavelmente funcionará bem. A parte complicada surge quando estamos realizando tarefas mentalmente complexas,  como escrever código.    para determinar seus custos. Eles mediram o tempo que as pessoas levam para concluir as tarefas e o custo do tempo para alternar entre elas. Os resultados foram os seguintes: Os psicólogos conduziram vários experimentos sobre troca de tarefas   “ Embora os custos de troca possam ser relativamente pequenos, às vezes apenas alguns décimos de segundo por troca, eles podem aumentar muito quando as pessoas alternam repetidamente entre as tarefas. …  alternar entre tarefas pode custar até 40% do tempo produtivo de alguém.”  "Você tem um minuto?"  Imagine o seguinte: você está preso, totalmente imerso e nada pode impedi-lo de terminar este novo e brilhante recurso. O mundo exterior nem existe - é só você e seu código. Mas então, você ouve um toque do nada... uma nova notificação em seu telefone.  É o seu amigo convidando você para beber neste fim de semana. E assim,   , os próximos 20 minutos da sua vida se foram. puf  Ou talvez você tenha acabado de receber uma mensagem do Slack de seu colega perguntando se você tem um minuto para ajudar com um problema específico.   A segunda situação é mais aceitável do que a primeira?  Bem, no final,     gravadas de 86 programadores usando Eclipse e Visual Studio e uma pesquisa com 414 programadores (   ) descobriu: não importa. Com base em uma análise de 10.000 sessões de programação Parnin:10  Um programador leva de 10 a 15 minutos para escrever mais código depois de retomar o trabalho após uma interrupção.  Quando interrompido durante a edição de um método, apenas 10% das vezes o programador retomava o trabalho em menos de um minuto.   É provável que um programador tenha apenas uma sessão ininterrupta de 2 horas por dia.   Os desenvolvedores tendem a evitar (   ) a troca de contexto quando se trata de reuniões inúteis. Ainda assim, acredito que podemos estar de alguma forma cegos quando alternamos o contexto entre as “tarefas do desenvolvedor” e ignoramos completamente seu efeito negativo. e odiar  Pensamentos finais  No mundo real, estamos sempre lidando com recursos limitados, seja dinheiro, tempo ou   . atenção   Corrigir erros tem um preço.  “Não” é não para uma coisa.    “Sim” é não para muitas coisas. -Jason Fried    A multitarefa pode parecer eficiente na superfície, mas alternar entre tarefas leva mais tempo e apresenta mais bugs no final. Dizer “sim” para corrigir um bug significa dizer “não” para um recurso.    ajuda você a fazer escolhas melhores sobre quais bugs valem a pena abandonar tudo e quais não valem (a maioria não vale). Compreender os custos ocultos da troca de contexto  Devemos parar de nos importar com insetos?  Bem não.   Pode ser desafiador sentar-se calmamente e aceitar bugs. Todos nós temos um desejo interior de produzir um trabalho de alta qualidade e construir algo do qual possamos nos orgulhar. No entanto, devemos pelo menos estar cientes do custo de corrigir bugs e nos perguntar:  "Vale a pena consertar?"  Infelizmente, esses bugs irritantes geralmente atrapalham.   Como Tom De Marco escreve em seu livro   , isso pode explicar por que é difícil parar de se preocupar com a qualidade: "Peopleware"  Todos nós tendemos a vincular fortemente nossa auto-estima à qualidade do produto que produzimos - não à quantidade do produto, mas à qualidade. (Por alguma razão, há pouca satisfação em produzir grandes quantidades de coisas medíocres, embora isso possa ser exatamente o que é necessário para uma determinada situação.)  – Pessoas  Devemos nos esforçar mais na prevenção de bugs?  Como mencionei anteriormente, você não tem escolha em muitos setores. Lá, você deve tomar todas as medidas necessárias para evitar que erros ocorram e corrigi-los o mais rápido possível.   Mas, para a maioria dos aplicativos,  o esforço extra vale a pena?  PS No final das contas, mesmo se tivéssemos uma varinha mágica que consertasse todos os bugs, nossos usuários ainda encontrariam uma maneira de fazer mau uso de nosso aplicativo 😅 

Find hidden bugs

Book a Call

Bugpilot

Este áudio é produzido no idioma original da história!

Os insetos estão matando seu impulso?

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Uma breve introdução à teoria do cérebro de Boltzmann

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Uma breve introdução à teoria do cérebro de Boltzmann

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps