A versão curta
Software defensivo é o software que continua compreensível quando o ambiente ao redor dele se comporta mal, e não apenas o software que valida suas entradas. O Comoji, meu app de preenchimento automático de emojis para Mac, pareceu quebrar depois de uma reinicialização quando o Secure Input do macOS ficou travado no estado ativo, segurado primeiro pelo Chrome e depois pelo processo de login da Apple. O Comoji estava se comportando corretamente ao se afastar enquanto a entrada do teclado estava protegida, mas nada dizia isso ao usuário, então uma pausa deliberada parecia idêntica a uma falha. A causa raiz estava fora do meu código, e ainda assim a confusão era minha. A correção foi pequena e não enfraqueceu a proteção: um selo de cadeado no ícone da barra de menus sempre que o Secure Input está ativo, e um artigo de ajuda a um clique explicando o que esse estado significa e como eliminá-lo. Estar tecnicamente correto não consola quando seu produto parece quebrado. Às vezes o comportamento certo é parar, e um bom software deveria dizer por quê.
Recentemente meu laptop ficou sem bateria e desligou. Depois que o conectei à tomada e reiniciei, o Comoji parou de funcionar. Eu digitava um atalho de emoji e nada acontecia. Nenhuma explicação, nenhum sinal de que algo tivesse mudado. Só um app que funcionava antes do desligamento e que, aparentemente, não funcionava mais.
Comoji é meu pequeno app para Mac que oferece preenchimento automático de emojis nos campos de texto que você já usa. O trabalho dele é simples: reconhecer um atalho, oferecer os emojis correspondentes e sair do caminho. Quando isso para de acontecer, não sobra muito produto com que interagir.
Só que o Comoji não tinha quebrado de verdade. Ele estava respeitando uma fronteira de segurança atrás da qual outra coisa no meu computador tinha ficado presa.
Por que fazer a coisa certa pode parecer não fazer nada?
O macOS tem um recurso chamado Secure Input (entrada segura) que protege a digitação sensível do teclado contra interceptação por outros processos. Isso é importante para um app como o Comoji, que precisa reconhecer o que você digita para oferecer o preenchimento automático. Um utilitário de emojis não tem nada que ficar observando você digitar uma senha, então o Comoji se afasta deliberadamente enquanto o Secure Input está ativo.
Nesse caso, o Chrome aparecia como o processo que segurava o Secure Input, mesmo que eu já não estivesse digitando nenhuma senha. Matei o Chrome esperando que isso resolvesse. Em vez disso, o Secure Input continuou ativo, e agora estava associado ao processo de login da Apple. O que quer que tivesse dado errado depois da reinicialização, fechar o navegador não tinha sido suficiente para resolver.
Essa é uma classe de problema que a própria Apple documentou. Um aplicativo que deixa o Secure Input ativado quando não precisa mais dele pode interferir em outros aplicativos que dependem de eventos de teclado, mesmo depois que o aplicativo culpado vai para segundo plano. O mecanismo de segurança continua fazendo seu trabalho, mas o software no resto da máquina sofre as consequências.
Era essa a situação em que o Comoji estava. Ele se recusava corretamente a operar enquanto o sistema dizia que a entrada do teclado precisava de proteção. Mas nada disso era visível para mim. Eu tinha escrito o app, e mesmo eu, no início, só vi que ele tinha parado de funcionar.
Um usuário não deveria precisar investigar o estado do sistema operacional para entender por que seus atalhos de emoji de repente não fazem nada.
Por que “o bug não é meu” não é uma resposta completa?
É compreensível a tentação de parar de investigar assim que você estabelece que um problema se origina fora do seu código. O Chrome segurava o Secure Input. Depois o processo de login da Apple estava envolvido. O Comoji se comportava exatamente como planejado. Caso encerrado, certo?
Não exatamente. Isso explica quem causou o problema, mas não ajuda a pessoa que está tentando usar meu app. Ela não está olhando para a posse de processos nem decidindo qual empresa merece um relatório de bug. Ela está olhando para o Comoji e se perguntando por que ele não funciona.
O problema de entrada subjacente estava fora do Comoji. A falta de uma explicação era algo que eu podia corrigir.
É aqui que o desenvolvimento de software defensivo vai além de checar argumentos inválidos e capturar exceções. Você também precisa pensar em como seu aplicativo aparece quando o ambiente ao redor dele para de se comportar corretamente. O usuário consegue distinguir uma pausa deliberada de uma falha? Ele sabe o que está impedindo o app de funcionar? Você deu a ele algum lugar útil para onde ir em seguida?
Estar tecnicamente correto é pouco consolo quando seu produto parece quebrado.
O que eu mudei? Um pequeno cadeado em vez de um mistério
Adicionei um pequeno indicador de cadeado ao ícone do Comoji na barra de menus sempre que o Secure Input está ativo. Agora existe um motivo visível para a ausência do preenchimento automático: o Comoji está pausado porque a entrada do teclado está protegida. O app não apresenta mais em silêncio um recurso indisponível como se ele devesse estar funcionando.
Também vinculei o menu da bandeja a um artigo de ajuda que explica o que é o Secure Input e por que o Comoji o respeita. Quem ficar preso pode chegar a essa explicação a partir do próprio app, em vez de ter que adivinhar os termos de busca certos ou me contatar para descobrir que esse recurso do sistema existe.
O importante é o que eu não tentei resolver. A resposta não era contornar a proteção de senhas só para o preenchimento automático de emojis funcionar. O Secure Input estar ativo não é, por si só, um erro. Ele existe por um bom motivo, e a Apple avisa explicitamente que ativar a entrada segura pelo teclado pode afetar outros apps que precisam dessas teclas.
O cadeado, portanto, comunica um estado, não uma crise. Durante a digitação normal de uma senha, ele explica por que o Comoji está temporariamente indisponível. Quando esse estado persiste de forma inesperada, ele dá ao usuário um ponto de partida para entender o que aconteceu.
Não tornei o Chrome ou o macOS incapazes de travar. Tornei o travamento deles menos confuso para quem usa o Comoji, sem enfraquecer a proteção que o Comoji deveria respeitar.
Por que grandes empresas continuam sendo dependências externas?
Há algo irritante em blindar um utilitário minúsculo contra problemas que envolvem o navegador do Google e o sistema operacional da Apple. Esses não são componentes obscuros que arrastei para o projeto sem pensar. São produtos de duas empresas de tecnologia enormes, e ainda assim o comportamento delas conseguiu fazer meu pequeno app parecer defeituoso.
Mas o tamanho delas não muda a decisão de engenharia. Não posso construir o Comoji partindo do pressuposto de que tudo o que é produzido por uma empresa maior que a minha sempre vai se comportar corretamente. Também não posso dizer a um usuário frustrado que o problema pertence a uma empresa suficientemente impressionante e considerar meu trabalho encerrado.
Não sei com que frequência essa sequência específica acontece. Pode ser incomum. Mas eu a vivenciei, e o resultado expôs uma distinção útil: o Comoji já lidava com a condição de segurança de forma segura; ainda não lidava bem com a confusão resultante.
Isso não significa que toda falha hipotética mereça uma nova configuração, uma caixa de aviso ou um subsistema de recuperação. Neste caso, a resposta foi pequena e diretamente relacionada ao problema. Um ícone de cadeado tornou a condição visível. Um artigo de ajuda a tornou compreensível. Nenhum dos dois exigiu fingir que eu podia consertar outro aplicativo de dentro do meu.
Para mim, essa é uma parte importante de construir software defensivo. Sua responsabilidade não termina em garantir que seu código funcione quando tudo ao redor dele funciona. Você também precisa decidir o que acontece quando ele não consegue fazer seu trabalho, inclusive quando o motivo é o erro de outra pessoa.
Às vezes, o comportamento certo é parar. Um bom software deveria ser capaz de dizer por quê.