Maya Consultoria · qaFactory

Linha de código não é métrica.Regra de negócio é.

A Maya conecta ao seu repositório, lê o código como ele está e devolve um laudo com as regras de negócio que existem ali dentro — quantas são, quais estão duplicadas, quais divergem entre si e quais não têm nenhum teste cobrindo.

Você não precisa ter documentação. Se não tiver, a documentação do que o sistema faz é o primeiro subproduto da análise.

10.000 linhas em até 24h úteis acesso somente-leitura sem cartão
Exemplo ilustrativo · dados fictícios
diagnostico-gratuito · 10.000 linhas 20 achados
Achado 01/20 Regra duplicada

Cálculo de imposto retido implementado em dois pontos, com arredondamentos diferentes

src/faturamento/CalculoImposto.java:214
src/legado/TributoHelper.java:88

As duas implementações usam modos de arredondamento distintos (HALF_UP e HALF_DOWN). Acima de R$ 10.000 elas divergem em centavos, e a rota executada depende de qual serviço processa o pedido primeiro.

Impacto divergência de valor em nota fiscal Esforço ~4h
02regra sem teste
03regra duplicada
04regra hardcoded
05acoplamento de domínio
06regra sem teste
07divergência de contrato
08regra órfã
+ 12 achados

Os outros 19 achados saem na conversa com o consultor.

Quero o meu
O problema

Ninguém sabe quantas regras existem no sistema — nem quem escreveu

Todo sistema com alguns anos chega no mesmo lugar. A regra de negócio foi implementada, depois foi copiada para outro fluxo, depois alguém corrigiu só uma das cópias. A documentação parou de ser atualizada no segundo mês. Quem escreveu saiu da empresa. E a única fonte de verdade sobre o que o sistema faz virou o próprio código — que ninguém tem tempo de ler inteiro.

Analisador estático não resolve isso. Ele mede estilo, complexidade e cobertura — coisas do arquivo. Ele não sabe que a regra de desconto do arquivo A e a do arquivo B são a mesma regra escrita duas vezes, com resultados diferentes. Esse é o tipo de problema que só aparece quando alguém lê o sistema procurando por regra, não por linha.

O que muda

Um sistema com 20 mil linhas pode ter a mesma regra escrita três vezes

E outro programador entregaria tudo em 5 mil. É isso que o laudo mede — e é por isso que contar linha não diz nada sobre a saúde do seu software.

Exemplo ilustrativo do laudo completo · dados fictícios
47 regras de negócio em 82.400 linhas
9regras implementadas em mais de um ponto
12regras sem nenhum teste que as cubra
3pontos onde a mesma regra diverge
~58%redução de código estimada, sem perda de função

A estimativa de redução sai sempre como faixa, com o critério de cálculo declarado no próprio laudo. Não é um número de efeito — é um número que você vai ter que defender numa reunião, e nós também.

Como funciona

Quatro passos, sem instalar nada no seu ambiente

01

Cadastro mínimo

Nome, e-mail e qual é a sua stack. Nada além disso — não temos formulário de qualificação de dez campos.

02

Você dá acesso

Conecta o repositório em modo leitura, ou envia um arquivo. As duas opções estão explicadas abaixo, com as implicações de cada uma.

03

Lemos o sistema

Nossos agentes reconstroem o que o sistema faz, mapeiam as regras de negócio e marcam duplicidade, divergência e ausência de teste. Um especialista revisa antes de qualquer coisa sair.

04

Você recebe o laudo

Em até 24h úteis no diagnóstico gratuito. Em PDF — ou numa branch de análise, se você tiver concedido permissão de escrita.

Para o sistema completo o prazo é informado depois que medimos o repositório — número de linhas, linguagens e arquivos. Não prometemos prazo antes de saber o tamanho do que vamos ler, porque essa promessa não se cumpre.

Limites

O que a gente não faz

