Intensive reading of "Thinking about Maintainability"

PS: All the intensive readings that are not linked to the original text are original, and this article is also original.

Before the front-end intensive reading, I wrote 23 design pattern summary articles, plus 6 design principles, opening and closing, single responsibility, dependency inversion, interface separation, Dimit's rule, and Richter substitution principle, which are basically maintainability of the code Have a comprehensive and profound understanding.

But you and I will always encounter bad code and large projects that are about to be unmaintainable in our work. Think about it, can these problems be solved by design patterns alone? Why is the ever-expanding large-scale project always becoming more and more difficult to maintain, and the more complex real world, but no one thinks it is about to collapse?

The design pattern considers the relationship between codes, and the design principle considers the relationship between modules and projects. Is there a higher level of thinking to solve the problem of increasing difficulty in maintaining large-scale projects?

intensive reading

First consider, why is there no maintainability problem in the real world?

Why there is no maintainability problem in the real world

This question seems a bit silly, because no one has ever complained that "our products, technologies, and concepts are too many, so much that I don't think I can live in this world anymore." But in the code world, programmers often complain that the concept of the project is too many and the design is too complicated that he can no longer maintain it. It is time to look for the next job.

An obvious explanation is that in life, we are all small characters. Living under our own sky does not need to touch so many concepts. Programmers basically play the role of God in the project and must worry about every detail.

But this does not completely make sense. We think that we don’t touch many things, but in fact we have too much knowledge of daily life. Take home appliances as an example. Everyone will be exposed to dozens of home appliances at the same time, ranging from air conditioners, refrigerators, washing machines, to cellphones, toothbrushes and chargers. These products are largely standardized, but each product has a lot of detailed differences in use, but no one feels that learning to use a new razor is a burden, nor does it feel that a poorly designed toothbrush will What is the negative impact on the entire toothbrush industry.

The reason behind this is: copy. Precisely because everything we use is a copy, it won't have any impact on other same items even if it is broken. But the code world is different, because of the existence of the code calling relationship, the more elegant the reuse, the greater the destructive power. A building can still be supported if a few pieces of steel bars are broken, but in the code world, as long as one piece of steel is broken, it means that all the steel bars of this building are broken. This is one of the problems that programmers hate most, that is why a change in a seemingly harmless code results in a malfunction.

From this perspective, the code world cannot absorb real-world experience. Moreover, this side effect of the code world has huge positive value in business, that is, the marginal cost of software is almost zero, which is impossible for physical products. Therefore, the software needs to pay the price of maintainability. It seems that this is the case. The price of extremely low marginal cost.

Although it is impossible to make one's own maintenance cost zero-hours by learning from the experience of the real world, the real world does have some lessons for the software world. Let's discuss some interesting points below.

The real world keeps shielding complexity

I don't know if you have ever thought about it like this: The interviewer always asks about the principle, but is worried that I can only use the framework and lack the foundation. But what is the basis? Knowing js, is java the foundation? It can also be said that it is not counted, because the compilation principle behind these languages seems to be the basis. There is an operating system behind the compilation principle. The operating system runs on the hardware, and the principle of the hardware? From the design of the CPU to how the silicon behind it is made, etc., it seems that the principle will never be grasped if this continues.

But when we derive from software to hardware, we can naturally find that no one thinks that mastering the production process of silicone is a must. We can always use products made of silicone, but we don't need to understand the principle of silicone production.

The real world always shields complexity. As consumers, the products we face are always carefully packaged and easy to use. Only when we work, we need to understand the principles of a certain professional field.

This principle can be transferred to the code world, that is, for a large and complex project, we cannot expect every developer to understand all the principles before it can work. We need to treat the developer as a consumer most of the time and provide exquisite and beautiful Stable interface. To do this, an architecture design similar to the following figure is required:

As can be seen from the figure, even if it is the business layer code, I don't need to care about the implementation of the bottom layer. The bottom layer code is like the compacted land under my feet, and I just need to walk on it.

However, the most frustrating thing is the following design:

In order to solve a problem, you need to face endless contexts, which is the main reason for the high maintenance cost.

Why do you think maintenance costs are high

As a developer, I have become accustomed to evaluating whether code maintenance costs are high or low. Today, let’s change our perspective and think about why you think maintenance costs are high.

The perception of maintenance costs is not entirely objective. I drew a four-quadrant diagram:

On the left is the part related to people, including your understanding of the code and familiarity with the project.

The stronger the understanding ability, the less likely it is to feel that the maintenance cost is high; the more familiar with the project, even the Shishan code, the maintainability will not improve after refactoring, because you will become unfamiliar with the project.

