Original: Taste of Little Sister (wechat official ID: XjjDog), welcome to share, please reserve the source.

Now, given an opportunity to tease someone else’s solution or code, where do you start?

Do you feel like you’re trying to say a million things until you just come up with a code naming problem? If you’re Java, you think of the Baba Development Specification, but that’s code level. Including sonar to the top, but also found some shallow problems.

Now developers are mixed, in order to eliminate the risk in the bud as far as possible, need some means. One of the means is technical review, with the sharp eyes of the masses, to pull back from the brink.

1. Classification of technical review

Technical review will take up the time of product development, but will improve the quality of products, software performance, good scalability, easy to restructure, in the long run is beneficial to future generations.

If you don’t have a complete grasp of the r&d capability of the unit, you must insist on technical review, which can save you a lot of boring low-level faults and defects.

But given that most meetings don’t get to the point these days, digressing is common. Be right with the technical review, don’t be aggressive and don’t go through the motions, these are two extremes.

For r & D, I generally divide R & D technical reviews into three categories. In view of space, I will stop here.

According to the general software development process. Generally can be divided into: scheme review, design review, code review. Too often, we focus only on code reviews, and some structural problems are discovered late, resulting in high quality code but poor overall quality.

2. Program review

2.1 Scheme background

1. Clarify the problems and hazards to be solved by the scheme.

That is the simple reason for the project. If the problem is not tenable, the design is meaningless.

Try to solve a major problem with a solution.

Finally, the problems of the same period are connected in series to see whether the whole is optimal. The so-called first points after the total, not only take care of their own piece.

2.2. Landing

1, the program should be able to land, transition, can not deviate from the reality, to build a utopia.

Design according to the resources the company can coordinate. For example, a company that doesn’t want to spend a lot of money on servers is not a good place to print logs in too much detail and keep them for too long.

2, the cost should be as small as possible, can be carried out step by step, can be phased acceptance.

For functions with longer cycles, there should be milestones to follow for external synchronization and progress tracking.

2.3 Whether to introduce new components

1, can use the first available resources to meet the needs.

Ideal is full, reality is very skinny. A good solution is not necessarily the best solution in the industry. The cost of introducing a new component, even if it is stable, is significant.

2. Research and maintain new components.

If you do need to introduce some components, do some basic research and consider how to maintain them in the future.

2.4. Good scalability

1. The plan should be forward-looking and avoid short-term reconstruction.

This generally see 2-3 years ok, but to avoid myopic, less than half a year to overturn the kind of re.

2, to have good scalability.

Extensibility will inevitably increase the number of modules and the number of external interfaces, and with the above “landing” to match, not lose. In general, providing extensible interface capabilities means having good extensibility.

2.5 Groups and people involved

1. Investment of R&D resources.

Good control of the ability of the participants, uncertain gap is too large goals, which requires a detailed task dismantling, can master the handling of difficult problems.

2. Multi-department communication and coordination.

If the function involves multiple departments of the company, the capacity and schedule considerations of other departments are also taken into account, and full involvement of key personnel is necessary.

3. Key points of design review

3.1. Provide design drawings

1, need to leave a document design that can be understood.

The design generally changes slightly as the problem progresses, but the overall idea does not change. Design drawings can reduce the cost of repeated communication and avoid repetitive discussions.

2, can reflect the simple intention of the designer.

The design should be simple and highlight the main functions. Secondary functions can be supplemented with additional graphical explanations, and should not be overshadowed by the review of the main business.

3. Follow existing specifications and architectures.

Any company will have its own norms and architecture, the design of acclimatization, doomed to the future bumpy. Design changes should be made with a full understanding of the company’s current situation.

4. Whether to consider the disposal of legacy interfaces.

Many developers love to develop new features and treat legacy code like shit. These factors need to be taken into account during the design phase, and legacy interface adaptation, extension, and offline issues represent the number of bugs in the future.

5. Whether to consider historical data disposal.

This process is much more dangerous if the design requires revision of historical data. Any of your field deletions, changes, may cause very serious consequences. The general design principle is to make transitions without subtracting.

6. Whether to consider the parallelism and rollback of the old and new schemes.

Most of the time, your new design will need to work in parallel with the old functionality. In this case, consider the downdraft impact and lifecycle of the old solution. If your design is to replace old features, consider fallback in the event of a serious problem, which can often save your life.

