January 24, 2008
Poor Tool Support Discourages Package Architecture OptimisationI'm a right one to talk, aren't I?
Here I am banging on about how developers should optimise their package architectures as they go, which implies a fair amount of repackaging, and I forget just what a pain in the arse repackaging classes is in some development environments.
Ideally, you want an automated refactoring that allows you to move classes safely and effortlessly between, say .NET or Java projects in your IDE. .NET folks have the worst time, I think. Moving classes between Visual Studio projects can be fiddly, and none of the .NET refactoring tools I've seen does it automatically. Renaming and deleting packages is also very troublesome in .NET solutions. Magnify those problems tenfold if the code is under source control. You can get your project files in a right old pickle, and no mistake, Guv'nor.
Moving a class from one package to another should be a doddle, even under source control
And when things are hard, we tend to avoid doing them. So repackaging tends to be a chore developers prefer to defer - often until they literally have to take days out to do a major repackaging, which can involve stopping anyone else from working on the code while the package structure is noodled about with in the SCC repository.
But it all seems very mechanical, and mechanical stuff can be automated. That's what computers are good at. So why hasn't anyone got around to implementing proper, robust package-level refactorings for tools like Visual Studio?
Methinks it might be because many tool developers hail from the BDUF school of package architecture, yes? whatever the reasons, the upshot is undeniably sub-optimal package architectures, and potentially software that costs more to change and is less reusable.
Posted 10 years, 10 months ago on January 24, 2008