Se você chegou até aqui, provavelmente prefere saber isso agora e não na terceira reunião.

  • ×

    Não alteramos o seu código

    Nem abrimos pull request com correção, nem “arrumamos enquanto passamos”. O produto é o diagnóstico. Corrigir é decisão sua, com o seu time — e, se quiser, pode ser contratado à parte com a Maya.

  • ×

    Não substituímos o seu linter nem o seu SonarQube

    Eles leem cada arquivo e apontam estilo, complexidade e cobertura — e fazem isso bem, a cada commit. Eles enxergam o arquivo; nós enxergamos o sistema. Nenhum deles diz que dois arquivos implementam a mesma regra de negócio de formas diferentes.

  • ×

    Não usamos o seu código para treinar modelo nenhum

    Nem o nosso, nem o de terceiros. O código entra para ser lido naquela análise e sai do processo depois dela.

  • ×

    Não prometemos 24 horas para sistema grande

    As 24h valem para o diagnóstico gratuito de 10 mil linhas. Sistema inteiro consome mais processamento e mais tempo de revisão humana, e o prazo real sai depois que medimos o repositório.

  • ×

    Não é laudo gerado só por máquina

    O agente faz a leitura pesada; um especialista da Maya revisa cada achado e assina antes de você receber. É por isso que o documento se sustenta numa discussão técnica.

Como o código chega até nós

Duas formas, e a diferença entre elas importa

A escolha muda quem guarda o quê. Está escrito aqui porque essa é a primeira pergunta que qualquer time técnico faz — e deve fazer.

Recomendado

Conexão ao repositório

Você autoriza nosso acesso no GitHub, GitLab, Bitbucket, Azure DevOps ou no seu Git self-hosted. Lemos de lá e escrevemos o laudo de volta.

  • Permissão de leitura já basta. Escrita só se você quiser o laudo entregue dentro do repositório
  • Nenhuma linha do seu código é alterada — e isso é verificável no histórico do seu próprio Git
  • Você revoga o acesso quando quiser, sem falar com a gente
  • Com escrita, o laudo chega numa branch nova qafactory/diagnostico-aaaa-mm-dd; sem escrita, chega em PDF
  • Nenhuma cópia do seu código é guardada depois da análise
Alternativa

Envio de arquivo

Se você não pode ou não quer conceder acesso ao repositório, envie um .zip. Funciona igual — mas você precisa saber o que muda.

  • Mais simples: não passa por infraestrutura nem por comitê de acesso
  • !O arquivo fica sob nossa guarda durante a análise, criptografado, e é apagado em até 7 dias após a entrega
  • !Não há branch para escrever, então o laudo chega em PDF
  • !Sem histórico do Git, perdemos sinais úteis: idade do código, quem mexeu onde, o que mudou junto

Como liberar o acesso para a Maya

Você concede acesso a um repositório específico — nunca à sua organização inteira — e revoga quando quiser, sem falar com a gente. Nossa conta é esta:

Padrão · recomendado

Somente leitura

É o suficiente para o diagnóstico. Lemos o código e devolvemos o laudo em PDF. Não conseguimos alterar nada, nem por engano.

Opcional

Leitura + escrita

Só faz sentido se você quiser o laudo entregue dentro do repositório. Criamos uma branch nova e nada além disso — nenhuma branch existente e nenhum arquivo seu são tocados, e o histórico do Git prova.

GitHub
  1. Abra o repositório e vá em Settings.
  2. No menu lateral, em "Access", clique em Collaborators (ou Collaborators and teams, se for repositório de organização).
  3. Clique em Add people e digite mayacodereview.
  4. Escolha a permissão Read — ou Write, se quiser o laudo em branch.
  5. Confirme. Recebemos o convite por e-mail e aceitamos.

Para revogar: mesma tela, botão de remover ao lado da conta.

GitLab
  1. Abra o projeto e vá em Manage → Members.
  2. Clique em Invite members e informe mayacodereview ou contato@mayaconsulting.com.br.
  3. Função: Reporter para leitura — ou Developer, se quiser o laudo em branch.
  4. Se quiser, defina uma data de expiração do acesso já no convite.

