Value-Oriented Programming: The Road to Coding Quality Over the Years

This article was first published on Mooring Nuggets : https://juejin.cn/user/1468603264665335

Version	date	Remark
1.0	2022.8.3	Article first published
1.1	2022.8.10	Improve content based on feedback
1.2	2022.9.11	Edit title

0. Preface

I have recently taken on several projects, and the quality of the code is uneven. I wanted to do a review of each patch according to past practice, but often the dead line was the first. I will think, if I do a review of this patch, and what value it can bring to the business in the long run. Following this article, I would like to discuss other techniques that can clearly bring value in coding as well.

Note that the value here refers to a quantifiable value. A common argument may be that it is beneficial to the long-term maintainability and stability of the system, but relevant indicators cannot be given. But we need to know, 数据思维要优于经验沉淀 .

1. The period matters

Periods are very important. According to different periods, we will choose different lives and choose different investment strategies. The same is true of technology. I listened to Wang Zhimeng's sharing before and gave a very down-to-earth technology development stage:

• can be used
• easy to use
• excellence

It is best to pursue speed until the business model or business value is proven. It's like you go hunting on a hungry stomach. You don't care how beautiful the weapon is, but whether it can help you hit the prey and avoid starvation. This is the usable stage.

CodeReviews tend to happen at the stage of usability and excellence. At this time, the value of the project has been verified, and further iterations need to be coordinated with business development. It can also be broken down here:

• Ease of use means that it fully meets business needs.
• Excellence is the ability to use less cost on the basis of fully meeting business needs. Be at the top of the industry from both a business and a technical point of view.

The value of CodeReview starts from being easy to use. At this time, we often focus on how to stabilize the iterative business. In the period of excellence, CodeReview is even more important - the business carried at this time is often bulky, and more attention needs to be paid to the stability and continuity of the business; at the same time, the scale of the team is also expanding, and further attention needs to be paid to reducing costs and increasing efficiency.

2. The Double-Edged Sword of CodeReview

I have participated in many CodeReviews myself, and each patch in ZStack can only be merged into the trunk after finding the corresponding maintainer review, and the overall review granularity is also very fine. Personally, many of my Coding skills were learned or inspired at that time. But this has a certain cost - let me give an example: for example, a function has been developed for 3 days, and the test has been tested for 3 days. Now the trunk is merged, the maintaner watched it for half an hour, and raised 10 comments. Improve. Then the development needs to be modified and tested (it took 1 day), and tested again with the test (the test took 2 days), and finally the main trunk is merged, then there are 3 more man-days than the original 6 man-days, 50 man-days. % man-day growth.

Maybe we can be smart and create a develop branch: then we will develop and submit the code, review it again, modify it and test it ourselves, and then submit it for integration and hand it over to the test. But in general, it still brings "additional costs" for research and development, the maintaner is often the main role of the business, and his time is also precious.

In Woqu, when the project iteration was hot, there were more than 10 patches that needed me to review a day, so I reviewed all day, and then slowly dismantled different projects and modules to different leaders, and the situation was better. .

Let's say you're considering introducing CodeReview, and you're in the process of using it well. Then I think the first thing to do is to reach a consensus with the upper management on how to calculate the cost of this additional labor cost. At ZStack CodeReview was directly promoted by CEO Zhang Xin, so I don't know how to explicitly quantify the value brought by CodeReview at that time. However, as far as I know, some major manufacturers have corresponding R&D efficiency insight platforms, and will measure R&D efficiency based on a large number of indicators. The indicators obtained by related methods in this article may only be a drop in the bucket. Considering the control space, we will not expand further. .

As for the practical rules introduced in CodeReview, I think the focus is on macro design. For example, if we write a complex business platform instead of a simple CRUD business (such as a library lending system), and use a "classic" three-tier architecture, then no matter how well your code details are standardized (reduce if else tricks, no more than x lines per function, etc.) end up being hard to iterate. And when we borrow the idea of clean architecture - whether it is DDD or hexagonal architecture or SOLID, design patterns, classic programming ideas, we will find that it is more important to keep the macro clean than the bad little details of.

Sadly, many automated inspection tools focus on micro-details, and very few tools can focus on macro-cleanliness. It is understandable that different projects have different requirements for macro cleanliness, and it is difficult to adjust.

Example: Our dwellings tend to have defined areas, with utensils in the kitchen and beds in the bedroom. Even if the pot or spatula in the kitchen is a bit messy, it's not unacceptable - this is macro neatness and microscopic bad; and if we have a clean sheet in the kitchen and a pot in the bedroom, No matter how neat they are placed, it violates the neatness of the macro, even though they are neat at the micro level.

Another simple brute force method is the coverage of white box testing, especially unit testing. Code that can easily write unit tests is relatively loosely coupled, so it is a good choice to use the coverage of white-box tests as the focus of the review.

3. If you don't write code, you can stop Reviewing

As the subtitle said, since reviewing the code is so expensive, don't write the code at all. For example we can use DSL.

This approach is actually very common. Anyone who has done big data knows MapReduce or Strom. When writing them, you need to pay attention to a lot of details, such as how to shuffle the data and how to ensure reliability. Today, with FlinkSQL, we don't need to pay attention to these underlying details at all. We only need to pay attention to where the data comes from, how to do business processing, and then where to go. This is the cliché of declarative programming, not procedural programming.

The same idea is also reflected in the declarative API of K8S. Write the configuration statement and submit it, and it will be finished when the resource is created. If you create a set of resources, you need to call them in sequence according to their dependencies, and pay attention to the state details inside. This ease of use is obviously much worse - just like OpenStack, you have to prepare a series of things before you create a VM. it is good.

The low-code platform is also the same idea. The UI-related code is formed by dragging and dropping customs, and some simple logic can even be defined in it. The code formed in this way naturally does not need to be reviewed, and the optimization is also done by the code interpreter in the low-code platform.

Considering the business value in this way, it is actually very obvious: it may take only 10 minutes for an ordinary developer to write a piece of SQL, while it may take half an hour to write a corresponding data processing task in code.

4. Writing good code is not for nothing

Having said that, the pursuit of completely clean and tidy code may seem less important to the business. From a business perspective, it is. However, there are always some core codes, often used libraries and frameworks that require clean code and API design. They are often located at the bottom of the project, but silently support the business developed on it. This requires CleanCode, even if one less parameter is passed, one line of code is less, and all users are benefited - this value is often reflected in reducing costs.

5. Summary

This article discusses the author's journey in coding quality, and analyzes the introduction time and key concerns for CodeReview. And pointed out that declarative programming, which is easier to quantify the value of, is a good choice.

For the vast majority of business codes, the degree of CodeReview needs to be weighed according to the period. The business carried on it is like a weapon when we go out hunting, and the commercial battlefield is like a jungle. If we can't hit our prey with our weapons - achieve commercial success, we'll starve to death sooner or later. At least if we don't starve to death, we must consider the ease of the weapon, and even if we are in a good mood that day, we can carve a flower on it to make it look like a work of art.

The pursuit of the ultimate in code is not useless. Those core libraries and frameworks need these skills, because when they are written well, they can already bring more value to the upper-level business.