Code refactoring in combat experience and those pits

Why do we feel the need to rewrite the software from scratch?

When we first wrote the system code, we had a very tight schedule, and we had to race against time to finish the schedule within the planned time. So neither the design discussion nor the Review Conference took too long--we didn't have time to waste it--we had to go through a function, a quick test, and then rush to the next. We shared office space with other companies, and I remember that software development in other companies took a long time to design, discuss architecture, and spend weeks discussing design models.

In addition to the hasty design, the original system is not poorly written, the overall structure is also good. Some of these spaghetti-style codes were left behind when the company did proof-of-concept, because the code worked, and the duration was tense, and we didn't touch it. But then we did not consider the optimization improvements, but decided to rewrite the code from scratch because:

• Old code is bad and difficult to maintain;

• "Single monolithic Java architecture" is not conducive to our future development, can not support 60 million mobile users and multi-site deployment of large operators;

• I want to try cool new technologies like Apache Cassandra, virtualization Technology, binary protocols, SOA, and more.

The result was unfortunate: we persuaded the entire company and the board to fulfill our aspirations.

Code Rewriting Tour

The formal development time starts in the spring of 2012, and we set the end of January 2013 as the release time. Because the plan was too big, we needed more people, so we hired consultants and a few remote developers in India. However, we do not fully anticipate the parallel workload of maintaining the original system, doing new development work, and understanding customer needs.

Remember what I said at the beginning of the article, do we have a real customer? This customer is one of the largest mobile operators in South America. After the systems we developed were put into use, they began to ask for changes and new features, so we could only continue to update the original system. However, as this system will be discarded, we are always a bit perfunctory in the update, as far as possible to find excuses to reject the customer many of the new functional requirements. The results resulted in delays in the schedule and failed to complete the scheduled deadline. In fact, our progress has been delayed for a full 8 months.

But let's talk about the results first: When the project is finally finished, the new system looks great and meets all the requirements. We did the load test, and the results showed that the new system could easily support more than 100 million users, the configuration set, the UI tools for viewing the chart, and it was time to discard the old system and change the new system ...

But the customer rejected the upgrade request: The original system has been widely used, their users have started to rely on the old system, they do not want to risk. Long story short, after a few months of wasting, we have little effect. The project was formally declared unsuccessful.

The experience we have learned

• In most cases, you shouldn't rewrite the code from scratch. The reason we rewrite the code is wrong, although some of the code is not good, if we take some time to read and understand the source code, we can reconstruct the problem by refactoring. The scalability and performance of the architecture we do have concerns about the inability to support complex business logic, but it's quite possible to fix it incrementally.

• Rewriting the system from scratch is of no value to the user. New technologies and buzzwords may seem cool to the team of engineers, but it doesn't make sense if they don't offer new functionality in accordance with customer needs.

• We missed the real opportunity when we focused on rewriting the code. Previously we provided a very basic site Analysis tool (Web tool) for customers to view charts and reports. But as the content grows, they begin to demand new features such as real-time charts, access levels, and more. As we do not intend to continue to use the old code, the time is not enough, we have to either reject the new demand, or make a mess. As a result, customers no longer use the tool, they insist on sending the report via email. We had another opportunity to build a robust analytics platform with urgent needs.

• I underestimated the amount of work required to develop a new system while maintaining the old system. We had expected to have 3 to 5 requests in one months, and the result was three times times the expected number.

• We thought: because it didn't take days to discuss the right design models and examples, the code would be difficult to read and maintain, and in fact the most professional code I've ever seen in a larger company is twice times worse than our code. Therefore, we are wrong at this point.

When to rewrite code

Joel Spolsky is strongly opposed to rewriting the code, and he advises everyone not to do so. But I'm not particularly agreeable: sometimes it's very difficult to gradually optimize and refactor, and the only way to read code is to rewrite it. In addition, software developers like to write code, create new things-read the code written by others, try to understand their code and "thinking abstraction" will be very boring. However, good programmers are also good maintainers.

If you want to rewrite the code, be sure to do it for the right reason and with the right plan. Like what:

• Sometimes after a long release of the new version, the old code still needs to be maintained, and maintaining two versions of the code requires a lot of work, and the time and resources needed to assess the project size before starting the rewrite.

• Think of other lost opportunities and compare tasks to priorities.

• Overriding large systems is more risky than small systems, and consider whether you can rewrite them incrementally. We did the following things: switching to a new database, using the SOA architecture, and replacing it with a binary protocol could actually be implemented incrementally.

• Consider the developer bias. When developers want to learn new technologies or languages, they will want to use them to rewrite some code. But I am not against it, which is a sign of good environment and culture, but it should be compared with risk and opportunity.

Michael Meadows has a good idea of when a "big" rewrite is needed:

Technically,

• Components are highly coupled and cannot be modified individually for a component. Re-designing a single component can result in a series of changes that affect not only neighboring components, but even all components indirectly.

• The technology stack is too complex, and the future state design needs to change a lot of infrastructure. For this reason, it is necessary to perform a full rewrite, and the gradual redesign does not have an advantage in this case.

• Redesign a single component will result in an override of that component in any case, and there is no place in the existing design where new functionality can be inserted. In this case the gradual redesign has no advantage.

Policy on

• Sponsors cannot understand that a gradual redesign requires a long-term commitment to the project. Inevitably, most companies are not interested in continuing to spend their budget on gradual redesign. This is also hard to avoid when completely rewriting code, but sponsors are more willing to keep investing because they don't want to use the new system with semi-finished products and some obsolete old systems.

• System users are more accustomed to using the "original interface": In this case, the policy will not allow the modification of the important part of the system (frontend). But if you rewrite it completely from scratch, you'll get around this problem. Users will also insist on using the same interface, but this time you have more reason to fight back. Remember: The overall cost of a gradual redesign is always higher than the full rewrite code, but it generally has a smaller impact on the enterprise. In my opinion, if the reason for rewriting is sufficient and the company has a super-good developer, let's start.

It's dangerous to abandon a project you're developing: Wasting a lot of time and money repeatedly implementing existing functionality while also giving up the opportunity to implement new features, potentially angering customers and causing work plans to be postponed. If you're rewriting the code, that's your power, but make sure you're doing it right, and that you know the risks and you have a plan.

Original link: http://www.colotu.com/html/gcs/49.html

Code refactoring in combat experience and those pits