How to refactor into sustainable applications with OutSystems

What is one of the first things that come to mind when you think of Italy? Spaghetti, right? Who doesn’t like spaghetti on a beautiful summer evening alongside a glass of wine? I have to admit that I am one of those spaghetti lovers but not when it comes to coding your Low Code application. But what do we mean by ‘spaghetti code’ and is this really possible within a Low Code platform like OutSystems?!

This term ‘spaghetti code’ gives the seasoned developer shivers. Spaghetti code is confusing and complex in nature, but also unsustainable, unmaintainable and impossible to debug. Even with OutSystems it is possible to create a spaghetti structure, but it can be prevented with the right measures. Here are the guidelines you can follow to make sure spaghetti is only on your plate and not in your code.

It all starts with identification of architecture violations. OutSystems offers a great tool called Discovery that helps you to analyse, measure and understand how to improve your factory architecture. It measures your architecture indicators by recognizing architecture flaws and providing direction on how to fix them.

Rethinking Architecture

Once you have identified the applications and modules you need to prioritise the violations. I prioritize architecture violations in the following way:

1. Upper and side violations to end-user modules;
2. Direct cycles between core modules;
3. Upper violations to core modules;
4. Direct cycles between Foundation modules;

But what about the impact on your current application factory?

Let's start with the theory behind refactoring. Refactoring your application is done in such a way that it doesn't change the behaviour of the Low Code application itself, but it improves the deep structures of your application's architecture to ensure correct abstracting of reusable services, isolating end-user processes, and avoiding unmanageable references.

Based on your analyses, you understand which components, elements, entities and other parts of the application are affected by refactoring. I’ll explain moving elements from one module to another because, if you don't think it through, you might end-up lose functionality which in all cases should be prevented.

There is a fantastic tool in the Forge, the OutSystems store, for moving elements called Refactor. This tool simplifies the refactoring of your application and it is almost like copying and pasting text from one document to another. You can easily move elements such as timers, roles and site properties in an easy and maintainable way. Bottom line please think and reconsider before actually executing the movement of elements or entities to minimise impact on your application.

A summary of the refactor steps in Outsystems

Within each category, first select the module with the most consumers. It will resolve more conflicts due to the relationship between a producer and consumer. Consider the impact of each individual module prior to refactoring and plan to minimise risk. Restructuring your data models tends to be riskier than others. The development of new features (or maintenance) on refactored modules must be stopped, until the refactored modules reach production.

Last but not least, plan and plan again. We have refactored many application factories for our customers and, in doing, saw that planning is essential alongside technical skills and experience. With our approach, clients were able to have a clean sheet in merely 3-4 sprints and could maintain it on that level by making use of our coaching on best practices, agile delivery and the provision of proper tools.

Consider these practices and tools so that your refactoring project runs smoothly.

Helpful tips

• The problem with spaghetti code isn't just your development team. Processes must be put in place to prevent spaghetti code from being developed. For example, include in your definition of ready that developers should develop in accordance with OutSystems best practices and use tooling such as the architecture dashboard to comply accordingly.
• Rather than an accusatory culture, create an open and inspiring culture that encourages discussing developer mistakes so that everyone can learn from them.
• Document your application, even with a Low Code platform like OutSystems.
• Test your application and test it again (quality assurance) before you deploy your refactored modules to the production environment.
• But above all, have fun coding!

Helpful tools within OutSystems

• Architecture Dashboard
• Discovery
• Refactor Component