A primeira coisa que confiro em qualquer código

Quando uma base de código cai na minha mesa, não começo pelo README, pelo diagrama de arquitetura nem pela suíte de testes. Começo por uma busca: todo lugar em que o sistema escreve no banco de dados. Inserts, updates, deletes, upserts, saves do ORM, SQL cru, stored procedures. Listo tudo, e depois conto. Esse número me diz mais sobre o sistema em dez minutos do que um dia de leitura.

Por que o caminho de escrita

Leituras podem estar erradas e o dano é temporário: uma página desatualizada, um número errado na tela, some com um refresh. Escritas são permanentes. Uma escrita errada é uma linha corrompida que toda leitura futura vai devolver fielmente, para sempre, até alguém notar. Todo bug sério de dados que encontrei em mais de 600 projetos foi uma escrita que não deveria ter acontecido, aconteceu duas vezes, aconteceu pela metade ou aconteceu na linha errada. Se só tenho uma hora, é no caminho de escrita que a hora vai.

O que a contagem me diz

Se há cinco lugares que escrevem na tabela de pedidos, sei que as regras de negócio de pedidos moram em cinco lugares e provavelmente discordam. Se há cinquenta, o time não tem noção de fronteira de escrita e cada funcionalidade inventou a sua. Se há um, alguém pensou nisso, e vou conferir se esse lugar é usado de verdade ou se os outros quarenta e nove passam por fora com uma query crua 'só para o script de migração'.

A contagem é um indicador de disciplina. Baixa e centralizada significa que o sistema tem espinha. Alta e espalhada significa que o modelo de dados é o que a última funcionalidade precisou que ele fosse.

As três perguntas em cada escrita

Para cada ponto de escrita faço as mesmas três perguntas. Está dentro de uma transação com as outras escritas a que logicamente pertence, ou o sistema pode cair entre elas e deixar meio estado? É idempotente, ou seja, rodar duas vezes com a mesma entrada produz o mesmo resultado, ou um retry cria duplicata? É validada nesta fronteira, ou confia que quem chamou já conferiu? A maioria dos pontos de escrita falha em pelo menos uma. Os que falham nas três são onde começo o relatório.

O que encontro, com regularidade

Um update que define um status sem conferir o status anterior, de modo que um pedido cancelado pode virar pago. Um insert dentro de um loop sem transação, de modo que uma queda no item sete deixa seis órfãos. Um delete que roda antes de a coisa que dependia dele ser atualizada. Um save chamado de um handler de evento e de novo da rota de API que disparou o evento. Nada disso é exótico. É o que acontece quando escritas estão espalhadas e ninguém é dono do caminho.

Só depois do mapa de escritas é que olho arquitetura, testes e documentação, e agora leio de outro jeito. Quando o diagrama mostra uma fronteira limpa entre serviços, já sei se as escritas a respeitam. Quando os testes estão verdes, já sei quais pontos de escrita não têm teste nenhum. O resto da auditoria é, em grande parte, explicar o que o mapa de escritas já revelou.

Faça isso no seu próprio código

Você não precisa de auditor para isso. Busque toda escrita na sua tabela mais importante, coloque os resultados numa lista e responda as três perguntas para cada um. Leva uma tarde. Na maioria das bases de código isso produz pelo menos um achado que, de outro modo, apareceria como um ticket de suporte com a palavra 'duplicado', daqui a seis meses, na pior hora possível.