Written By Kelvin Tan
One of the many goals that a software engineer should strive is to build a testable and maintainable code and it seems like many unable to program such codes. I am sure there are many reasons that contributes to this factor such as a tight deadline to finish the project, or perhaps the engineer did not learn the proper way of writing a code.
Working at Kaodim, I am grateful for the opportunities to learn from my seniors and be able to understand why we tend to do things the certain way. I remember coding my first feature at Kaodim and I definitely felt inadequate in many ways and started writing spaghetti codes.
As I revisit my first features, I began noticing the mistakes that I have done before and I felt that I could have done it better. For your information, my first feature is called Customer Sign Up which allow new users to sign up and existing users to login with OTP feature. This is the tip of the feature but as we dive deeper, there are many logics that revolve around it. For this feature, August, my senior had created a One Time Password library and I was able to modify it from time to time to fit the needs of the feature.
CODE CLIMATE MEASUREMENT
We use Code Climate to measure our codes quality and maintainability. Before refactoring the codes, my PhoneNumberViewController and VerifyPhoneViewController quality were measured as below:
The plan here is to use Object Oriented Programming specifically Inheritance and with this technique, I am able to write scalable and testable codes. Let me present to you visually our intended code structure.
To give you are a clearer picture, I have two parent classes with a flexible number of child classes. And each child classes will inherit from the parent class, with this I was able to eliminate repetitive codes in the child class and be able to add as many child classes I need.
Let me present to you the screen visually and I’ll give you a scenario. As a new user, I insert my phone number and was prompted to sign up with an OTP code. I then receive my OTP code via SMS and input it on my verifying screen.
With this approach, I was able to minimize redundancy in the codes and have a cleaner code structure. However, as an engineer, it is much clearer by looking at codes. We’ll first look at the parent class where I have an API created by the back end engineers to check the phone number to determine if the phone needs to be verified. With the different condition met, a different function is executed but in my case, I’ve created several empty functions that could be overridden by the child classes
With the child class, we could override the empty function in the child class and decide what we want to do and as you can see, the child class is only 11 lines of codes and it’s really easy to read the codes. Again, most functionality is in the parent class and the child class is the executioner and decide what to do next.
CODE CLIMATE COMPARISON
Now, I am sure we are all excited to see the new score for the code climate and I too am excited to see how I am doing. Let’s look at the comparison of the score below.
That’s two grade up from the previous score. But judging from the maintainability, there is a huge improvement of duration from 24 hour to 25 minutes & 1 hour respectively. That’s one huge improvement in my opinion. However, I felt like we could still do better. Along with that, all the child classes created scored A and 0 minutes for maintainability.
WRITING THE UNIT TEST WITH QUICK & NIMBLE
We will be using Quick & Nimble for unit testing. First, we’ll mock our own data and not rely on the API call. We could do that as following:
Here we are creating our own version of mock data to determine the value of each key and we could pick our desired return value.
Next, once we have our mock data, we could test it accordingly. First, we will test if the phone is taken, we don’t allow the user to sign up. We could check that by selecting our checkNumberCase to return certain value that we need.