...

• 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?

...