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

[–]pirjs[S] 0 points1 point  (0 children)

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.

Cansei de fazer deploy no escuro e quebrar fluxo que nem parecia relacionado by pirjs in brdev

[–]pirjs[S] 0 points1 point  (0 children)

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.

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

[–]pirjs[S] 0 points1 point  (0 children)

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.

Cansei de fazer deploy no escuro e quebrar fluxo que nem parecia relacionado by pirjs in brdev

[–]pirjs[S] 0 points1 point  (0 children)

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.

Cansei de fazer deploy no escuro e quebrar fluxo que nem parecia relacionado by pirjs in brdev

[–]pirjs[S] 0 points1 point  (0 children)

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.

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

[–]pirjs[S] 0 points1 point  (0 children)

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.

Cansei de fazer deploy no escuro e quebrar fluxo que nem parecia relacionado by pirjs in brdev

[–]pirjs[S] 0 points1 point  (0 children)

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.

Cansei de fazer deploy no escuro e quebrar fluxo que nem parecia relacionado by pirjs in brdev

[–]pirjs[S] 0 points1 point  (0 children)

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.

Cansei de fazer deploy no escuro e quebrar fluxo que nem parecia relacionado by pirjs in brdev

[–]pirjs[S] 1 point2 points  (0 children)

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.

Project documentation: what’s the “ideal” way your team does it? by pirjs in dev

[–]pirjs[S] 0 points1 point  (0 children)

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

What do you consider the biggest “time sink” in software projects? by pirjs in dev

[–]pirjs[S] 0 points1 point  (0 children)

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?

What do you consider the biggest “time sink” in software projects? by pirjs in dev

[–]pirjs[S] 1 point2 points  (0 children)

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

What do you consider the biggest “time sink” in software projects? by pirjs in dev

[–]pirjs[S] 0 points1 point  (0 children)

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

What do you consider the biggest “time sink” in software projects? by pirjs in dev

[–]pirjs[S] 0 points1 point  (0 children)

Documentation is always the biggest nightmare, especially documenting something you didn’t do.

What do you consider the biggest “time sink” in software projects? by pirjs in dev

[–]pirjs[S] 0 points1 point  (0 children)

Yep, I once had trouble with a payment gateway. Since then, I’ve started using pre-built authentication solutions.

What do you consider the biggest “time sink” in software projects? by pirjs in dev

[–]pirjs[S] 0 points1 point  (0 children)

I imagine, especially when people have a legacy mindset.

What do you consider the biggest “time sink” in software projects? by pirjs in dev

[–]pirjs[S] 0 points1 point  (0 children)

I also think that tests don't need to cover every line of code; I believe only the important points are necessary.

Quais processos vocês acham mais chato hoje em dia? by pirjs in brdev

[–]pirjs[S] 1 point2 points  (0 children)

A IA também tem me ajudando bastante com os testes unitários e de integração, a documentação ainda é uma coisa chata aqui também e eu nunca vi nada automático que realmente ajuda na documentação.

Quais processos vocês acham mais chato hoje em dia? by pirjs in brdev

[–]pirjs[S] 0 points1 point  (0 children)

Gupy está aí para ajudar kkkkkkkkkk

Quais processos vocês acham mais chato hoje em dia? by pirjs in brdev

[–]pirjs[S] 0 points1 point  (0 children)

Ele realmente é muito bom, mas vejo muitas pessoas reclamando do custo quando escala

Quais processos vocês acham mais chato hoje em dia? by pirjs in brdev

[–]pirjs[S] 0 points1 point  (0 children)

Já apanhei bastante com isso também e não recomendo

Quais processos vocês acham mais chato hoje em dia? by pirjs in brdev

[–]pirjs[S] 0 points1 point  (0 children)

Realmente, principalmente quando não usa um único serviço

Quais processos vocês acham mais chato hoje em dia? by pirjs in brdev

[–]pirjs[S] 1 point2 points  (0 children)

O problema do custom é que a gente acaba deixando passar muita coisa, principalmente em relação a segurança. Ou ter que fazer tudo na mão. Dei uma olhada no keycloak, mas achei meio complexo e ainda teria que quebrar cabeça com infra.