> The example of renaming a function with thousands of callers, for example, is probably better handled by just temporarily aliasing the function, or by temporarily defining the new function in terms of the old.
Why exactly? The best I can think of is that you may annoy people because they'd need to rebase/merge after your change lands and takes away a function they were using.
If you're literally just doing a rename, and you're using something like Java, why not just go ahead and do a global rename?
Because actually getting that commit pushed won't be just clicking "rename method". You'll need to run and pass the presubmits of every single project you made code changes in - and the more projects you're changing at once, the less likely it is that the build is green for all of them at the same time. Then you'll need to get code review approvals from the code owners of each of the clients in one go. Hopefully no new users pop up during this process. If some do, you'll need to iterate again.
Then once some trivial refactoring inevitably causes some kind of breakage ("oh, somebody was using reflection on this class"), you'll need to revert the change. That'll be another set of full code reviews from every single owner. Let's hope that in the meanwhile, nobody pushed any commits that depend on your new code.
None of this is a problem if you have a library and two clients. But the story being told is not "we can safely make changes in three projects at once", it's "we can safely make changes in hundreds or thousands of projects". The former is kind of uninteresting. The latter is a fairy tale.
The latter does happen at Google at least. But it requires tooling to reliably make the change (monorepo-aware refactoring tools, basically), and tooling to run all affected tests. Such large changes at Google are often accompanied by a doc outlining the specific process and possible impacts of the change, and many times are given "global approval" by someone that has that ability rather than requiring individual approvals from each affected team.
That's not true. The process for the large scale changes at Google is described in the "Sofware Engineering at Google" book[0]. Chapter 22 is all about it. There is tooling, yes, but the goal is exactly the opposite of trying to make a single commit across the whole codebase:
> At Google, we’ve long ago abandoned the idea of making sweeping changes across our codebase in these types of large atomic changes.
The article is talking about mitigating risk. Unless I missed something, it doesn't restrict itself to Java, so that's an unreasonable restriction when questioning the author's reasoning. But I don't think it destroys the argument completely.
I suppose a single-developer code base in a fully checked and compiled language that doesn't support any kind of reflection has no particular added risk from renaming vs introducing a new name. Each time you remove one of those constraints, you add a little bit of risk.
If you have a giant company, it might be possible that someone is copying a jar file and calling it in a weird way that you don't expect.
If your language isn't fully checked, you might correctly rename all the Typescript uses and miss a Javascript use.
If the language supports dynamical calling, it might turn out that somewhere it says "if the value of the string is one of these string values, call the method whose name is equal to the value of the string". There's various IPC systems that work this way, and it will certainly be hard to atomically upgrade them. I hate that kind of code but someone else doesn't.
If your language supports you doing these things, you can create as many conventions as you like to eliminate it. But someone will have an emergency and they need to fix it right now.
Some people view the correct way of dealing with that problem is to insist on the development conventions, because we need to have some kind of conventions for a large team to feasibly work together.
But I guess the author leans towards the side that says "if it's valid according to the language/coding environment, it might be better or worse, but it's still valid and we need to expect and accommodate it". It isn't my preference but it's a viable position - technical debt is just value if you can accommodate it without some unreasonable burden.
> If you're literally just doing a rename, and you're using something like Java, why not just go ahead and do a global rename?
It introduces changes to places which really doesn't need changes. We've done both at work, but I mostly prefer just making the old function(s) simply call the new one directly.
Then you won't "pollute" source control annotation (blame) and similar.
Why exactly? The best I can think of is that you may annoy people because they'd need to rebase/merge after your change lands and takes away a function they were using.
If you're literally just doing a rename, and you're using something like Java, why not just go ahead and do a global rename?