Erro número um: escrever uma especificação em vez de uma frase
As pessoas que já foram prejudicadas por software mau tendem a abrir o construtor e a escrever um parágrafo inteiro. Sistema de classificação, preferências de unidades, modo offline, esquema de cores, tudo isso antecipado antes mesmo de chegar a primeira resposta. Parece responsável. Não é. O construtor lê a sua frase única, infere o que provavelmente pretende, e devolve um plano em cerca de quinze segundos — "um registo de treino para escaladores" transforma-se numa vista de registo de sessões, numa vista de acompanhamento de graus e num painel, com o sistema V de boulder e as vias YDS escolhidos como predefinição, porque é isso que a maioria dos escaladores realmente usa. Diz-lhe o que escolheu, mesmo ali no plano, para que possa corrigir numa única linha se for a exceção. Escrever o parágrafo antecipadamente não elimina esse passo. Continua a receber um plano, continua a ter de o ler, e agora gastou três minutos a escrever restrições que o plano lhe teria apresentado de qualquer forma, pela ordem que realmente importa para a sua construção.
O plano não é um formulário com espaços para preencher. É prosa, e a sua resposta também é em prosa. "Na verdade, usa os graus Font, estou na Europa" é uma edição completa. Tal como "adiciona um campo de parceiro/registo de segurança, escalo com pessoas diferentes." Cada edição regenera o plano, não a construção — está a orientar antes de a parte dispendiosa começar, não a reiniciá-la. Aprovar esse plano é a última decisão que é obrigado a tomar. Tudo o resto é geração e verificação.
Erro dois: ficar a observar o feed como se fosse um terminal encravado
A construção corre do lado do servidor, e o cenário de catástrofe aqui é quase sempre um falso alarme: alguém fica a olhar para um feed de atividade silencioso durante dois minutos e presume que está encravado. Não está — está numa fase que não produz resultados visíveis a cada segundo, e o feed indica em que fase se encontra exatamente por esta razão. Pode fechar completamente o separador. A execução não vive no seu navegador.
O que deve realmente esperar varia bastante consoante o tipo de projeto. O registo de escalada — algumas páginas, um modelo de dados local, sem chamadas a uma API externa — fica pronto em menos de três minutos, o que é típico para qualquer coisa que seja basicamente "regista isto, mostra aquilo num gráfico, apresenta-me uma lista." No momento em que uma construção precisa de um backend real, autenticação, uma base de dados com relações, tarefas em segundo plano, está a olhar para oito a doze minutos, porque agora há geração e migração de esquemas, e a verificação corre uma segunda vez sobre código de servidor em vez de apenas marcação. Os jogos são ainda mais lentos, porque precisam de geração de recursos: sprites, efeitos sonoros, por vezes uma segunda passagem visual se a primeira tentativa não resultar bem no tamanho em que deve ser apresentada. E o empacotamento nativo, um APK realmente instalável, não uma vista web envolvida numa shell, passa a responsabilidade para uma cadeia de ferramentas real. Gradle, assinatura, tudo isso. Só esse passo pode acrescentar cinco a dez minutos a tudo o resto, e é a única fase em que um feed silencioso significa que a cadeia de ferramentas está a fazer o seu trabalho, não que algo correu mal.
O custo real deste modelo é que se perde o feedback instantâneo, carácter a carácter, de ver o código a ser gerado num editor. Em troca, obtém-se um sistema que sobrevive a um portátil que adormece e a um wifi que cai, que se pode consultar a partir do telemóvel, que continua a funcionar quer se esteja ou não a observá-lo. Para um build de noventa segundos, essa troca praticamente não se nota. Para o build de backend de doze minutos, faz a diferença entre vigiar um terminal e ir buscar um café.
Erro três: confundir gerado com concluído
Este é o erro caro. Um build que termina rapidamente e não foi verificado não é um build terminado, é um rascunho que por acaso funciona — e é nesse intervalo que a maioria dos criadores rápidos de sites ganha má reputação, lançando formulários sem sanitização e botões inacessíveis por teclado. Antes de esta plataforma considerar algo concluído, agentes verificadores independentes analisam-no: código, segurança, links, SEO, acessibilidade e conformidade com o plano que aprovou. Trata-se de uma verificação genuinamente separada, não do mesmo agente a reler o seu próprio resultado e a acenar com aprovação.
A verificação de segurança procura os erros banais que realmente prejudicam em produção: uma chave de API incluída no código do lado do cliente, um formulário que aceita entradas sem sanitização, um endpoint que confia num ID de utilizador fornecido pelo cliente em vez de o obter da sessão. A verificação de acessibilidade não é um linter que se silencia com um comentário — verifica rácios de contraste reais e se os elementos interativos são acessíveis por teclado.
A conformidade é a que mais se subestima. É fácil que uma passagem de geração deixe cair silenciosamente algo que pediu — aquele campo de parceiro/registo de segurança da sua edição do plano, por exemplo — três ficheiros dentro do build, despriorizado sem que ninguém tenha decidido eliminá-lo. A conformidade relê o plano aprovado em comparação com o resultado real e deteta a lacuna. Quando encontra uma, a correção é aplicada e reverificada automaticamente; não recebe uma lista de tarefas, recebe uma correção que nunca chega a ver ou simplesmente nada de errado à partida. Os detalhes do que cada verificador analisa, e o que acontece quando algo falha duas vezes seguidas, estão em Como os builds se verificam a si próprios. A ideia principal a reter desta secção: concluído significa aprovado, não gerado. Trate-os como a mesma afirmação e acabará por lançar a chave exposta ou o botão inacessível.
O que obtém se evitar os três erros
- Um produto funcional numa pré-visualização real onde pode clicar — uma instância a funcionar de facto com os seus dados integrados, não uma captura de ecrã do aspeto final.
- Uma conversa associada, onde "escurece o cabeçalho e adiciona uma página de estatísticas" gera a versão dois ao lado da versão um. A versão antiga não desaparece; fica lá como alternativa enquanto a nova assume a pré-visualização ativa.
- Botões que fazem coisas: publicar em direto, descarregar o código, criar instaladores nativos, enviar para uma loja. Não janelas de venda adicional disfarçadas de botões.
Esse botão de descarregar o código merece um segundo olhar, porque é o que distingue uma ferramenta em quem confiaria para algo real de uma que só usaria em protótipos descartáveis. Se o código é genuinamente seu para levar, com uma estrutura de ficheiros legível e sem aprisionamento exótico além do que efetivamente pediu, então a plataforma tem de continuar a merecer a sua próxima sessão em vez de descansar no facto de já estar preso a ela.
