How to measure the quality of code, is there a standard and can it be quantified?
I think the answer is no. If the central government gives the provinces a death order this year, requiring the annual GDP growth to reach 10%, I believe that every province will be able to complete the task. In recent years, GDP growth has been above 8%, CPI growth has been less than 4%, and national rejuvenation has been completed by 62%. These are all quantified. Are you satisfied?
Back to the issue of development, there are some numbers, such as the number of bugs and the number of restarts, which can explain certain problems, but not all. It can only describe part of the external quality of the system, which can be guaranteed by QA. But internal quality can only be guaranteed by developing itself, and sacrificing internal quality to ensure functional and external quality should not be done.
What does intrinsic quality mean? For example, the system was found to have a hole, and we were ordered to fill the hole. After arriving at the designated location, I found that there was no soil around to fill the pit, and the soil had to be dug from a long distance, which was obviously unrealistic, and there was not so much time. So we dug a hole from a hidden place next to it and filled the hole with the excavated soil. Usually we think: "This newly dug hole is very remote, and no one will fall into it". Or, we may have dug 3 small holes to fill in a big hole, at least if you fall into the small hole, you will not fall to death. In the end, from the outside, the hole was filled, and everyone was happy.
We leave various pits without shame in the process of project development and bug modification, often to ensure progress and external quality. Reviews often fail to resolve internal quality issues, and developers are aware of the problem, but "it's all about progress". We also left a comment in the code, saying that there is a hole here, and we will make it up next time. However, there is often no next chance because more tasks are waiting for you.
In this way, we maintain a system that has a history of N years and has been changed N times by N people. Now these N people can't find it, and there are pits and incomprehensible codes everywhere.
We are constantly making new pits.
We also spent a lot of energy and took a lot of risk to fill in the previous pits (for example, if you really can’t stand a piece of messy code, you took time to modify it, but this matter does not complete any business function, it is difficult to establish a project, and often it is not There will be tests, and you will even develop in your spare time). More often, when we pass a pit, we don't fix it, but pretend we didn't see it, because we can't risk stepping on a mine to trouble ourselves.
When revising programs while cursing my predecessors, I sometimes wonder, did he also know that he wrote a piece of shit, so he didn't even leave a name?
So, I call on engineers to show their professional hacker spirit and sign their works. Sign your own name on each newly created source file, and if you make a major modification to a file, sign your own name after the original author; if you just add or modify a method, you can only add or modify it in this method Sign the note.
I don't know of any good way to address the intrinsic quality, but it's certainly possible to rely on the developer's personal reputation for intrinsic quality.
Sign your own code for future generations to look up to or spurn, do you dare?
From: Sign the code for future generations to look up to or cast aside, do you dare?