The refactoring factor

The world we live in is fascinating and its easy to take amazing things for granted that make our lives easier.

If you have some coding experience and had to refactor some piece of working software you will probably appreciate the tools that allow you to do refactoring.

I became a Python developer after some years’ experience in Java because of its “hassle-free” dynamism that liberated me from primitive text-based IDEs and static compilers. This was until I revisited all the cool IDEs, like Eclipse, that made Java an attractive development technology again, not because something fundamentally changed in the language, but because the tools made coding much more enjoyable, like refactoring your code without breaking it.

If you are a Mendix Business Engineer you are not excluded from the fold of the fantastic refactoring forte. You probably just haven’t been made aware that you are.

Loosely stated

“Code refactoring is a disciplined technique for restructuring or altering existing code and internal structure without changing its external behaviour, undertaken in order to improve some of the nonfunctional attributes of the software.”

The ability to change chunks of  what goes on “behind the scenes”, like data models and flow logic where the end-user is unaware of these changes, is an almost everyday occurrence. Ever noticed the errors in your Error viewlet in the modeler when you’ve made structural changes, like deleting an association or adding an enumeration though not changing any interfaces? Well, this is the modeler implicitly guiding you in some cases to apply refactoring.

Refactoring in action

This past week we delivered a project for a sprint review where we had to implement a new complex widget 30 minutes before the actual review as our definition of done was in a liberal phase. The implementation wasn’t a straight forward one as the data model required to operate the new widget was fundamentally incompatible with the existing model.

Needless to say, the business modeler allowed me to make huge changes and commit it back to the cloud in 29 minutes. That was quick refactoring for that load of work. I was thoroughly impressed with this gamble and needless to say the review was positive. Now, the obvious way to solve these kind of “cutting the red wire a second before the bomb goes off” situations is to avoid them entirely, but the rule however does not cover the exceptions and exceptions occur and you have to be flexible when it happens.

One feature worth mentioning is the Extract Microflow that allows you to take a selection of actions in your microflow and promote it to a separate microflow. Its clever enough to infer what parameters are needed and pre-populates the new microflow with them, returning a value if needed. Having this kind of refactoring capability inside a modeling tool is very cool indeed:To wrap things up, here is a little video demonstrating some refactoring in action. Its a simple app that starts up with a search screen that allows you to find existing customers. If they are not found, the app creates them using the “Get-Create” design pattern discussed in an earlier post.

Note that the app should work as it did after the changes, only improving the inside guts of our system. In essence the change allows us to make a sub section of our microflow re-usable by future improvements and cleans up an existing microflow.