Architectural Review

Back to Code Review Overview

The architectural review should occur as often as necessary. There should actually be an architectural review for ANY software component that is being introduced into OpenMRS, before development begins (after the design phase) and when development has completed. The architectural review is a high level review that will hopefully catch integration issues before too much effort has been put into the design or development of an application component. The review should also serve to detect component reuse and generality.

1. How does the new software component fit (or integrate) into the rest of the system?
2. What are some of the protocols used between two components?
3. Are there places in which refactoring can take place?
4. Is the API expressive enough? Too expressive?
5. Are systems tightly/loosely coupled?
6. Could we benefit from abstractify-ing systems?
7. Who should take part in Architectural Review
   • Higher level developers or architects
   • Members of review team should meet (virtually or physically) to discuss issues
8. How long should a review last?
   • As long as it takes, but generally a good review will take between 4 – 8 hours
   • At the end of the review the team should write recommendations for the developer, including risk assessment
   • Recommendations should include both general architectural comments as well as more fine-grained implementation details.
9. When should these reviews take place
   • During the design phase of the project to make sure that the architecture of the component complies with guidelines.
   • After requirements have been completely specified.
   • After each development iteration to make sure code still complies with architectural guidelines.