On the right is the part related to the project, including the complexity of the business itself and the quality of the technical abstraction behind it.

The more complex the business itself, the higher the maintenance cost. Because the amount of information will inevitably increase, we can never just stare at the Hello World Demo research framework; the code quality reflects the abstraction of the technology to the business, the abstraction is good, and the complexity The degree curve will be more suitable for the real complexity of the business, and the abstract is not good. Hello World Demo can also come in and drink a pot.

Among these four keywords, business complexity is almost unchangeable, and familiarity with the project also requires a process, so the focus should be on understanding and code quality.

Whether it is personal understanding or code quality, the goal is to help us understand the project quickly. That is to say, as long as I can quickly understand what the technical project is doing, how quickly I integrate, I will feel that the maintainability is high, and vice versa. Good maintenance.

Therefore, a simple project, or a large project with reasonable layering and clear documentation will make people feel that it is maintainable. At this point, the experience that needs to be learned from the real world is that even in the software world, not all the principles are understood. All the logic of the corners shows that the skills are superior. Working with this kind of thinking will only make everyone fall into endless Involution and understanding anxiety. We need to reduce the burden on everyone's thinking. Do not display modules and code designs that do not need to be understood. Set the minimum knowledge required for the development of each module to minimize the burden of understanding for developers.

Of course, I have to add that this does not mean that the developer’s growth and learning space is limited. Other knowledge opens the door at any time, but understanding that they are not necessary for daily development. This knowledge can be used as a document and can be discarded without becoming a long-term memory. . Speaking of this, it leads to the second interesting part of the real world, which is the manual.

Real-world instructions

It’s incredible when I think about it. No matter what you buy by courier, you can finally assemble it according to the instructions of the manual. After you install it, you can throw away the manual without any cognitive burden.

It's not so much that the instructions for express parcels are too complete, but it is better to say that the instructions are not perfect, and the goods that are not easy to use cannot be sold at all. We have long been accustomed to extremely easy-to-use products and detailed instructions. This is the result of the continuous development of business society and long-term gaming, and it will continue to be stable. Imagine that if the projects we participate in maintenance also have sophisticated designs and complete documentation, then maintenance will not be a problem, just follow the instructions step by step.

So why in most cases, the project we took over is like a Lego without instructions? This should be the essential difference between the product and the code, that is, whether the quality of the product is good or not, it is voted by the buyer with banknotes, and it is good to use, and the product with perfect instructions can survive, but the technical realization behind this is invisible. , And no one can vote. Even if the technical staff complains about the code that cannot be maintained, if the project achieves commercial success, it will only grow bigger and the technical debt will roll up.

The buyers of technical projects are programmers, but there is no way for programmers to refuse the visa, which leads to acceptance regardless of the quality of the project. Without the function of market mechanism, bad code can be seen everywhere.

To solve this problem, we must first be aware of this problem, that is, the quality of technical projects is essentially something that nobody cares about for a long time and continuously. You might say that technical leaders care about it? But this is too weak compared to business drivers. The product has user-side banknote voting. No matter how many people are changed by the manager, it will continue to provide motivation from the source, but the quality of the project always has to be repeatedly emphasized, intermittent rectification, and different Leaders care about differently, because there is no source behind this. Motivation, unless the quality of the project affects the user's cash supply, but when this happens, it means that the project has already sucked.

It is precisely because the quality of the technology lacks the source power, or the source power transmission link is too long, we need to constantly strengthen the attention artificially, pay attention to the documentation, pay attention to the use experience, and pay attention to whether it conforms to the design mode. Only long-termists can insist on code quality governance, because they firmly believe that one day, code quality will affect business development.

Summarize

This time we borrowed some experience from the real world to the software world. From the shielding complexity of the real world, we talked about why the real world manual is so easy to use, but the technical project documentation always lacks arms and legs.

The experience we have summarized is that design principles and design patterns can certainly improve maintainability, but in the final analysis it is a problem of motivation. Improving code quality itself is a thing that lacks motivation to do, or is considered an important and not urgent thing for a long time. It’s often difficult to find a reason to do it now, but no one thinks it shouldn’t be done.

Therefore, if you want to improve maintainability, find out why you need to do technical optimization now, immediately, and start optimization immediately.

The discussion address is: Intensive Reading of "Thinking about Maintainability" · Issue #359 · dt-fe/weekly

If you want to participate in the discussion, please click here , there are new topics every week, weekend or Monday release. Front-end intensive reading-to help you filter reliable content.

Follow front-end intensive reading WeChat public

Copyright notice: Freely reprinted-non-commercial-non-derivative-keep the signature ( Creative Commons 3.0 License )