development process 3106

Perhaps. Or not. Refactoring, like a lot of other choices, are up to the individual developers, and get done as the developers, or their managers, notice problems justifying the work. Code smell is a real thing, but fixing it, like everything else, has to be weighed in the context of the overall problems we are trying to solve. Short source files just does not buy that much.

Some clbuttes provide functionality for many applications. Developers working on those applications may customize at the app level, or they may push a fix or generalization up into the core library. Contrawise, if functionality in a library is no longer used by more than one app, it may get pulled back down into the app, or expunged entirely.

If more than one developer does this at the same time, then the same file in that library may well end up modified by more than one person. Particularly if they are changing interfaces that many clbuttes implement.

Amusing. We deliver over a hundred applications spread over a hundred and fifty jars, with over 6200 files of java source.

Yep. Heard a lot about them, and have given them much thought in light of an industry whose dwell time is under two years at a given job. I suspect we have wrestled with these issues more than many, given a very active team, lots to do, and rapidly changing scientific data analysis needs.

Testing, like everything else, is done based on how the managers driving the projects prioritize it. There is interest in unit testing, and some does get done, but in the main, integration testing gets the most effort.

Libraries get the best testing, as it is quite bad mojo to break a library that others depend on. Applications meant for less send users also get quite a bit more testing, as do those that change core data. All of this happens in parallel, and people take a fair amount of care to keep things working.

Scott