Review view set of application development code

After reading the code of many colleagues who have just been involved in development, they are always in a heavy mood. Due to lack of engineering experience, they do not know how to write the code, I do not know how to develop from the perspective of software engineering, which greatly reduces development costs, especially product development, and can reduce the costs of multiple rounds of iteration, black box testing, and post-maintenance, in addition, it can intuitively reduce the overtime time, correct engineering methods + accurate grasp of requirements = successful software engineering.

I would like to take this opportunity to re-talk about the differences between software and programs. The so-called program is only a piece of code that can be compiled and run on a computer, and the program design can be academic, for example, in order to verify certain algorithms and certain academic goals, the software fully understands users' needs, A set of executable code and documents with certain framework definitions and quality assurance are successively followed by design, development, unit testing, and integration testing, software is a collection of programs and documents produced after engineering management. The gap between the two is in the following two aspects:

1. The requirements and objectives of the software are very clear;
2. The quality of software is controlled by engineering, and the quality is up to standard;

Many colleagues who have just joined the work generally recognize software development = program development. This awareness is very harmful, and the most intuitive response is time estimation, it is often estimated that two weeks of work have not been completed in the last two months, which is obviously a misunderstanding of software engineering.

This article will focus on the collection of review views on code development. The discussion on software engineering will be shared with you in subsequent articles.

Code review viewpoint set:

"Shape"

1. beautiful shape of the curve: the shape of the Code curve should be more beautiful, and a good shape of the Code is shown as a gentle blunt triangle, poor code is represented by sharp triangles with a large span due to poor writing methods;
Good code shape: (relatively gentle)
----
---------
-------------
----------
-------
Bad code shape: (messy and untyped)
-
-------------------------------------------------------------
-------
--
------------------------------------------------

 

2. function parameters. Excellent code styles have strict control opinions on function parameters. Generally, we recommend that you set the function parameters to within six, we recommend that you transmit more than six parameters by using struct, pointer, or referenced object. Generally, when the number of parameters involved in a single function exceeds 6, you need to consider whether your current function processing logic design has encountered a major problem, which is also an indicator to test your design philosophy.

 

3. code length limit. Generally, it is recommended that the code length of a single function be less than 50 lines, and the maximum length is not more than 100 lines, the main significance of setting this indicator is actually to achieve the layered processing of human thinking logic and avoid many problems brought about by major mistakes in thinking design. For this indicator, many colleagues who are initially involved in programming and development always violate this rule. At the end of code adjustment and modification troubleshooting, we often find these colleagues sweating when looking for a problem, when you find a function and modify it, the parent function is often modified and the sub-function is modified. This causes fixing a bug and other bugs, which may cause serious degrade problems, these are caused by some good programming and development practices.

 

4. the main purpose of setting this indicator is to control the current mainstream screen bandwidth range to achieve code reading without horizontal scrolling, in the past, the old standard was recommended to be controlled at 80 characters per line, and the new Recommendation specification was recommended at 120 characters per line.

 

5. naming rules: You must implement unified naming rules for variable names, function names, class names, package names, and file names to further enhance code readability, make sure that the code is easy to communicate during team development. Many developers with insufficient development experience always think that this is a huge constraint. In fact, if you have done maintenance for large projects and Software Reverse Engineering developers think this is indeed very important, the readable code is much more readable than reading a thick set of documents that often seem relevant to the code and actually cannot keep up with the code update speed.

 

6. code comments: excellent code must contain very good code comments. Because code comments are green in many code editors, the comments rate is called "greening rate ", the recommended Greening rate is about 20-25% (number of rows). We recommend that you balance the distribution to ensure that the code reading can be easily completed with the help of annotations, together with the naming rules above, this can enhance the readability of the Code.

 

The idea of setting "shape" is mainly to facilitate code reading, so that other developers can design a review for your code to facilitate code communication and communication. In addition to high execution efficiency, excellent code, high readability and good testability are also very important indicators, which ultimately determine the delivery quality of the overall code.

 

"God"
1. design viewpoint: the focus is on high cohesion and low coupling. The overall guiding principle is that the internal implementation of the module is high cohesion, and the interface interaction between modules is as few as possible, in this way, when the module interface changes in the future, the workload of modification and adjustment will not be exaggerated. However, it is generally recommended to use Compatibility Design to solve the problem of migrating new and old codes, in this way, the workload caused by the design upgrade of different modules is relatively small. This design idea is especially important for the software design at the operating system level, if you look at the Windows compatibility design process, it is not difficult to see the shadows of such design ideas, in Windows 95, a large number of compatible with the MS-DOS design, Windows 98 compatible with Windows 95 design and later versions compatible with the first three versions of Windows of the various applications run.

2. algorithms: excellent algorithms can directly determine the clarity of ideas for solving complex problems, greatly reduce the workload of code coding, and greatly improve the inherent technical complexity of software. In some extreme cases, the algorithm determines the software's life and death.

