Original: little sister the taste (micro-channel public number ID: xjjdog), please share, reproduced Please keep the source.
Now, to give you an opportunity to Tucao someone else's program, or code, where to start?
It is not that a thousand words you want to burst, just think of the last to get the code name issue? If you are a java, you would think, "Baba develop norms", but that is the code level. Including to sonargive up on, also found some simple questions.
Now developers in different ways, in order to minimize the risk nipped in the bud, we need some means. One means is the technical review, with the sharp eyes of the masses, to the brink.
1. Technical Review classification
Technical review will squeeze product development time, but will improve the performance of the quality of products, software, and has good scalability, easy to reconstruct, in the long run is something that will benefit future generations.
If not fully grasp the R & D capability monomer, we must adhere to the evaluation and review technique that lets you avoid a lot of boring low malfunctions and defects.
But given the current situation can not catch most of the current meeting focused, tricky question is common. To correct the face of the technical evaluation, do not open the smell of gunpowder, and do not go through the motions, these are two extremes.
For R & D, I generally will develop technical review into three categories. In view of space problems go beyond that.
According to the software development process in general. It can be divided into: program evaluation, design review, code review. Many times we focus only on code review, a number of structural problems discovered late, resulting in a high code quality but poor overall quality consequences.
2, program evaluation
2.1, the background program
1, to clarify the issue To resolve the harm.
That is the simple reason for the project. If the problem is not established, the design meaningless.
2, try a solution to a major problem.
Finally, the problem of the same period of the series to see if the overall best. After the so-called first half of the total, that one can not only take care of themselves.
2.2, may fall
1, programs to be able to fall, the transition can not deviate from the actual build a Utopia.
To be designed according to the company's resources can be coordinated. For example, a company does not want to pay big bucks to buy a server, the log is not suitable for printing too much detail, save for too long.
2, the price to be as small as possible, be able to carry out step by step, be phased acceptance.
For a slightly longer period of function, there must 里程碑, in order to track the progress of the external synchronization and time, can follow.
2.3, whether the introduction of new components
1, there is the possibility of using resources to complete the requirements.
Ideal is full, the reality is very skinny. Good program is not necessarily the industry's best solutions. The introduction of a new component of the cost is very large, even if it is very stable.
2, research and maintenance of new components.
If you do need to introduce some components, there must be basic research, as well as components for future maintenance considerations.
2.4, good scalability
1, the program must be forward-looking, avoiding short-term reconstruction.
This is generally seen 2--3 years ok, but avoid short-sighted, less than half the overthrow of the kind again.
2, have good scalability.
Scalability is bound to increase the number of modules and the number of external interfaces to and above the "landing may be" cooperating, not the other. In general, provide a scalable interface capabilities, it means that there are good scalability.
2.5, and the group of people involved
1, R & D resources.
The ability of participants to have better control of the indefinite gap is too big goal, which requires the dismantling of the task to detail, able to master the handling of difficult problems.
2, multi-sectoral communication and coordination.
If the function related to the company's various departments, and the duration of the ability to consider other departments should also be taken into account, key personnel involved in the entire process is necessary.
3, design review points
3.1, providing design
1, it is necessary to leave the document can be read in the design.
With the deepening of the design problem will generally produce subtle changes, but the overall idea is not going to change. Designs can reduce the cost of communication again and again, to avoid repetitive discussions.
2, can reflect the simple intent of the designer.
Design should be simple, highlighting the main features. FIG secondary function may be supplemented with additional explanation, not distracting, it ignores the main business assessment.
3, following the existing specifications and architecture.
Any company will have its own specifications and architecture, design acclimatized, doomed future frustrations. To fully understand the current situation in the company's premise, correct design.
4, whether to consider the disposal of legacy interfaces.
Many developers prefer to develop new features, treat legacy code as smelly dog feces. The design phase of these factors need to be considered, for adapting legacy interfaces, extensions, off the assembly line, the representative of the number of future bug.
5, whether to consider historical data disposal.
If you need to revise the design of historical data, the process is much more dangerous. Deletion of any of your fields, changes are likely to lead to very serious consequences. General design principles are only increasing instead of reducing the transition.
6, to consider whether the old and new programs parallel rollback.
Many times, you need to design new and old features parallel, this time, to consider the impact of offline and cycles of the old programs; if your design is to replace the old function, it is necessary to consider fallback when serious problems occur this can often save your life.
3.2, reduce complexity
1, evaluation of the complexity of.
In general, the complexity is reflected in the following aspects: 1) calling chain is too long 2) Programs Policy complicated not landing 3) inter-library across storage 4) Use the cache 6) uses asynchronous.
Each of the above point, in most cases all can be optimized, and it is difficult bug took place. Invite several people familiar with the business, as well as distributed applications developers involved in sensitive issues, you can circumvent the problem as soon as possible. For example, referring to the cache, you can think of data synchronization, penetrate, avalanches, capacity and other issues, is called 技术敏感.
For each component used in the design, can be "sensitive technology" type of review.
2, cutting unnecessary components.
If no special components necessary not to introduce priority With the company's existing facilities are completed. Regardless of the tube can not keep living.
3.3, authentication
1, the test unit design.
Your design can facilitate the conduct of unit testing. If the unit test can not be performed, how to verify the correctness of some logic.
2, interface test design.
Your design, all functions will close no rubbing a piece, indeed affect the whole body, can not interface testing. This problem exists in the design of many, such as the use of unknown JSON (character string) for data transmission, one time a plurality of redundant transmission, interference data.
3.4, high availability (service)
1, class of service.
Your design and function, in which the position. If more resources are needed to ensure a higher level of SLA. The need to deploy or elastic reserve resources? Are there unexpected request spikes?
2, the influence on the downstream alert.
You are designing the function, the impact on the downstream. Upstream, if you can do (SLA generally slightly higher than the upstream services) promised service levels. Downstream, we must consider is the birthplace of the burst traffic: general from regular tasks, or multiple threads.
3.5, high reliability (data)
1, data consistency.
After the occurrence of extreme cases (such as certain important components of death), whether the data inconsistency occurs. General service degradation, will lead to the consistency of the data in question. This part can not automate the restoration program, but for ease of repair of a preliminary assessment, if too difficult to be resolved by way of recording redundant information.
2, simulation exercises.
Prior to on-line, of possible node simulation exercise. Physical exercise can also be paper.
3.6 Resources
1, to determine each sector resources.
Detailed design phase to determine the coordination of resources, determine the whole process in the short board department, resource tilt.
2, schedule.
To function in accordance with the milestone dismantling, schedule, this department to be able to roughly estimate the extent of the workload.
3.7 Risk
1. Are there technical difficulties?
Technology also exists to develop 28 principles. Several technical difficulties, you may occupy 80 percent of the time. These problems are usually blocked in the end will only be resolved, you need to find a way to Mock, default has opened up these channels.
2, if there is business risk?
Related functions are in violation of the relevant laws and regulations? Whether to collect the things that should not collect? Whether certain sensitive information does not do desensitization treatment? If these are not for you to confirm, then quietly shut up.
3, security.
Some security issues in advance to predict, such as bad faith registration, current limiting, and other banned. If resources are limited, these are usually relatively low priority. Prior to grow into an elephant, you are able eyeing ants.
4, code review points
4.1, automated code review results
1, which level must be addressed.
Using the preliminary scan sonar, you can find a lot of problems. This avoids the situation allusive (especially the development of norms) of. Automated something is better than something in your head more credible.
4.2, double accreditation
1, the main processing logic trial.
2, the trial exception handling.
3, the trial performance.
4, the trial message.
5, review comments.
Above, it is a good developer needs to master the content. Correctness processing logic, is the basic function of acceptance, but the problem is often some of the more hidden places.
Some exceptions would expose sensitive information, or to the unpredictable branches. Some error messages will not appear 友好, causing a lot of trouble to the user. Some comments will offset the actual information, especially in the case of a developer unstable.
Review of this step, a 360 degree.
End
Many companies, is no excess capacity of the technical evaluation, the developers are generally as bus up and down, which is the longer the product of deeper poison sake.
Not to review and assessment, the assessment is to solve problems, not to form. If you are running account every time prescribe general feeling, everyone nodded (sleepiness), it is not a problem with the process is that you have a deep way poisoning bureaucrats.
About the Author: little sister the taste (xjjdog), it does not allow the public a number of detours programmer. Focus infrastructure and Linux. Decade architecture, day ten billion flow, and you explore the world of high concurrency, give you a different taste. My personal micro-channel xjjdog0, welcome to add friends, further exchanges.