The problem
C# project consisting of WCF services used by a Flex application.
A customer may request a functionality change that requires me to alter code to work just for them. It could be a single line of code in a method or maybe a method acts in a totally different way for customer x.
My Ideas
-
Use branches for customers that have a customization. When a release is ready, merge to customer branches and try not to break / forget what their customization was for. We use SVN. I’m not a huge fan of this as the code base is very large.
-
Use inversion of control, dependency injection, and MEF. Create an interface for the class/s that needs to be modified. Create a new class library project (that is, customerabc), add a new class that implements the class just created, override method/s as needed for customer changes. Add a MEF export. I then place this in a customization folder and point MEF there. If it finds a DLL file in the folder, it uses that instead of the export from the executing assembly.
I like option 2.
Pros :
- Easy – normal deployment install, then drop in their DLL file.
- Obvious – it might not be overly clear wether or not a customer is running code from their branch. With this option I could just look at the customization folder.
- Clean – only the files that need to be customized exist. There isn’t any need for a full copy of trunk. d. It promotes better SOLID for future development and refactoring (this project has little OOP).
Cons:
- It will be harder to manage changes in trunk out to the customer projects.
- It doesn’t necessarily solve my problem with database changes or changes on the Flex side.
- If the change is a single line of code in a 500 line method, I don’t see any other option than to override that method, copy paste the code to the customer override and make the one line change. This isn’t good use of DRY to me, but is there a good way around this?
- OK, so better use of OOP and SOLID principles could mitigate some of this, but it also means that to implement a simple customer request, I have to do some major refactoring to the whole class… potentially many classes.
What should I do?
4
Option #1 is reasonable, but it represents a big hassle.
Option #2 should be the dictionary definition of overengineering.
Option #3: consider this:
Instead of multiple disjoint sets of requirements, (one for each client,) suppose that you have a single set of requirements, covering all customers, with the additional requirement that any given installation of your application should cater to a single customer, which is specified in configuration.
True, this means that specific customer concerns will be scattered throughout the codebase, and that every customer will be receiving inactive features, possibly even unused database tables and columns, but do they need to know? And if they do need to know, do they care? Do they mind? Would they please mind their own business and let you do your job in whatever way is more productive for you?
My car engine has some hooks on it. I have no use for these hooks, but they are there because they made it much easier to install the engine in the factory, and much safer for the workers there, so the presence of these hooks has actually lowered the end price that I paid for my car. So, I am perfectly fine with these otherwise useless hooks.
3