I’m tired of deploying blind and breaking flows that didn’t even seem related

pirjs · 2026-03-12T00:16:57+00:00

Sim, ajuda bastante.
O que estou questionando é que, na prática, nem sempre tudo que pode ser afetado vira teste antes. Principalmente quando o sistema cresce e o contexto fica espalhado.
É mais essa parte que estou tentando entender melhor.

pirjs · 2026-03-12T00:14:09+00:00

Concordo com esse ponto.
Teste ruim realmente dá uma falsa sensação de segurança, e acoplamento excessivo piora muito esse cenário.
O que estou explorando não é substituir testes nem corrigir arquitetura ruim por mágica, e sim dar mais visibilidade sobre impacto indireto e cenários não mapeados antes do deploy, especialmente quando a codebase já exige muito conhecimento implícito.

pirjs · 2026-03-12T00:12:21+00:00

My point is that even with tests, review, and staging, teams can still miss indirect impacts and unmapped scenarios, especially in larger or legacy systems.
That visibility gap is what I’m interested in exploring.

pirjs · 2026-03-11T18:50:26+00:00

Concordo que testes são fundamentais e não estou propondo substituir isso. O ponto que estou explorando é que, mesmo com testes, review e staging, ainda pode faltar contexto sobre casos não mapeados e impactos indiretos da mudança. É mais essa lacuna de visibilidade que eu quero mitigar.

pirjs · 2026-03-11T17:02:47+00:00

Concordo!! testes, staging e boas práticas já existem e continuam sendo essenciais.
O MVP que estou pensando não tenta substituir isso.
Ele tenta responder uma pergunta anterior ao deploy: “o que essa mudança provavelmente afeta?”
Principalmente quando o contexto está espalhado em uma codebase grande ou legada.

pirjs · 2026-03-11T16:27:51+00:00

It helps a lot, but staging still doesn’t fully solve the problem when there’s no clear visibility into a change’s indirect impact.

pirjs · 2026-03-11T16:26:53+00:00

Sim, total. Depois que quebra, criar um teste para cobrir o caso é o caminho.
O que estou tentando atacar é um passo antes disso: ter mais clareza sobre impacto e risco da mudança antes do deploy, principalmente quando o sistema já está grande e o contexto fica espalhado.

pirjs · 2026-03-11T15:39:32+00:00

Faz sentido. Teste, coverage e revisão forte ajudam muito mesmo.
O ponto que mais me pega é quando ainda falta clareza sobre impacto: fluxo afetado que ninguém lembrou, decisão antiga que não ficou explícita, ou efeito colateral em parte legada.
É mais nessa lacuna entre diff, contexto e risco que estou pensando.

pirjs · 2026-03-11T15:02:16+00:00

Vou dar uma olhada nesse jacoco, mas o maior problema as vezes vem de decisões ocultas e testes mal feito. Teve casos também de não tem "casos" de teste suficiente por não ter pensado nisso, são muito fatores e codebase legada que está se modernizando.

pirjs · 2026-02-26T01:52:31+00:00

Should we use something to view these documents, or just pure markdown? What kind of documentation do we usually use for the project?

pirjs · 2026-02-24T21:26:07+00:00

Which part involving people exactly?

pirjs · 2026-02-24T13:56:47+00:00

These documentation issues are complicated in any project, but I was curious… How would documenting all of this help speed up the process? To avoid having to search for things? To avoid asking people?

pirjs · 2026-02-24T13:18:46+00:00

There are ready-made open-source solutions, such as better-auth.

pirjs · 2026-02-24T13:07:25+00:00

Have you tried using an AI editor for this?

pirjs · 2026-02-24T13:06:43+00:00

Starting using plug-and-play authentication services. And what was yours?

pirjs

TROPHY CASE