Development Process

The current team’s development model is still based on the traditional waterfall development model. The overall development process involves requirements review, test case review, technical architecture review, development and testing, acceptance and launch. This is mainly based on the TL perspective from requirements management, technical architecture review, Discuss several key links of code review and release plan review, welcome to make a brick.

Demand management

The CHAOS Reports of Standish Group, an authority specializing in tracking the success or failure of IT projects in the United States, reported a study by the company. After investigating multiple projects, the company found that 74% of the projects failed. These projects cannot be completed on time and on budget. Among them, the most mentioned cause of project failure is "change user requirements". In addition, from the analysis of Standish Group reports over the years, the most important reason for project failure is related to demand. The CHAOS report of the Standish Group further confirms that the most intimate factor with a successful project is good demand management, that is, project scope management, especially good management of project
changes.

The product is born out of demand. During the entire life cycle of the product, the product manager will receive demands from all aspects, but the necessity, importance and realization cost of each demand need to be analyzed and planned carefully to avoid blindness Deciding on requirements or changing requirements can easily lead to confusion in work. If the technical TL cannot correctly control the requirements, the entire project will deviate from the right track.

The first step in demand management is to sort out demands from different sources, including product positioning, feedback from external users, competitors, market changes, and feedback from internal operations personnel, customer service personnel, and developers. First of all, the technology TL has enough knowledge and control of the product. Simply put, my product is made to meet the needs of whoever. The product demand must be rooted in the needs of the customer and the customer's environment. Each product must have its core value, which can create more value for customers. Based on this consideration, some core needs can often be obtained, eliminating the need for less value.

The most important thing in demand management is the management of divergent demands, which often leads to constant changes or increased demands during the execution of the product. Because people’s thinking is divergent, various fresh and interesting ideas often appear in the process of product conception. These ideas may come from the leader or the product manager themselves, but these ideas are often not related to the core direction of the product. But because these ideas can bring temptation at the time, these unrelated requirements will seriously interfere with the energy of the technical team, disrupt or delay the original plan of the product.

Similarly, technology research and development students also need to establish in-depth thinking about products, not to position themselves as the implementer of product requirements, they also need to be responsible for the requirements.
Many times the demand changes or increases because we face too many choices and want too much, do not have proper control of our desires, and decide the demand according to our own preferences. These factors can easily lead to the product without a clear direction and team. The members were exhausted, but there were no actual results. Therefore, the technical TL must be able to evaluate the priority of re-examining products and screening requirements, and identify the necessity, importance and implementation cost of each requirement.

Give the team a clear direction and focus through careful consideration, focus on the control of resources, and ensure that the team's energy is focused on the core requirements of the product.

Technical architecture review

In the Internet era, everyone advocates agile iteration. They always think that the traditional methods are too heavy, the process is complicated, and the efficiency is affected. Everything is expected to be short and fast. In a flat organization, the demand is often quickly distributed to the front-line R&D, and then it depends on individual toss. In fact, the technical architecture review is also a very important part. The value of architecture review or technical plan review is to gather the power of everyone to analyze and see if there are pits in the plan, and whether there will be insurmountable major technical problems after the plan goes online. Try to consider some things in advance and raise questions. In fact, it is of great benefit to the healthy development of the project.

基于架构评审，我们的目标核心是要满足以下几点：

Design checks to ensure that the plan is qualified, all aspects are taken into consideration, to avoid defects and omissions, do not ask for too many plans, at least not make mistakes.
Ensure that the structure design is reasonable and basically consistent and conforms to the overall principle.
Maintain a global understanding of the system architecture and avoid black box effects.
Discover innovation highlights through review and promote best practices.

Architecture design must ensure the rationality and scalability of the architecture design, but also avoid over-design. Architecture design not only considers the realization of functions, but also has many non-functional requirements, as well as the work required for continuous operation and maintenance, which requires engineering practical experience, balances and trade-offs.

The architecture review requires the following:

