Comment on Reality check: Our Go backend stack
Shaner@programming.dev 11 months ago
I ran across this today: graphite.dev/…/how-large-prs-slow-down-developmen…
They describe just the problem you are experiencing: change amplification.
Contrary to some comments this is not a sign of good architecture. It may be needed at your company, but if I was betting I’d bet it’s not.
colonist@programming.dev 11 months ago
To enable smaller PRs we need to get rid of all the generation artefacts in the PR.
You won the bet. We don’t need that architecture, at leas in my opinion. We’re a startup. We need something to iterate as fast as possible, without craping our code base. Requirements change a lot. The initial folks did a lot of big brain thinking and introduced a lot of things that might be need to be abstracted, and most of them haven’t been used to date and just add complexity.
spacedogroy@feddit.uk 11 months ago
As a bit of low-hanging fruit, you may be able to reduce the length of the diffs in an MR by marking generated files with
-diffin a.gitattributesfile. This is at least supported by GitLab (not sure about others): git-scm.com/docs/gitattributes#_marking_files_as_…colonist@programming.dev 11 months ago
Looked into that yesterday. I can mark generated files as generated. It collapses them but doesn’t remove them from the review, which is a bit annoying. Need something like a .diffignore