Refactoring- what is it and when do you need it?

Question 1. What is refactoring ?

Code refactoring is the process of restructuring existing computer code - a change in factoring - without changing its external behavior. Refactoring improves non-functional software attributes . Advantages include better code readability and reduced complexity , they can improve source code maintenance and create a more pronounced internal architecture or object model to improve extensibility.                                    

This time we will try to skip the "boring" technical issues and focus on what companies really need.

In a more mundane language, refactoring is the process of reorganizing the code base without introducing new functions.

So what ? Basically, you want to do something with the code (which is not a spectator-ish ) and spend time programming in WITHOUT adding new features? You're joking right?   

We will answer this question a little later.

Question 2. How do I know if my application needs refactoring?

There are three main reasons for refactoring :

1. Code architecture is poor. This happens when the application is delivered as quickly as possible, and the developers and product owner do not care about the integrity and ease of maintenance of the solution. The situation may get worse if the scope of the project has changed significantly or there were several dozen freelancers who worked on the solution at different times (without convention, code style, etc.)   
2. The project did not confirm that the concept was correct. It's no secret that some projects are successful and some fail. Smart product owners must ensure that key functions operate as intended and can be demonstrated to investors and stakeholders. Or, like product companies, they verify their ideas in narrow focus groups. In any case, they allocate limited resources to see if the idea or approach really works in the real world. As soon as the answer "yes - it works " , you should plan a budget for the following tasks and (this is an important element) to actually plan or adapt the architecture of the solution. Otherwise, you can build a tower block on shifting sands.      
3. Technology stack is outdated. This is also happening. Technologies evolve quickly, companies need cross-platform solutions, mobile adaptation, etc. Go to the 1999 website and try to add the fancy ReactJS interactivity to it . You can try to make it work, but in principle the expected result cannot be justified by the amount of time.   

When this every message comes from the development company, it is a reason to cry , right?

Well ... yes and no.

You can ignore this information, skip the audit code to another company and just go to the current approach.

Here is a list of possible problems you may encounter:

1. The application is incorrect. Over time, some errors are resolved to replace them with new ones. Why? Because programmers fix problems, but only then it becomes apparent that they have broken something else. The larger the application, the more lines of code, the more intersections, the more unconventional solutions and ... the worse the situation is usually.     
2. The application is slow. By introducing new functionality you are inevitably adding code. When you add more data to the DB, you increase the size. So, in the early stages, server or client side performance issues may not be visible. But over time, they can become quite obvious.      
3. Development takes too long, even with simple functions. This is related to the previous point. To provide a stable product, the programmer must solve problems beyond his scope, basically refactoring, while providing this function. It works, but there is no systematic approach. And it is not clear for your from the position of person who is paying small bills, right?        
4. Some functions will not be completed. Again, referring to both of the above. Introducing a new component or function may simply not be worth the effort. Imagine getting an estimate that says it will take two full days to create a simple drop-down menu . A software development company usually says "you don't need" or something like that.      

Question 3. What is the expected result?

Benefits with the right above refactoring’s are directly related to the problems that are going to solve:

• Easier system expansion
• Better cooperation of programmers
• Less time for discussions, more time for good solutions
• Saved money
• Easier implementation of changes
• Fewer mistakes
• Less Q & A
• Better client-side application performance 
• Happy customers
• Better server-side performance
• Cheaper AWS plan
• Less money spent on support and development in the future

The list goes on . Basically, you'll be able to solve most, if not all , of the problems listed above.

Question 4. How much does it cost?

Short answer - it depends.

The longer version sounds - from 100 hours to 2000+ .

Small projects can take 50-150 hours to update the stack technology.

Larger projects with changes in backend and frontend can easily take 500h +.

Small projects may also take 10-15 hours, only because we have to get rid of sub-optimal solutions and move forward, evolve and raise funds.

It is important to properly inform programmers about their plans - close and distant. This is the most important thing from the very beginning. Sometimes (quite often) it makes sense to combine refactoring and implementation of new functions when you are sure that the older functionality will change soon.  

If in doubt, you can order a code audit of another proven company. They are not cheap, but they can be completely justified when we talk about ranges over 1000 hours. 

Question 5. How to avoid refactoring? 

Rule 1. Find the right people . A development company should be professional, transparent and have a good reputation.   

Rule 2. Express your wishes. Understanding your dream in all its glory and giving it to the SRS can be difficult. Read how SCRUM works and what the product owner does.    

Principle 3. Specify your target group, stakeholders, plans for the future. The more detailed the image, the less space on false assumptions and the greater the chance of meeting expectations.    

Rule 4. Inform the development company when there will be a significant change in the roles in the project, high probability of changing the approach or cancelling the scope. Remember that we run a project and it should perfectly match the product - you are the person who knows it best.    

Rule 5. Do not put the quality assurance "when the time comes." The cumulative problems are more difficult to fix. In addition, their solution will take some time (and money), and you basically will not receive new features at this time. After all, you pay for what you already thought was resolved. You are getting frustrated , and the recipient has the gap in subsequent editions / versions.     

Rule 6. Plan ahead. At some point you will need to adapt mobile (very likely) l last few in applications and user roles. Try to imagine what this ultimately looks like, and then transfer your vision to the right people. This enables effective architecture planning and the selection of the right technological station .     

Ok, you already have complete information. Refactoring is necessary.

Bad news: A new investment is needed, sometimes (often) unplanned.  

Good news: You product will be better for a lot of levels . I hope you'll see it now.   

Tip - don't treat it as an expense. It's a wise investment. If you decide otherwise, you may pay twice more later, or worse - get stuck in a dead alley with wrong code. Contact us in case you need more details on refactoring!