技术选型: Why choose component A but not components B and C? A is open source. What is the open source agreement? Based on what language was developed, can we maintain it if something goes wrong? Has the performance been tested under pressure? As a technology selection, we need to consider all these issues carefully before we can make the final decision.
高性能: What are the TPS, QPS and RT corresponding to the product? What are the TPS, QPS and RT that can be achieved in the design? In fact, will there be obvious problems with the overall system performance as the amount of data increases? With the increase in business volume and data volume, how can the performance of our system be further improved? Which part of the system will be the biggest bottleneck? Whether there is the ability to resist sudden performance pressure, how much TPS and QPS can be satisfied, and how to do it to achieve high performance, we need to think about these issues.
高可用：Is there a single-point component, how to fail over the non-single-point component? Have you considered too many options? Is there a possibility of data loss? How to recover data loss? What impact will the system downtime have on the business? Are there other remedies? These problems need to be thought out clearly and there are corresponding solutions.
可扩展性: The business strategies of A and B are almost the same. Will the business strategy of C continue to be derived later? What links can be expanded as the business develops, and how to expand? The architecture design needs to consider the scalability of the business.
可伸缩性: Is the service of each link stateless? Are they all capable of rapid horizontal expansion?
How does the expansion need to be done manually or automatically? Can the response speed be improved after expansion? All these problems require us to think clearly and have corresponding solutions.
弹性处理: Is the service idempotent for repeated consumption of messages and repeated calls of interfaces? Have you considered service degradation? Which businesses support downgrade? Support automatic downgrade or manual downgrade? Have you considered the overtime fusing, abnormal fusing, and current limiting fusing of the service? What is the impact on customers after the fuse is triggered? Is the service isolated, and does a single service failure affect the overall situation? These problems all require us to think clearly about the corresponding solutions to further ensure the rationality of the architecture design.
兼容性: Has the upstream and downstream dependencies been sorted out and what is the scope of influence? How to replace the old and new system? Can the old and new systems switch back and forth? Is the data storage compatible with old data processing? If it affects your upstream and downstream systems, do you notify upstream and downstream business parties? How to minimize the cost of upgrading the upstream and downstream relying parties? These problems require a perfect solution, and a little carelessness can cause malfunctions.
安全性: Do you completely avoid SQL injection and XSS? Is there a possibility of data leakage? Have you made a risk control strategy? Does the interface service have an anti-brush protection mechanism? Are data and function permissions controlled? Has the Xiaoer backstage system performed a log audit? Is the data transmission encrypted for signature verification? Is there a clear text AK/SK and password in the application code? These security details need to be carefully considered by us, and security issues should not be underestimated at any time.
可测性: What is the difference between the test environment and the online? Can I do stress testing online? How to isolate test data in online pressure test? Is there a test whitelist function? Do you support the deployment of multiple isolated test environments? What is the ratio of black box and white box workloads? Whether the new scheme is very convenient for testing, it needs to be considered to a certain extent.
可运维性: Does the system have any initialization or warm-up link? Does the data increase exponentially? Does business data need to be archived and processed regularly? How does the system need to be inspected and maintained if the pressure remains the same over time? The design of business operation and maintenance also needs to be fully considered.
监控与报警: Has monitoring and alarm been added to externally dependent interfaces? Are there any indicators exposed in the application level system for monitoring and alarming? Are there any monitoring alarms for middleware and storage used at the system level? Only by fully considering the monitoring and alarming of each link, any problems will be notified to the research and development as soon as possible to prevent the failure from further spreading.

In fact, projects at different stages have different goals. We will not do 99.99% availability at the beginning of the project to support the architecture of one million QPS. The business goal of completing the project efficiently is also one of the factors considered in the architecture.

And with the development of the project, with the standardization of the company's middleware and containers, many architectural tasks have been replaced by standardization, and business code needs to consider the requirements for scalability, operation and maintenance, etc. in the architecture. These tasks are slowly Can be picked up by the architecture and operation and maintenance teams. At the beginning, we can take a moment to consider these issues, but not all issues require a final solution.

