Design/Code Review Guidelines

Design Reviews Should Check For:

How-to design wiki for Sqoop2.

Use the above as a guideline to ask specific questions about the design such as the 

• Scope of this feature, what it does intend to change and what it does not. 
• What the relevant components in Sqoop that will be affected by this change?
• It might be good to help them break down the design if it is too large and will extend more than few weeks to get the first cut
• Ask them if any of the design decisions were based on some benchmarks/testing if performance is stated as a goal
• Make sure they have done even research to leverage existing utilities/libraries instead of re-inventing the wheel again

Code Reviews Should Check For:

• Is the code change consistent with the proposed design?
• If at this point some of the design decisions have to change, highlight them clearly and get back to discussing them on JIRA or design wiki, do not do back and forths in RBs. RB should be mostly for code review
• Is the new feature or bug fix well covered by unit tests?
• Is the new code sufficiently documented (i.e. code comments and wiki where needed) ? 
• If the feature is user facing, the user documentation must be updated. 
• Does the code break backward compatibility? (For example, adding abstract methods to class used by connectors)
• Are there new dependencies? Are there new dependencies on non-open-source components?
• Is the placement of objects in packages consistent with the rest of the project? If a new package/component is required, it should be highlighted in the design doc
• Does the patch apply? Unit and integration tests pass?
• Learn to spot duplicate code patterns.!
• Sometimes take the extra step to give an example of what you might have done if it is few lines of code.

 More in-depth review checklist per sqoop component.