Fundamentos: como ler o registo de verificação de uma build

Há três semanas construí um widget de reservas para uma amiga que dirige um estúdio de yoga — uma conversa, um plano que aprovei rapidamente porque estava a meio de outra coisa, uma execução, e depois um cartão de versão com um visto verde que olhei de raspão e segui em frente. Na terça-feira ela mandou-me mensagem a perguntar se podia apontar o site de um segundo estúdio para a mesma construção. Antes de dizer que sim, fui verificar o que "verificado" tinha realmente significado três semanas antes, e foi aí que li um destes registos pela primeira vez em vez de simplesmente confiar no visto.

Fica logo no cartão da versão, junto à pré-visualização e às ações de código — o mesmo sítio onde iria para reimplantar ou reverter. A primeira coisa que notei: está limitado a essa versão específica, não à conversa toda. Tinha iterado nesta construção cinco vezes a tentar resolver um seletor de datas avariado, e esperava, em parte, que o registo contasse a história de toda a troca de mensagens. Não conta. O registo da versão 4 só descreve a versão 4. Não tem memória de que a versão 2 foi lançada com um formulário de login que falhava silenciosamente, nem me vai dizer que a versão 5 corrigiu discretamente algo que a versão 3 tinha estragado. Cada registo é uma fotografia, não uma diferença nem um registo de alterações — se quiser o histórico do que mudou de lançamento para lançamento, isso é uma vista totalmente diferente. Este só responde a "esta versão está bem".

Ao descer, o registo divide-se em seis linhas:

Todas as seis estavam a verde, e o meu instinto inicial foi o mesmo instinto errado que, imagino, a maioria das pessoas tem: a segurança passou, logo é seguro; a acessibilidade passou, logo é acessível. Nenhuma dessas leituras resiste ao que as verificações realmente fazem. A verificação de segurança significa que os problemas de superfície — concatenação de strings numa query, uma chave de API exposta no pacote do cliente, um eval sobre algo escrito por um utilizador — não apareceram. Não é o mesmo que um dia com um pentester. O estúdio da minha amiga não recebe pagamentos através deste widget, apenas nomes e horários, por isso o mínimo era suficiente para ela. Se fosse um fluxo de checkout, eu teria querido mais do que o mínimo.

A acessibilidade foi a que realmente me fez parar e ir pesquisar algo, porque "passou no axe" parece exaustivo e não é. O axe — o motor automático que corre por baixo — capta de forma fiável algo entre um terço e metade dos critérios de sucesso do WCAG: texto alternativo em falta, rácios de contraste maus, campos de formulário sem etiqueta, uso óbvio incorreto de ARIA. Não consegue dizer-lhe se o seletor de datas personalizado que eu tinha pedido é utilizável com um leitor de ecrã, se navegar por tabulação através do fluxo de reserva em várias etapas leva o foco para um sítio sensato, ou se o estado "confirmado" versus "pendente" que eu tinha colorido a verde e amarelo é um problema para alguém com daltonismo vermelho-verde. Isso exige uma pessoa a percorrer a construção com as ferramentas que os utilizadores com deficiência realmente usam. O axe é sinal real, não é nada — é a camada do corretor ortográfico da acessibilidade, não o editor.

A conformidade foi a linha que quase saltei, porque parece burocrática — "contém o que o plano prometia" — até me lembrar que o plano que tinha aprovado foi escrito enquanto eu estava distraída, e sinceramente não conseguia recordar se tinha pedido confirmações por email ou apenas por SMS. É esta camada que verifica a construção contra o plano, não contra a minha intenção real, e passou, o que me disse que a construção correspondia ao que eu tinha aceitado, não necessariamente ao que eu tinha querido dizer. Já ouvi falar de construções funcionalmente sólidas e seguras que, ainda assim, falharam nesta camada porque uma funcionalidade foi discretamente descartada sob pressão de tempo. É a camada que mantém uma construção fiel à conversa que a produziu, mesmo quando a própria conversa foi um pouco descuidada.

Abaixo das seis linhas havia uma lista mais longa, dividida em dois grupos, e foi aí que passei mais tempo. Os itens "a corrigir obrigatoriamente" não são coisas atualmente erradas na construção — são recibos. Uma linha dizia que a camada de revisão tinha assinalado um caso em que uma string de data era interpolada diretamente numa query, e já tinha sido corrigido antes desta versão ser marcada como concluída. Não estava a ver uma ferida aberta; estava a ver uma cicatriz. Essa distinção importa, porque se ler uma entrada de "a corrigir obrigatoriamente" como um aviso ativo, vai gastar tempo a preocupar-se com algo que já está resolvido.

A lista de recomendações era mais longa, e era, na maioria, o tipo de coisa que eu própria diria se estivesse a rever o código de um colega sem querer bloquear o merge: "considere extrair o bloco repetido de renderização de horários para um componente partilhado", "este endpoint não tem limitação de taxa, o que é aceitável para uma ferramenta interna de reservas, mas vale a pena reconsiderar se ficar público." Nada nessa lista era um defeito. Eram decisões de julgamento que um verificador fez apenas com o plano e o código disponíveis, e para um marcador de horários interno de um estúdio de yoga, todas essas decisões caíram do lado razoável. Se o estúdio da minha amiga fosse uma franquia com o widget incorporado em cinquenta páginas de localizações, eu teria querido contestar a questão da limitação de taxa — a classificação depende de contexto que o verificador só pode adivinhar, e quando uma suposição lhe parece errada, o mais correto é dizê-lo no chat, não assumir que a etiqueta é definitiva.

O que me impressionou, ao ver uma lista de recomendações razoavelmente longa ao lado de uma coluna de itens obrigatórios vazia, foi que quase li a extensão dessa lista como má notícia. Não é. Uma construção sem nenhuma nota de recomendação teve uma verificação estreita ou teve sorte; uma construção com uma pilha de itens "considere" e nada pendente na coluna obrigatória é uma que foi realmente examinada com cuidado. A coluna de recomendações é o que deve sobrar depois de os problemas reais terem sido resolvidos.

A outra coisa que me obriguei a fazer, já que este registo tinha três semanas, foi verificar que camadas realmente correram antes de confiar em qualquer veredicto. Todas as seis estavam presentes aqui, mas desde então já vi uma construção em que a acessibilidade estava simplesmente ausente da lista em vez de marcada como aprovada ou reprovada — isso não é o mesmo que ser ignorada por ser considerada pouco importante, é um sinal de que a verificação não correu para aquele tipo de site ou configuração de opções em particular, e ler a ausência como uma aprovação silenciosa é exatamente o erro que este formato convida se estiver só a percorrer por alto.

Nada disto me disse se o fluxo de reservas do estúdio de yoga realmente converte, se as pessoas abandonam na etapa de escolha de horário, ou se a própria ideia de um widget personalizado em vez de simplesmente ligar para o Calendly era a decisão certa em primeiro lugar. A verificação prova que uma construção funciona como prometido, não que a promessa era a certa a fazer — são perguntas separadas, e já vi construções passarem impecavelmente por todas as camadas e, ainda assim, falharem com utilizadores reais porque "funciona corretamente" e "resolve o problema certo" não se sobrepõem tanto quanto seria de esperar. A parte disto que realmente responde à segunda pergunta é o ciclo de medição, e as duas devem ser lidas em conjunto. Um registo de verificação limpo numa funcionalidade que ninguém usa para reservar continua a ser uma funcionalidade que ninguém usa para reservar.