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?
- 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?
- Does the patch apply? Unit and integration tests pass?
More in-depth review checklist per sqoop component.
Component | Must not miss checklist |
---|---|
API additions or changes
|
|
Respository
|
|
Integration Test
| |
Connectors ( inhouse)
| |
MR Execution/Submission Engine
| |
Sqoop Server
| |
Sqoop CLI ( Shell)
| |
Sqoop Client
| |
Security
| |
Tools
| |
Docs
|