I'm working on softwares that were built without taking into account that they could be sold in modules. At the present time, when we (the company I'm working in) sell the software we have to install all features on the client. I know that currently there's a technique using "Prism" that solves this situation, but our softwares are already made and we can't start them all over again.
Does anyone know any technique on how to handle this situation?
My thanks in advanced
It would help a lot if you pointed out which specific programming languages are involved (and platforms). Generally speaking, it will depend on a few different aspects.
First of all, if your current code is built in a very monolithic way (i.e., one solid block, with no "removable" parts), then you are in trouble (and probably have been for quite some time since writing and maintaining monolithic code is a nightmare from start to finish). But, more moderately, if your code is just too intertwined to be able to make any kind of easy splits into modules (at least, conceptually speaking), then you should simply pack up what you have as some sort of "core" or monolithic kernel to your code-base, and then start writing the new code in a modular fashion. This will certainly involve writing some interfaces and adaptors to blend to old and new codes, but, in the future, you'll be happy that you did so.
On the other hand, if you do want to make the current code modular, at minimal cost (effort), of course, then that's a more interesting discussion. Assuming that your current code is object-oriented (or somewhat analogous to it) for the most part of it, then you already have some structure to work with. The golden word in modular software is independence, i.e., minimizing inter-dependencies between different parts of the software such that some chunks of it can be reasonably isolated from other parts. You first make these splits conceptually (ask yourself what parts should be independent from others, in principle), and then you can move on to implementing those splits. To implement the splits, the basic approach is to somehow assess the current interdependencies in the code base, and there are tools to do that (e.g., generating call-graphs, dependency-graphs, etc., by parsing the existing code). Then, you identify some key inter-dependencies that are problematic in terms for making the necessary splits, and typically, those spurious links can typically be deleted fairly easily by either moving some code around a bit or by introducing a new base-class (or interface) to act as an in-between that isolates both sides of the spurious inter-dependency. And once you've been able to isolate the "modules" that you want to make optional, the rest is technical.
One of the main obstacles, in many languages and platforms, is that making software which is split into several modules usually involves many little technical issues, like resource management across modules, extensible type identification, forward-backward and across modules compatibility of file formats or other serialization mechanisms, binary compatibility, passing data between modules, etc., etc. Most of these issues are easy to solve when starting from scratch, because they are typically solved by laying out a framework (or using one that exists already) that programmers have to use for everything they do from then on. However, for an already existing code-base, it is pretty much impossible to just go, after the fact, and re-do the entire foundational framework of the library (if it's large, of course, 6-7 digits or more in total count of lines of code). So, in that case, it is probably worth looking for a non-intrusive solution to the problem, and there are some out there, but this is mostly language-specific. One type of solution is to use a higher-level language (or a scripting language) as glue between the modules, examples of that are SWIG or Boost.Python (if the code base is in C/C++), and these will generally allow you to non-intrusively wrap the existing code in some interfaces (so you still have to write interface wrappers, mostly, just listing functions to export). But, again, this is very language specific.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.