Refactoring
Improvements and best practices on existing code base
Software strive to be better and continuously grow, new menus are added to offer higher variety of services, more features are implemented as quality of life improvements on customer’s use of the app.
With the rising complexity of the app, it is also essential for maintaining the source to ensure code quality does not degrade. One way to do it is to constantly refactor.
Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations … cumulative effect of each of these transformations is quite significant — Martin Fowler
Another key component to a clean code base is to follow best practices and design patterns in the framework used since it will be easier for others to understand and.. some people out there that designed it had took much time in thinking the best way of doing things, so it is most likely also be the best for you.
Here I will talk about refactoring and best practices used in our project Moodah POS which is a subsection of an ERP application called Moodah developed by RubyH with React-based frontend, GraphQL middle ware and Odoo as open source back end for ERP systems. Here is a neat summary of the refactoring book by Martin Fowler used as reference for sections in this post.
Bad smells
Bad Smell is a term that has been used for codes that are messy, it says there is part of the code which should be refactored in the future to ensure code quality is high, meaning it is easy to maintain, extend and read.
Duplicated code
The first and easiest to detect smell is code repetition, this can be found when making requests to Odoo system from our middle ware. As usual we have to embrace DRY by extracting similarities into one place, this case defaults are placed inside a function.
Long Parameter List
Next is functions with unclear and many arguments. It is not intuitive what second or third argument is for, however if we split it into methods in functional style, with a well-defined name, it will be much more readable and extensible.
Composing methods
This is a basic pattern to designing your functions, especially ones that call others. It discusses how to best apply designing and calling these methods for readability and extensibility.
Introduce Explaining Variable
Again the power of good names will prevail, if there is a complicated conditional expression, consider naming them into variables for readability.
Substitute Algorithm
JavaScript provide some vanilla functional style programming such as map and every. They should be chosen over imperative like for loops with if since it will create unnecessary complexity and reduce readability.
Hide Method
Our project does not build new classes since we are only passing requests to Odoo-based back end. However, lots of utility functions are created and some which will only be usable in that module or file will not be exported. This can be somewhat viewed as hiding method to not expose others developers with the added complexity of these functions.
Project structure
As the project grows, lines in some of our files began such as schema.ts and integration.ts which contains every request resolver and test cases respectively quickly reaches the one thousand mark. This slows down development as searching for specifics will take longer scrolls.
By searching around, every framework should have at least an agreed project structure by the community. We chose the structure to the right of the picture below to better organize our request resolver and test cases.
React HOC
Now, we move on to best practices on our frameworks used in this project, starting from React.
React revolves around props and states, however the basic way of setting these up if not handled with care will result in convoluted code which is hard to read and add features to.
In this project, the pattern used by RubyH and us to be expected is HOC. With the help of recompose library, we can build complex components with just a few lines.
On the first example, ProductCategoryTable is added the following features by HOC: access to the history for routing, data props that represent result of PosCategories query and when a row in table of POS categories is clicked, redirect to appropriate detail page.
The GraphQL way
GraphQL query language for APIs and an alternative method of communication to the usual REST based API.
It is advised to design a GraphQL server tailored to front end’s needs, this case one of requests needs the record’s id and displayName, we should minimally accommodate that requirement so there are no fields that are never queried for the sake of simplicity.
The last to be discussed is that GraphQL allows for nested queries on relationships. By default Odoo only returns a list of ids on paymentMethods, however this is only half useful for front end hence a nested resolver is implemented to use those ids to query more information about paymentMethod’s model to eliminate the need of front end to do another query just to get those information.
And.. that’s all for refactoring and framework-specific design patterns that we implement in Moodah POS. By doing this process continuously, we can achieve a much cleaner code base and save time when needing to change or add features in the future. Thanks for reading, cheers~
