Table of Contents
...
...
...
...
...
...
...
...
Code Approval's Responsibility
...
Table of Contents |
---|
...
Overview
As developers design and code, they naturally get biased looking at their own code, hence, getting a pair of fresh eyes to get feedback is worthwhile. Code reviews are not easy, but you can firmly believe that the tool can improve your code.
...
Initial feedback may be minor things, such as:
Choice of variable names
Code format issues
Eventually, you will migrate to:
Spotting design issues
Providing better implementation choices
Code Review Categories
Is the intent of the API at the header file clear?
Functions
Should be small
Code should be modular
Does the function name match the actual code of the function?
Module review
Can the module be broken up?
Any duplicated code? (DRY violation)
Can we re-use any existing code?
Unit-test review
One type of test per test function
Minimal “setup”, and maximum code-reuse
Code Approval's Responsibility
Beyond the code author, there is an inherent responsibility of domain owners to ensure that the code review objectives are met prior to giving approval. Also, do not forget the Sibros' steps to writing quality software.
Requirements assessment and updating or adding appropriate requirement
Did we really build what we wanted?
Have the requirements been updated?
Review design and API interface
Is the header file or class interfaces correct?
Is there any possible memory leak or an awkward code interface?
Review the code
Stylistic changes should not be the focus, although you should point that out
Does the code address the requirements?
Is the code expressive and otherwise follows the coding standards?
Review the unit-test code
Do the tests hit the requirement?
Do they leave a quality barrier behind in case someone alters the API interface being added?
...