Comment by throwawayscrapd
Comment by throwawayscrapd 6 days ago
Did you ever consider refactoring the code so that you don't have to do shotgun surgery every time you make this kind of change?
Comment by throwawayscrapd 6 days ago
Did you ever consider refactoring the code so that you don't have to do shotgun surgery every time you make this kind of change?
I mean given that you've had this problem repeatedly, I'd call it "past-proofing", but I suppose you know your codebase better than I do.
If you have some idea of what future changes may be seen, it is fine to design for that. However, it is impossible to design a codebase to handle any change. Realistically, just doing the absolute bare minimum is probably the best defence in that situation.
I wouldn't try to automate the DB part, but much like the protobufs code is generated from a spec, you can generate other parts from a spec. My current company has a schema repo used for both API and kafka type generation.
This is a case where a monorepo should be a big advantage, as you can update everything with a single change.
It's funny, but originally I had written a codegenerator that just reads protobuf and generates/modifies code in other parts. It's been ok experience until you hit another corner case (especially in UI part) and need to spend another hours improving codegenerator. But since after AI coding tools became better I started delegating this part to AI increasingly more, and now with agentic AI tools it became way more efficient than keeping maintaining codegenerator. And you're right about DB part - again, now with task description it's a no brainer to tell it which parts shouldn't be touched.
A lot of that is inherent in the framework. eg Java and Go spew boilerplate. LLMs are actually pretty good at generating boilerplate.
See, also, testing. There's a lot of similar boilerplate for testing. Giving LLMs a list of "Test these specific items, with this specific setup, and these edge cases." I've been pretty happy writing a bulleted outline of tests and getting ... 85% complete code back? You can see a pretty stark line in a codebase I work on where I started doing this vs comprehensiveness of testing.
You mean to future proof the code so requirements changes are easy to implement? Yeah, I've seen lots of code like that (some of it written by myself). Usually the envisioned future never materializes unfortunately.