3. code logic branch processing: it is best not to break through the three-tier constraints (restricted by the mental thinking system of ordinary people) in the condition and loop nested logic of an excellent logical branch ), the direct jump logic of modern programs is basically not allowed, and the branch logic is controlled within eight. We recommend that you use sub-function classification for the part that exceeds the above standard, in this way, different logics can be reasonably segmented to facilitate others' understanding.

4. exception Handling Method: Generally, the exception handling rules at different layers of the Software except the interface layer are mostly to throw the exception up, in some cases, exceptions must be captured and directly output to logs or ignored. For the UI Layer, exception handling usually prompts that the user-related data processing operation fails, in addition, the detailed error information is notified to the developer through some easy-to-accept expression to help the developer fix this defect.
For example, for Windows, when the underlying processing encounters an exception, you will see the familiar bsod screen, and capture these errors by logging in to the portal using the CPU to give the error code and logic address, you can also dump the data that is present in the memory;
For SDK-level application development, especially remote support, we recommend that the system develop the X-ray function, after a full scan is performed for the scenario where an error occurs, all the environment information during the error occurrence period is fully retained to facilitate remote analysis by developers and provide necessary technical support;
For application-level development, the error interface (exception description details and UI screenshots) and system logs are generally used for comprehensive exception locating, facilitate subsequent developers to provide technical support;

 

5. program processing logic: simple is the mainstream consideration of program processing logic and design. Modern software development, especially application-level development, highlights this central idea, framework-level developers need to learn more about design and implementation from open source code and the community, and find the most appropriate implementation solution between various control transfer models and design patterns, this ensures the overall scalability of the code based on simple, direct, and clear ideas;

 

6. in terms of quality assurance and implementation, all codes must pass a strict quality assurance process to ensure that the final products are qualified. The viewpoint of quality assurance must be rooted in the minds of everyone in the team, at this point, developers often have the following error ideas:
A. quality assurance is what project management personnel and QA personnel should do, and it has nothing to do with themselves. The mistake of this idea is that the scope of quality management personnel is too one-sided, just like the implementation of TQM In the manufacturing industry, the quality assurance of software development is definitely not a few people, but the entire team's grasp and control of the entire lifecycle.
B. quality assurance is only the guarantee of code quality. This idea is also very one-sided, and this idea exists quite seriously among developers, especially those who have not been working for a long time, it ignores superior experience in requirement acquisition, system design, especially human-computer interaction interface design.
C. quality assurance is only a matter of manufacturing segments (coding + testing) and has nothing to do with other stages. According to the quantitative data model analysis of the past hundreds of different content projects by the company, we found that the correlation factor of the final delivery satisfaction of software is mainly caused by requirement confirmation, which is not highly correlated with the code manufacturing segment. In this way, the quality follows the demand, the focus of quality control is the comprehensive quality control model that focuses on requirements and supplemented by code development quality control.

 

The idea of setting "God" is mainly to improve the internal logic quality of the Code, from the perspective of design and writing implementation, the overall quality is indeed a development process dominated by "God" and supplemented by "shape". In addition, from the author's experience, the product management model of waterfall management is emphasized in the development and management models that we have previously promoted. Therefore, the overall quality control is relatively smooth and easy. However, I have learned a lot from many years of project experience, even for product development, in order to meet the market needs of rapid development, the development team is increasingly advocating agile development management models, and the iteration cycle is generally around 2-4 weeks, this paper proposes a new concept of "Embracing Change" to increase customer satisfaction to a new level.

 

When I was developing a well-known SAN storage product many years ago, I had a development with 2-3 tests for quality assurance (all are black box-level integration tests ), even if the cost is so high, the overall product quality is still not high. after a long time of installation and running at the customer's office, there will always be various problems, when debugging, testing, and fixing bugs, I always feel powerless or powerful, it was the painful quality management experience of product development that forced the author to examine the quality of the project from the global perspective of Software Engineering in the following years, we also met another opposite case during outsourcing development to Japan. At that time, we undertook a very critical communication component development. To ensure the quality of the entire project, according to the theory of software engineering, quality assurance is implemented from the perspective of different engineering perspectives, such as requirement understanding, design, code review, single white box, and integrated black box, it was surprised to find that, after six months of running in the customer's environment, only a small bug was found. what's even more amazing is that, driven by the quality control model of software engineering, from the perspective of code development Control and grasp of all aspects of the entire software engineering life cycle, especially putting more efforts into the needs understanding, system design, and other source links, so that the control of software engineering quality and customer satisfaction can reach a new height of integration, the charm of software engineering management lies in the ability to make excellent and large-scale software under the guidance of a unified thinking of ordinary development and testing personnel teams, this avoids the circle where software can only be produced by excellent talents, and changes the production mode of the previous heroic manual workshop to the factory production mode of a large team, truly realizing the software industrialization.