A função Guest não enxerga o código em projeto privado — por isso Reporter é o mínimo.

Bitbucket
  1. Abra o repositório e vá em Repository settings → User permissions.
  2. Adicione contato@mayaconsulting.com.br.
  3. Permissão: Read — ou Write, se quiser o laudo em branch.

Para revogar: mesma tela, remover o usuário da lista.

Azure DevOps
  1. Em Organization settings → Users → Add users, informe contato@mayaconsulting.com.br.
  2. Nível de acesso: Basic.
  3. Selecione o projeto e adicione ao grupo Readers — ou Contributors, se quiser o laudo em branch.

O nível Stakeholder não dá acesso ao código do Azure Repos. Precisa ser Basic — o plano gratuito inclui 5 usuários Basic.

Git self-hosted ou outro provedor
  1. Crie um usuário somente-leitura para contato@mayaconsulting.com.br, ou nos envie uma deploy key / token de leitura com escopo naquele repositório.
  2. Se o servidor não for acessível pela internet, um espelho somente-leitura temporário resolve — ou o envio do .zip.

Nos diga qual é o seu ambiente no cadastro: a gente se adapta ao que a sua política de segurança permitir.

Não precisamos de acesso ao seu pipeline, a segredos, a variáveis de ambiente nem a qualquer outro repositório. Se a sua política pedir NDA assinado antes da liberação, é só avisar no cadastro.

Diagnóstico gratuito

10 mil linhas, de graça, com um achado revelado

Você recebe o laudo do recorte analisado e o primeiro achado por escrito, com arquivo, linha e impacto. Os outros saem na conversa com o consultor que revisou o seu caso — não é um robô te ligando depois.

  • Recorte de até 10 mil linhas, escolhido pela representatividade dentro do sistema
  • Resposta em até 24h úteis, com a documentação do que aquele trecho faz
  • Sem compromisso — se o seu sistema for maior, o orçamento sai só depois de medirmos o repositório

Prefere falar direto? Chamar no WhatsApp ou escrever para contato@mayaconsulting.com.br.

Usamos o seu contato só para devolver o laudo e falar sobre ele. Sem lista, sem sequência automática.

Dúvidas

O que costumam perguntar antes

Preciso ter documentação do sistema?
Não. Se você tiver, ela ajuda e acelera — pode enviar junto. Se não tiver, a documentação do que o sistema faz é o primeiro subproduto que a análise gera. Exigir documentação inviabilizaria justamente quem mais precisa do serviço.
Quem lê o meu código, na prática?
Nossos agentes fazem a leitura, e um especialista da Maya revisa e assina o laudo. Trabalhamos sob NDA sempre que você pedir — e, na modalidade de conexão, o acesso é de leitura e revogável por você a qualquer momento.
Vocês cobrem a minha linguagem?
Cobrimos as stacks mais comuns do mercado, incluindo sistemas legados. Diga qual é a sua no cadastro: se não conseguirmos dar um diagnóstico à altura, respondemos isso francamente em vez de entregar um laudo raso.
E se o meu sistema tiver 300 mil linhas?
O diagnóstico gratuito analisa um recorte de até 10 mil linhas — serve para você ver o método e o tipo de achado. Para o sistema completo, medimos primeiro o repositório (linhas, linguagens, arquivos) e só então falamos de prazo e de investimento. Sistema maior consome mais processamento, e isso aparece no orçamento.
Isso vai virar uma lista de 300 problemas que ninguém lê?
Não. O laudo é priorizado: cada achado vem com impacto e esforço estimado, e o plano de ação diz o que fazer primeiro. Ferramenta que despeja achado sem ordem você já tem.
Depois do diagnóstico, vocês corrigem?
O qaFactory vai até o diagnóstico. A correção é um trabalho separado, que a Maya pode assumir com o time e os agentes da AI Software Factory — mas é uma decisão sua, tomada depois de ler o laudo, e nunca uma condição para receber o diagnóstico.