Refactoring Was Totally Worth It

Refactoring makes my next step easier

This week task is refactoring of my OpenSSG code. However, I refactored most parts of my code two weeks ago. Now I don't see much to improve to my knowledge. I have a huge interest in refactoring since I read the book Clean Code. I saw the beauty of breaking down the code in a manageable way, better naming for anybody to understand the code more easily, and create a function to reduce errors and to find errors in unit tests. Since I had a co-op, I realized the importance of refactoring more. I probably have to read Clean Code again to learn things that I forgot now.

Send an object instead of passing multiple arguments

It's not easy to find out where and how to refactor code while I'm implementing a feature. But I knew something was not right and error-prone when I tested my OpenSSG. First problem was the too many overloading functions. They were doing almost similar jobs. Only optional tasks were different. When I fix one place, I had to carefully find all the places to add the same fix. It's very likely to make a mistake and time-consuming to find where I miss. I remember one article explaining refactoring. One of the strategy is to pass arguments as one object. So I created Options class, and it solved a lot of my problems. I opened same files on the editor at the same time to add refactored codes while still keeping the old ones. So, I didn't know how much I could reduce my huge FileUtilities class by introducing Options class. Once I ensured new code worked fine, I happily removed my overloading functions. I could see this process reduced a lot of code that was giving much headache.

Hide detailed logic inside function and give a function a good name

Then, I looked through the whole files where I could make functions so that it can be more readable and manageable. I made arArgsValid(String[]) function to contain all logics to check whether correct options are provided. And I tried to create more checking functions like hasTitile(String[]). I think boolean returning functions look clearer when we hide the logic inside and show a good function title. Also, I tried to cut out some of parsing logics outside of FileUtilities, then I named it Parser class. I cut anything that didn't do file writing in FileUtilities, and moved it to Parser class. This also reduced a lot of code. And my code looks much better. And each file size is closer.

❯ wc -l src/*                                                                                                                                                                                                ─╯
     227 src/FileUtilities.java
     168 src/OpenSSG.java
      70 src/Options.java
      90 src/Parser.java
       6 src/Release.java
     561 total

Continuous journey to better refactoring

Lastly, I checked all my variables to see if anything is ambiguous or mis-understandable. I usually try to name it right. But when I change my code all over and test it constantly, I put aside renaming work for later. Now I'm pretty satisfied although I still have a thinking that I should create more functions or not. I don't have a clear answer now. I should continue reading more codes and books to do refactoring better.