Simply by pushing your code out of boilerplate will force you to build more scalable code fitting your agile model development.
I’ve seen many developers use this software pattern (or refactor), but I didn’t seen this published as a formal guideline as a standard for writing scalable code.
But following this guideline in your coding style will make your code robust and scalable.
Pushing code out of boilerplate means that you separate the activation code from the logic, for example:
1. when you write an HTTP route, the route boilerplate and you code should be separated.
2. when you write React actions, the action specific code and the application logic should be separated
3. in C program separating the code out of main is also considered separating code from boilerplate because main is provided by the infrastructure.
Following this guide in all of your code will promote separation of infrastructure from your domain logic
In the following route the route and application logic are mixed:
module.exports = async (req, res) => {
const {
queryData
} = req
try {
const data = {
api: ${PUBLIC_URL},
cdn: ${APP_SERVING}/${VERSION},
}
res.header('Access-Control-Allow-Origin', '*')
return res.json({
success: true,
data,
})
} catch (e) {
logger.error({ stack: e.stack }, 'error with metadata route', { message: e.toString()
})
}
Simply by extracting the logic from the boilerplate you get the following code:
module.exports = async (req, res) => {
const {queryData} = req
try {
const data = controller.getMetadata(queryData)
res.header('Access-Control-Allow-Origin', '*')
return res.json({
success: true,
data,
})
} catch (e) {
console.error(
{ stack: e.stack },
'error',
{ message: e.toString() }
)
}
the controller is then becomes
const getMetadata = queryData => ({
api: ${PUBLIC_URL},
cdn: ${APP_SERVING}/${VERSION},
})
Keeping this simple rule anywhere in your code will make your code scalable from day one.
Let’s summarize the gain:
π₯ Clear guideline to check your code for more refactor opportunities, if you see boilerplate mixed with logic, extract out the logic to the application logic layer
π₯ Clear boundary between you infrastructure and application logic
π₯ Promote single responsibility between infrastructure and logic
π₯ Promote easy logic testing as separate layer
π₯ Promote application logic encapsulation and decoupling (i.e. logic in separate lib) easy to refactor to application domain structure
π₯ Boilerplate code becomes repetitive and provide additional refactor opportunities to abstract and reuse the infrastructure code
Pay attention about creating clear boundaries when starting to use that guideline, sometimes you will be tempted to send variables from one boundary to another, for example sending the req object of the router to the application domain – that is not allowed and promoted code that is not scalable.
You have to create decoupled interfaces between the layers, so in our previous example you should extract all the information from the req object and send them as another object into the application layer of as single parameters. Another example can be passing data from UI into the application logic – such shortcuts will downgrade the scalability of your code.
WDYT? π