Go to portal
According to Wikipedia, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behaviour. Refactoring improves non-functional attributes of the software.
Why do we need code refactoring?
As with any other programming languages and platforms, sometimes circumstances lead us to a non-desired coding scenario. These scenarios my affect the platform in different ways such as poor performance for the end users, code that is difficult to maintain or even worse, a situation where scaling the functionality is a real challenge and where companies have had to start their developments in ServiceNow from scratch.
How can I identify if my instance needs code refactoring?
QC for ServiceNow can help organisations to identify and prioritise the areas that need refactoring. It will also provide a consistent, refactoring discipline that will help to improve the code structure.
To do so, there are some dashboards which can be used after a code analysis is performed by QC for ServiceNow.
The first dashboard to use is the Most configured areas one. The dashboard classifies all the configuration elements such as business rules, client scripts, UI actions, dictionary entries etc. by application. In the example shown in the image below, we can observe that 525 elements are in the global scope. Since Fuji’s release, elements can be scoped into applications. So now this could be an area to review. Scoping the elements to the right applications helps with code maintenance. Building scoped applications allows you to associate your elements with a specific application, hiding the implementation details and enforcing application independence.
Therefore, businesses should consider starting to create applications and “migrating” code to the right scope. Unfortunately, ServiceNow does not offer a migration tool to do so.
Another case is shown in the example above, where Incident and Service Catalogue are the two main customised applications in this particular instance. Let us take a closer look at their architecture and its quality.
Service Catalogue needs a little more attention than incident in this case. The ratio number of configuration elements vs defects is higher.
Incident:
Incident has 16 issues classified as high severity.
Catalogue:
Catalogue has got 26 high severity incidents. If we take a closer look at these incidents in Catalogue with high severity, we can observe that most them affect scalability, which is key when carrying out refactoring work.
In this particular case, the incidents refer to business rules not wrapped within functions. In these scripts, user-created variables are globally scoped by default. If a new variable is declared in an order 100 business rule, the business rule that runs next at order 200 also has access to the variable. This may introduce unexpected behaviour.
The recommended method for preventing such unexpected behaviour is to always wrap your code in a function. This protects your variables from conflicting with system variables or global variables in other business rules that are not wrapped in a function.
This area would be an easy and clear one to start our refactoring work and achieve better, clean code in our ServiceNow instances.
Finally, we can also download the findings file in a CSV and look for repeated names in functions. That will probably help us to uncover duplicated code, another area for analysis. Duplicated code will be also easily spotted if there is an issue in any of the duplicated lines since the same issue will appear in multiple functions but normally in the same line.
Regular code checks on the instances will prevent us having to carry out major refactoring work down the line.
