00 Preface Business Code Will There Be So Many Pits #

Let me first tell you about my 15 years of work experience to deepen our understanding of each other. During the first 7 years, I focused on the .NET field, where I not only worked on business projects but also did a lot of community work. While serving as a moderator on CSDN, I answered a lot of questions about .NET and summarized the answers to many of these questions in my blog, earning me the recognition of being a Microsoft MVP three times.

Later on, I switched to the Java field and transitioned from a programmer to an architect. I became more interested in open-source projects and internet architecture design. At AirMedia, I was responsible for the overall architecture design of the technical platform for the large-scale MMO online game “Ji Zhan,” which had millions of players online. During this time, my team and I developed many Java frameworks with good performance and stability. At Ele.me, I was in charge of the development management and architecture work for a logistics platform that processes millions of orders daily. I encountered many issues that only occur in high-concurrency scenarios, which allowed me to accumulate a wealth of architectural experience. Currently, I am a member of the infrastructure team at Beike Financial Services, where I am responsible for the development planning of basic components, middleware, and basic services. I also establish processes and standards and lead the team in developing a self-developed Java backend development framework and a microservices governance platform. In the process of implementing the Spring Cloud combined with Kubernetes container cloud platform technology system, we have explored many basic components and best practices that are suitable for our company’s projects.

Over these 15 years, I have never stopped coding and have been involved in projects of all sizes, totaling more than 400. I have encountered countless pitfalls, either through personal experience or through observing others. One thing that struck me deeply is that there are indeed too many pitfalls in business code. Some pitfalls may seem like very simple knowledge points but are surprisingly easy to fall into, such as the issue of Spring declarative transaction not taking effect. Other pitfalls, due to their long “incubation period,” have caused significant manpower and financial losses when they lead to online incidents. As a result, I have systematically collected and organized these cases and pitfalls, and finally selected 100 cases, covering more than 130 pitfalls, to form this course.

Not being aware of the pitfalls in business code is very dangerous #

You may ask yourself, “I have been writing business code for years. Whenever I encounter a problem, I just search the internet and find the answer. The most common problem I face is unstable servers, which can usually be resolved by restarting. How can there be so many pitfalls?” With this question in mind, let me continue.

From my observation, many developers are not aware of these pitfalls, and there are three possible reasons for this:

1. Not being aware of the existence of pitfalls: For example, the so-called server instability is often caused by code issues. Many times, problems like Out of Memory (OOM), deadlock, and timeout can be solved at the operational level by changing configurations, restarting, or scaling up. However, they are often not traced back to the development side to find the root cause.

2. Some problems only manifest under specific conditions: For example, cache breakdown or using non-thread-safe classes in a multi-threaded environment will only expose problems in situations with multiple threads or high concurrency.

3. Some performance issues do not cause obvious bugs but instead slow down program execution and increase memory usage. However, they may suddenly erupt when there is a significant change in quantity.

Because developers are not aware of these pitfalls and issues, they adopt incorrect handling methods. Once the problems erupt, they become very difficult to deal with, which is extremely dangerous. Do any of the following scenarios sound familiar to you?

For example, I once heard about a project with a large number of orders. Every day, there were thousands of orders with incorrect statuses or processes, requiring a significant amount of time to reconcile data and repair order statuses. The developers were so busy investigating the problems that they had no time to develop new requirements. The technical leader was at a loss and eventually had to hire dedicated technical support personnel. In the end, after much pain, they decided to enable detailed logs to investigate the problem thoroughly. They discovered that a self-invoked method caused the transaction to not take effect, leading to the problem.

Another example is a friend who told me about their financial project. The code for calculating interest used float types instead of BigDecimal types to store and calculate amounts, resulting in a few extra cents being added to each interest settlement for users. Luckily, the problem was discovered promptly during the day-end reconciliation. Imagine if there were thousands of users with thousands of small orders to settle. If the problem had only been found during the month-end reconciliation, they could have lost millions.

Yet another example is using RabbitMQ for asynchronous processing. Messages that failed to be processed would continuously cycle through the MQ. Before the problem erupted, it might only affect the timeliness of message processing. However, when the MQ eventually became paralyzed, you would be faced with millions of messages in the MQ, with both dead and normal messages mixed together. Besides clearing the MQ, what else could you do? But clearing the MQ means spending several hours or even dozens of hours to correct the normal business data. This has a long-lasting impact on the business.

Incidents like significant accidents caused by a small pitfall not only cause losses to the company but also affect work performance due to self-blame and reduce confidence in coding. I once encountered a responsible core developer who resigned because a bug caused tens of thousands of dollars in economic losses to the company, and he couldn’t bear the psychological burden.

In fact, many times it’s not that we don’t want to solve the problem at its root, but rather we don’t know where the problem lies. To avoid these pitfalls and find these time bombs, the first step is to know what they are, where they are, and why they occur. Explaining these pitfalls and related best practices is the main focus of this course.

What is this course? #

If I were to sum up this course in a few keywords, I would choose “Java,” “Business Development,” and “Avoiding 100 Pitfalls.” Now let me explain in detail what this course is and its features.