3.2. Reduce complexity

1. Assess the complexity.

In general, complexity is reflected in the following aspects: 1) the call chain is too long, 2) the program policy is too complex to land 3) across libraries and stores, 4) the use of caching, and 6) the use of asynchrony.

Each of these points, for the most part, can be optimized and are the site of difficult bugs. Involving a few people familiar with the business, as well as developers sensitive to distributed application issues, can help avoid problems early on. For example, when you think of caching, you can think of data synchronization, penetration, avalanche, capacity, etc., which is called technology sensitivity.

A “technology sensitive” review can be performed for each component used in the design.

2. Cut out unnecessary components.

If there is no special need for components, do not introduce, first use the company’s existing facilities to complete. You can’t take care of your students.

3.3. Authentication mode

1. Unit test design.

Can your design be unit tested easily? How to validate some logic if unit testing is not possible.

2. Interface test design.

Your design, do you knead all the functions in a piece, affecting the whole body, can not be interface test. There are many designs with this problem, such as using unknown JSON (string) data transfer, transferring multiple redundant, intrusive data at once, and so on.

3.4 High Availability (service)

1. Service classification.

Where your design, and your function, stands. Whether more resources are required to ensure a higher SLA level. Do you need flexible deployment or reserve resources? Are there unexpected spikes in requests?

2, upstream and downstream impact reminder.

The function you’re designing affects upstream and downstream. Whether the promised service level can be achieved for upstream services (generally, the SLA is slightly higher than that for upstream services). Downstream, consider the source of burst traffic: usually from a scheduled task, or from multiple threads.

3.5. High reliability (data)

1. Data consistency.

Whether data inconsistencies occur after extreme events, such as the death of some critical component. In general, service degradation will cause data consistency problems. This part may not have an automated fix, but the difficulty of the fix should be initially reviewed, and if it is too difficult, it should be resolved by recording redundant information.

2. Simulation drills.

Before going online, the possible nodes are simulated. Can be physical exercise, can also be an armchair strategist.

3.6, resources,

1. Determine the resources of each department.

In the design stage, detailed department coordination resources are determined, the short board departments in the whole process are determined, and resources are tilted.

2. Schedule.

Break down and schedule functions according to milestones, to the extent that the department can estimate the overall workload.

Risk of 3.7,

1. Are there any technical difficulties?

Technology development also has 28 principles. A few technical difficulties, which can take up 80% of your time. These problems are usually blocked until the end, and you need to find a way to Mock them out by default.

2. Is there any business risk?

Does the function violate relevant laws and regulations? Do you collect things you shouldn’t? Is some sensitive information not desensitized? If you’re not checking, just shut up.

3. Safety.

Some security problems should be anticipated in advance, such as malicious registration, traffic restriction, blocking, etc. These are usually low priority if resources are limited. Before you grew into an elephant, ants were the ones who could watch you.

Key points of code review

4.1 Results of automated code review

1. Which level must be processed.

With sonar initial scans, many problems can be found. This avoids the temptation to cite references (specifically development specifications). Something automated is always more reliable than something stored in your head.

4.2 Double review

1. Review the main processing logic.

2. Review abnormal disposal.

3, review performance.

4. Check prompt information.

5. Review notes.

The above, is a good developer needs to master the content. The correctness of processing logic is the basis for the function to pass the acceptance, but the problem is usually some relatively hidden places.

Some exceptions reveal sensitive information or go off in unexpected directions. Some error prompts can appear unfriendly and cause a lot of confusion for users. Some of the comment information can skew reality, especially if the developer is unstable.

This step of the review, 360 degrees without dead Angle.

End

Many companies do not have the excess capacity to carry out technical reviews, and developers are like buses up and down, which is also the reason that the poison gets deeper as time goes by.

Don’t review for review’s sake. Review for problem solving, not form. If every time you will open a running account of the general feeling, everyone is nodding (sleepy), that is not the process has a problem, is you in the bureaucratic road poisoning has been deep.

Xjjdog is a public account that doesn’t allow programmers to get sidetracked. Focus on infrastructure and Linux. Ten years architecture, ten billion daily flow, and you discuss the world of high concurrency, give you a different taste. My personal wechat xjjdog0, welcome to add friends, further communication.