Code self-review experience

From: Zhuang zhoumengbutterfly
1. First, the attitude should be correct.CodeSelf-review does not deny yourself, but gives yourself a better chance to do your job. During the review process, you should try to review your code as a bystander, despite the difficulty.

2. Code review is inseparable from refactoring. During the review process, we found that refactoring should be used to improve any bad taste. We found that testing should be supplemented in time when there is a lack of testing, rather than missing bugs.

3. The code self-review may not be as early as possible. After a while, I will go back to view what I wrote and give a more objective evaluation of some design choices, during the review process, you may need to re-understand the code. In this process, you can check the readability of your code and think about how to improve the readability. Remember that the code is read first.

4. During the review process, you need to record some errors that have been made, and why such errors were made at that time, create your own bug database, and review them frequently, avoid the same errors in future work.

5. Self-Review of code should be a continuous process, instead of taking specific actions at a specific time, and often review your code, not only can you identify your own gains and losses, it can further improve its design and foresight capabilities in future work.

6. There is no conflict between code self-review and the review of team members. A self-review is performed before Mutual Review, which helps improve the review efficiency, this includes improving readability and avoiding common errors.

7. Some common precautions for code self-review:
(0) code that you think will never go wrong and has never been reviewed.
(1) Pay attention to else statements. Sub-statements under the IF condition may be a normal process, while else indicates exceptions or special scenarios, you may pay special attention to how to handle the normal situation, but ignore the implementation details of the else clause. For example, if the released lock is not released, the Count of this decrease is not decreasing, the special value is not assigned.
(2) Do you need to implement the empty method without the method body? Or forget to implement it?
(3) Have you forgotten break when you pay attention to the switch statement? This error can be avoided by static code check tools such as findbugs.
(4) Pay attention to the large comments. Why are there so many comments? Is the code poorly written? Or legacy annotations? The remaining comments are misleading and must be deleted in a timely manner.
(5) Pay attention to some code that looks "unreasonable". Many of such code is optimized based on the so-called performance considerations. Is such optimization required? Can I remove these "strange" codes to meet normal requirements?
(6) There is a hypothetical code for the use of the client. If the user only uses this code, if the user only uses some attributes in the returned object, other attributes will not be used? Do not make assumptions about the customer code! This customer code includes external users and internal code that calls this module.
(7) Do I forget to fix the bug and implement the function of code labeled with task tags such as fixme and todo?
(8) can any method with more than 15 Rows be split into finer-grained methods and kept at the same abstract level?
(9) Should any constant value in the code be extracted as a separate constant? Is the default value of the constant set reasonable?
(10) Any code that holds the container provides a method to put the object into the container. Is there a way to remove the object from the container? Ensure there is no memory leakage risk.
(11) other bad tastes mentioned in refactoring. Don't let them go, but do not pursue perfection. Oo is not the Holy Grail.AlgorithmDo not introduce three objects and four interfaces.
(12) at the end of the review, you can list a list, list the risks faced by the project, propose solutions, and review the key code according to the list, focus on handling exceptions. The review of risk points. I suggest you put it behind it and solve the general error. At this time, you will become familiar with the code again.