There have been a scenario whereby clients come with an existing source code for refactoring because it has lots of bugs and it’s not running efficiently, a situation whereby the client decides to change the team of software developers, or probably the clients has a request of adding some features or needs some tweaking on his/her website/app.
There could be a dilemma whereby the new agency or developer will have to reason whether or not to use refactor techniques or rewrite the codes. Both ways seem possible and all have proven to be the best possible way out on different occasion. Now, here is the question, in which situation can a developer or agency decide if to refactor or rewrite codes? This is because it could be catastrophic when a developer decided to refactor the code whereas it is better to rewrite the application and vice versa.
Here in this article, we will discuss in brief, a circumstance to decide when to refactor or rewrite your codes. Follow me down as we look at both scenarios.
Rewriting Application:
It is common with developers to decide writing the codes from scratch as some believe writing is easier than reading codes. They could come up with reasons why they chose to rewrite which is actually reasonable.
These reasons could be:
-
they can’t understand the codes
-
debugging is becoming more challenging
-
new codes can fix current issues etc.
When choosing to rewrite codes from scratch, you need to consider some factors: Time factor: It is obvious it will take you much more time than it took the first developer considering that you have lots more information. This could bring dissatisfaction from the client point of view and the users.
- Time factor: It is obvious it will take you much more time than it took the first developer considering that you have lots more information. This could bring dissatisfaction from the client point of view and the users.
- New innovation: While you are spending more time rebuilding the app, new innovations are coming up and client competitors are pushing to meet up. This could result in the clients losing users.
- Customers satisfaction: This can resort to the users being frustrated. Existing users will prefer upgrade or add new features. Your user’s satisfaction needs to come first when starting up a business and anything that will alter that should be avoided.
What is Refactoring
Code refactoring techniques is simply the methodology of restructuring existing code without changing the core functionality of the application. Often time majority of issues or bugs can be fixed by simply adding small changes. It is usually difficult to work on someone’s code but that doesn’t make it impossible. Refactoring code often takes more time but it helps you be in check and keep your users anticipating for upgrades, it reduces the rate of frustration on the user’s side. This shows that the risk of losing your users is low. It helps you get feedback and work on them gradually.
Here in Sloboda Studio, we had two scenarios where our clients who happen to be startups came to us with an existing source code to refactor. We had the opportunity to rewrite application but we chose to look deep into the code and we resort to refactoring the code. This made us achieve great results.
Here are code refactoring examples and scenario:
* First was CityFalcon, it is a financial news aggregator which provides a comprehensive, relevant, personalized and real-time news feed for fundamental investors, powered by crowd-curation, social media, and machine learning.
This project came to us with an existing MVP which was done by the founder as he has some experience in Ruby on Rails after having a 3-month course on Ruby. As I’ve mentioned earlier, some developers would have preferred to start from the scratch but we took the advantage of what has been written to get more insight about the app.
This was an innovative product, possesses many challenges, requires flexibility and super efficient solutions. We had to master all the intricacies of FinTech field within the shortest possible time to better understand the nature of the project and avoid unnecessary amendments in the future. For us, it was crucial to get ourselves adapted to the business processes of the client, providing full – scale support to CityFalcon, concentrating not only on the ongoing task but on the entire product.
We use Agile methodology practices to ensure timely and efficient implementation of the project’s features. Prior to starting the project, we knew we will face scaling issues because it was an already built MVP. As soon as the first user appeared, the number of records in DB increased a hundredfold, and many shortcomings of the old Frontend became obvious combined with the Backend.
We tried to eliminate the scaling problems by adding several servers to the DB, reducing the burden on the main server. We also reduced the time for requests processing and the number of requests added caching of the most frequently used data, and used a load balancer for the web-servers. We took measures to filter spam bots and block useless crawlers. Another solution that helped us avoid scaling issues was splitting the application into separate components.
* The second scenario was Aquinium, an online environment filled with intelligence games for people to train and sharpen their cognitive skills and also a powerful tool that helps gather scientific data in a controlled environment to facilitate research on individual magnitude estimation, the wisdom of crowds, and decision-making processes relating to trade on beliefs.
We started the project with semi-finished MVP that was built by the client and we had to refactor the code substantially. Our first challenge was to make the system more flexible and stable in terms of loading and we achieve that by writing reliable scoring algorithms, paying attentions to proper input and output data analysis. We needed to manipulate the data between the users and store statistics according to data selected by users. We achieved that by implementing WebSockets technology and use it in each game room by creating a channel for each pair of users and trigger actions according to the data they send. This approach proved itself to be much more effective than the alternatives, like long-polling.
Another huge challenge we faced was to make the application as scalable as possible to maintain at least 500 game rooms which result in 1000 players online, playing simultaneously and hitch free. While we were studying the app, we noticed that it requires proper and complex DB structure for storing relations between users and computer users, games statistics and for making analysis and results in export as simple as possible. Therefore, we produced a highly organized DB with complex relations and dependencies.
There are instances when one can be faced with the option of refactoring of codes rather than rewriting the code. This could be as a result of technical debt or legacy code.
Technical debt is the extra development process that comes when code that was implemented for a short run is being used instead of using the best and accurate solution. In the situation whereby you have a design but will take you more time to implement, releasing such code quick is like incurring debt and as such you will only be left with the choice of refactoring rather than rewriting the codes. This shows that refactoring of code lowers the technical debt and can increase performance.
Legacy code is often called old code that can be rewritten using better programming techniques or languages. It is usually not easy to rewrite because of dependencies on that code. Refactoring legacy code should be done as a step by step activity within a longer period of time.
We at Sloboda Studio see refactoring as a viable option though we could in some instances rewrite the codes. Before making a decision to as which path to take (rewriting or refactoring), we weigh our options and go for the best. We are experts that are capable of identifying which is the best at a given point.