Code review

Code quality includes functional code quality and non-functional code quality. Most of the functional quality can be found through testing. Non-functional code quality users cannot directly experience the quality of this quality. The code quality is not good, the most direct " The "victim" is the developer or the organization itself, because the quality of the code directly determines the maintainability cost of the software. Code quality should be more measured from the dimensions of code maintainability such as measurability, readability, comprehensibility, variability, etc. CodeReview is a very important link to ensure code quality, and establish good CodeReview specifications and habits , For a technical team is a very important core thing, a team without CodeReview has no future.

After each project development self-test is completed, the team of developers will usually be organized to conduct a collective code review. The code review generally reviews code quality and specification issues. In addition, it is necessary to pay attention to whether each line of code change is related to this requirement. If there is a ride-hailing release or code refactoring optimization, you need to ensure that the test passes, otherwise it will not be released.

CodeReview I will focus on the following things:

Confirm code function: The function realized by the code meets the product requirements, and the rigor and reasonableness of logic is the most basic requirement. At the same time, it is necessary to consider appropriate scalability, make a trade-off between code scalability and over-design, and not write useless logic and some additional code that has nothing to do with the code function.

Implement certain features when you really need it, not when you foresee it will be useful. —— RonJeffries

Coding standards: based on the premise of the group development protocol and static code protocol, whether the coding standards are followed and the best practices are followed. In addition to formal requirements, more important is the naming convention. The goal is to improve code readability and reduce code maintainability costs.
Potential BUG: Code that may have problems in the worst case, including common thread safety, business logic accuracy, system boundary range, parameter verification, and security vulnerabilities (business authentication, gray product exploitable vulnerabilities) Code.
Documents and comments: Too little (lack of necessary information), too much (no amount of information), outdated documents or comments, in short, documents and comments should keep pace with the times and keep pace with the latest code. In fact, many times I personally feel that good variable and function naming are the best comments, and good code is better than comments.
Duplicate code: When a project is in the process of continuous development iterative and function accumulation, the appearance of duplicate code is almost inevitable, and it can usually be detected by PMD tools. Duplicate code processing outside the type system can usually be encapsulated in the corresponding Util class or Helper class. Duplicate code within the class system can usually be solved by inheritance, template mode and other methods.
Complexity: The code structure is too complex (such as high cyclomatic complexity), difficult to understand, test and maintain.
Monitoring and alarm: Based on the requirement logic of the product, some indicators are needed to prove that the business is working properly. If an abnormality occurs, monitoring and alarm indicators need to be notified to the R&D personnel for processing. The monitoring and alarm indicators corresponding to the review business requirements are also the key items of Code Review .
Test coverage: Write unit tests, especially whether the test coverage for complex code is sufficient.

In fact, the cost of maintaining unit tests is not lower than the cost of development, which is what the team currently does not do well. For the classic cases involved in each code review above, they will be uniformly output to the document. You can learn together to avoid writing the same Ugly Code.

Release plan review

Projects involving more than 10 person-days must have a clear release plan, and organize project members to participate in the project release plan review. The release plan mainly includes the following points:
1) Determine whether there is an external dependency interface, and if so, please coordinate and coordinate Business side;
2) Configuration confirmation before release includes configuration files, database configuration, middleware configuration and other configurations, especially the differentiated configuration items in various environments;
3) Second party library release sequence, whether there is any dependency;
4) Application Release sequence;
5) Whether there are data changes and corrections in the database, and table structure adjustment;
6) Rollback plan, must have a rollback plan, release problems must have an emergency rollback strategy;
7) Production environment regression test key Case;

supplement

How to become a good technical manager? You have to do these three points (1) Development specifications

How to become a good technical manager? You have to do these three points (3) Technical planning and management

How to become a good technical manager? You have to do these three points (two) development process