Force.com Code Modularity – Quite an ignored module
Introduction
Recently, I got a chance to visit one famous Indian restaurant in Rotorua, New Zealand. The restaurant was very nice and was famous for serving various Indian delicacies. For an instance lets imagine the restaurant serves everything you ask for in one single plate. Welcome drink, Soup, Papadum, main course, desserts everything will be served in one single plate. A very horrifying image of food now is in front of you. If presented in such a terrible way, even though the individual dishes were tasty, you’d refrain to eat it. Won’t you? Something similar happens with your Force.com code especially Apex Controllers and Visualforce Pages, if they’re not modularized and are not well written to have good code readability.
One might argue on best practices where the code is written to ensure no governor limits would hit. Governor limit is important but not the only thing to consider while writing the code.
What it is?
Consider a mid-sized enterprise say a retail industry with various products which they cater with, to their customers. Considering the complexity of the business rules, they decided to build the app using Visualforce and Apex which would allow their Sales reps to create leads.
A Visualforce page, which when entered the appropriate information creates an Opportunity for a given product, where there is a huge custom logic to validate the data for each one of the product with separate business rules for each one of them.
Now, if the code is not modularized and all the logic is written in one single Visualforce page and the associated Apex controller, at the end of the day it won’t be a surprise to see both the files with more than 2000 lines of code or even more than that. This is like that of the plate with all food in it, which one certainly would refuse to eat.
Challenges
Initially when the application is new, it might run smooth whereas there are certain factors which might put the application at risk in future.
Code Scalability:
Initially the application was developed to cater certain products only. What if in future, there’s addition of new products for which a separate logic must be introduced which certainly would be the case for any enterprise. If the modularity isn’t there and disparate logic is not written for each product, the application is not scalable. Not good. Isn’t it?
Test Code coverage:
Even a small change in such a big code can affect the code coverage badly. Before that, I doubt if the code was deployed to production environment with test code covering all the Apex or at least 90% of it. Yeah, writing an effective test code for a class with more than 2 KLOC is not an easy task. Taking it to 75% and deploying it is someone would look for bearing in mind the scheduled release. So any new fix or change in the code is going to take the code coverage further more down, making it more challenging to revive the code coverage.
Productivity:
How about some other developer who is asked to work on such code to fix a bug or may be extending it? That developer would take his / her own good time to understand the code before even starting to work on it. Chances are high, their productivity will get affected and risk of not meeting deadlines is high.
Code Readability:
One might have to consider using scroll wheel mouse while working on such kind of code. Also, it’s very much likely that code indentation and code readability is not as per the standard practice.
Summary:
This article is mainly intended to explain the need of modularity and why writing the code should be broken down into pieces and kept separately than having them in one single file. There isn’t any emphasis on a specific design pattern to follow as it varies based on the requirement and the overall echo system of the project.
SFDC with Siddharth 