Within the last team code review, I met a lot of my colleagues are talking about implementation unclear requirements.
About the following performance:
- Up demand not say, just say code. The audience confused and do not know the design is reasonable.
- Having described the requirements, but also directly look at the code, see table structure, no mention of the process.
- Relatively simple algorithm, described in particular around, people do not understand. After being pointed out to think this thing is so simple, why do you not understand, very aggrieved.
- Direct that term, not to the interpreter. Also made their own interpretation of the term does not give, the more chaos there is the term "multiplex", so that we understand are different.
So programmers how technical solutions make it clear it? From a practical point below teach you some tips in a short time with the ability to speak clearly.
First, the first account of the needs background
Why do this demand, for what is required to achieve, product manager mention what boundary conditions. There is no silver bullet, good or bad and implementation of a program of technical requirements are closely related, they are not decoupled. For example, a system interface to access the quality of statistics that can accept a day to run a script to generate data. But providing services to users of consumer details, it must be able to demonstrate in real time, and can not go wrong.
In the assessment, the more time consuming, is to ask the audience of listeners who needs to be reviewed background. There are people who give the audience an idea, and then been denied accreditation, saying there is required a product I just did not say. Then make recommendations to people, it is very hurt.
Account of the background and a good alignment is the basis for the assessment of technical solutions and code review, otherwise I do not know that behind you is reasonable, in the end you do not even know what to do. Technical program evaluation out of the question.
Second, the overall architecture introduces technical solutions
After the background finished, say your approach. First GLD points, starting with a general introduction architecture design. What are modules, each responsible for what duties, how the convergence ...... so we have a full understanding, to see which part of the principal contradiction, we put 80% of the energy spent on the assessment of 20% of important module, the best steel in the knife's edge .
For example, a prize-giving activity, the most important module is a module lottery prizes, but overall do not speak up, but to talk about the show module active rules, but spent most of the time, it is a waste of manpower.
Describe the overall architecture with architectural diagrams, flowcharts, plus concise language, to an account of. Generally architecture template, templates directly in accordance with the requirements, refer to the existing excellent examples, there will not be a big problem. Most importantly, this first talk, to explain clearly.
Third, the introduction protocol, Database Design
After the introduction to the overall program, introduced protocols and database table design, began to gradually into the details. Because this design is reasonable, the impact on the efficiency of the program is relatively large.
What distinguish agreement, the table is important, focusing on speaking, other less important to speak fast.
When the protocol execution flow, to explain clearly, the entire protocol is how circulation in each module, the specific data modification, and how the existing table structure concatenated. This is the process of program execution, if say for sure, will be the depth of doubt whether you can achieve clear.
This part is to be noted, terms less as possible. Because everyone's different background, some of the technical terms we do not know, you want to use straightforward words so that we listen to understand.
For example: Some people say when describing the protocol process, "I call the 123 number provided by the command server after a successful return, the state field of the database to 2, to complete the prizes." But you say the 123 is doing, state What does it mean, what is 2 state?
Much everyone's questions, saying it should be good, "I call protocol 123 prizes provided by the server, the return is successful, the database in the user's state awards, prizes have been updated."
Fourth, the branch and exception logic description, explain the code
After the foregoing explanation several portions, substantially finished program. The rest is talk branching logic, and exception logic. A code written is good, whether an experienced programmer, mainly to see whether the place for exception handling.
This part is mainly about disaster recovery from the architecture, robustness, such as a server died, or a module frequently requested, whether you have early warning systems, compatible. It means the boundary conditions of service and the ability to explain the system.
Finally the code, if the code review, at this time began to say your code. While it is looking relatively late, but we all know what your code is a function to see the speed will be accelerated.
V. Replay
After each review, to re-set their own summary. What problems are people problems, why ask? I should explain what the problem is not accountable, and let people ask? What is the problem I program, the challenges posed by others?
For he did not explain, thinking why would leak, if we can make it clear in advance, if you can save a lot of time.
Heart fundamental is to have empathy. Reflections from the other point of view, the problem is that he will know it, I do not say he understand? Program evaluation is not important that you finish, but others understand. People concerned about the audience's reaction, your task is not to say, but let us listen to understand. Instead he kept saying, but to make everyone understand what you mean, so that other people can help you. Otherwise people will always ask questions, challenge you, and finally deny your program.
Do not think that the audience kind of stupid, is not so simple to understand, if people do not understand the audience, then you must be wrong. Strong ability of people to be able to explain the problem is very simple. US writer specializing in science, and the complex scientific knowledge to do, "the old woman who can answer." Review of the audience who are battle-hardened, if they reflect do not understand, then who would be the problem?
to sum up
Technical solutions must first explain the background to explain, repeat the overall framework, and then refine the process. The first main line, and then branch to the correct path, then exception logic. To speak to the audience point of view, straightforward and simple as possible, so that non-technical people can understand is the best
This link address:
https://www.owenzhang.net/blog/201.html