1.最基本和最重要的一点,代码是否实现了需求 first and foremost does code meets all requirements which it should met, point out if anything has been left out. 2.改动的代码是否涉及对其他模块的影响 Some time one change in your system may cause bug in other upstream and downstream system and it’s quite possible that new developer or anyone who is writing code might not be available of that dependency. This often directly related to experience in project and I found that the more you know about system and its environment better you able to figure this out. 3.并发 Concurrency: does code is thread-safe? Does it have properly synchronized if using shared resource? Does it free of any kind of deadlock or live-lock? Concurrency bugs are hard to detect and often surfaces in production. Code review is one place where you can detect this by carefully understand design and its implementation. 4.可读性和可维护性 Readability and maintenance: does code is readable? Or is it too complicate for some-one complete new. Always give value to readability as code is not just for this time it will remain there for long time and you need to read it many times. Another important aspect is maintenance as most of software spends 90% time in maintenance and only 10% time on development it should be maintainable and flexible in first place. You can verify that whether code is configurable or not, look for any hard coding, find out what is going to be changed in near future etc. 5.一致性 Consistency: This is part of point 4 but I have made it another separate point because of its importance. This is the best thing you can have in your code which automatically achieves readability. Since many developer and programmer take part in project and they have there own style of coding, it’s in best interest of everybody to form a coding standard and follow it on letter and spirit. For example it’s not good someone using function initialize() and other is using init() for same kind of operation, keep you code consistent and it will look better, read better. 6.性能 Performance: Another important aspect most important if you are writing high volume low latency electronic trading platform for high frequency trading which strives for micro second latency. Carefully monitor which code is going to execute at start-up and which is going to be executed in loop or multiple times, optimize the code which is going to execute more often. 7.异常处理 Exception handling: Ask does code handles bad input and exception? It should and that too with predefined and standard way which must be available and documented for support purpose. I put this point well above on my chart while doing review because failing on this point can lead your application crash and not able to recover from fault on other system or other part of same application. 8.简单 Simplicity: Always see if there is any simple and elegant alternative available at-least give a thought and try. Many times first solution comes in mind is not best solution so giving another thought is just worth it. 9.代码复用 Reuse of existing code: See if the functionality can be achieved by using existing code, advantage of doing this is that you are using tried and tested code which reduce your QA time and also give you more confidence. Introducing new libraries introduce new dependency. I prefer not to try anything fancy until it’s absolutely necessary. 10.单元测试 Unit test: Check whether enough JUnit test cases have been written and cover sufficient percentage of new code. never let you pass the code without Junit test because developer often make excuse of time but believe me its worth to write it. Not last but least that put a comment on your java file that by whom it has been reviewed, what issue finds are out and status of those. This will make the whole process official and ensures that due diligence would be applied during code review. Its also good to maintain your own code review checklist or a project wise code review checklist and use it every time while doing review. There are so many best practices but I have only included those which I follow and found interesting but as I had said earlier this is the area which always needs improvement and no body is perfect on that. So please contribute your ideas on code review and effective development.
2012年1月12日星期四
10 points checklist on Code Review
ref
订阅:
博文评论 (Atom)
没有评论:
发表评论