The first keyword is “Java,” which means that all the demos in the course are based on the Java language.

If you are familiar with Java, you can fully understand these pitfalls and use the demos to check if your business code has similar implementation errors.

If you are not familiar with Java, it’s not a big problem. Most advanced languages have similar features and structures, and many problems are common. In addition, the content of the “Design” and “Security” sections is basically high-level, language-independent issues. Therefore, even if you don’t use Java, you can still gain a lot from this course, which is the first feature of this course.

I want to point out that this course is centered around pitfalls rather than a systematic study of the Java language, so it is not a comprehensive Java textbook.

The second keyword is “Business Development,” which means that the course content is limited to the development of business projects and focuses on the pitfalls that may be encountered during business project development.

Let’s first look at the word “business.” Those who have been doing business development for a long time know that business projects have two characteristics:

• Tight deadlines and complex logic. Developers tend to focus more on implementing the main process logic correctly, neglecting non-main process logic or the implementation of guarantee, compensation, and consistency logic.

• Lack of detailed design, monitoring, and capacity planning feedback loop, resulting in various accidents as the business grows.

Based on these characteristics, I have summarized nearly 30 aspects of content to cover key issues in business project development. The comprehensiveness of the cases is the second major feature of this course.

These cases can be viewed as a comprehensive guide to pitfalls in Java business code, helping you write better code and gain more confidence for interviews. You can even use the subdirectories as a checklist for code reviews, helping business projects grow and avoid pitfalls.

Now let’s look at the word “development.” In order to be more focused and targeted, I have limited the content of this column to business development and will not discuss issues related to architecture, testing, deployment, and operation and maintenance in too much detail. The “Design” section focuses on pitfalls in architectural design and does not fully and comprehensively introduce architecture factors such as high availability, high concurrency, and scalability.

The third keyword is “Avoiding 100 Pitfalls.” A “pitfall” refers to common mistakes, and “avoiding pitfalls” refers to analyzing the root causes of stepping on those pitfalls and avoiding stepping on the same ones again.

The entire course consists of 30 articles, covering 100 cases and about 130 pitfalls. Among them, 40% are from over 200 production accidents that I have experienced or observed, and the remaining 60% are from developing business projects and discovering issues during code reviews. This course aims to stay close to reality and does not discuss outdated or rarely used technologies or frameworks, which is the third major feature of this course.

For most cases, I will provide an executable demo that demonstrates both the erroneous and corrected implementations. The demos are complete and continuous, helping you learn the essentials. This is the fourth major feature of this course.

Complete and continuous, understanding the reasons behind it. I will explain each case using the following structure: “Introduction to knowledge -> Restoring the business scenario -> Erroneous implementation -> Correct implementation -> Principle analysis -> Brief summary.” For each pitfall, I will provide at least one solution and select key points to analyze the source code. This way, you can not only avoid pitfalls but also understand the underlying causes, improving your technical skills.

This course aims to teach you how to fish. When encountering a problem, we usually use our experience and tools to locate and analyze the problem before identifying the pitfall. We don’t know the reason from the beginning. In this course, I will try to present the process of analyzing problems as completely as possible, rather than directly telling you the reason. This way, you will have a problem-solving approach when you encounter issues in the future.

This is also why, although there are many materials on the internet about Java code pitfalls, many students have told me that they didn’t have a deep impression after reading them and ended up stepping on the same pitfall again because they didn’t fully grasp it. Therefore, I will also share some best practices that I have sorted out based on years of experience and thinking.

After reading this, I’m sure you can’t wait to see what pitfalls are covered in this column. Take a look at the mind map below:

Given the content and features of this column, let me share with you the best way to learn.

The best way to study a course #

We all know that programming is a practical science. Just reading without practice or reflection usually doesn’t yield good results. Therefore, I suggest that after opening each article, you should study in-depth in the following ways:

For each pitfall, run and debug the source code, and reproduce the problem using the tools and methods mentioned in the article. Seeing is believing.

For each pitfall, consider whether there are other ways to fix it besides the solutions and approaches mentioned in the article.

For the root causes of the pitfalls involving JDK or framework source code analysis, you can find the relevant classes and read the source code systematically.

Reflect on the practice exercises. Some of these exercises are supplements to the article content, while others are additional pitfalls that are easy to encounter.

Once you have understood all the examples covered in the course, you should be familiar with most of the common mistakes in business code. Not only can you write higher quality business code yourself, but you can also identify potential problems when reviewing others’ code, and help the whole team grow.

Of course, what you gain from this course will not be just the methods to solve the problems in the examples. It will also improve your ability to analyze and locate problems, as well as your ability to read source code. When you encounter other tricky pitfalls, you will have a clear solution in mind and can grow into a firefighting expert, helping everyone locate and analyze problems together.

Well, that’s all I wanted to share with you today. Please quickly follow our course and start the journey of avoiding pitfalls. Feel free to leave a comment about your situation and share the pitfalls you have encountered and any difficulties in writing business code. See you in the next lesson!