1. Macro Level
2. Micro Level
To review an existing system for any recommendations or trouble shooting - is not a one man job especially for complex Enterprise systems. This is simply not feasible. This is a team effort -at least a team of 3 to 4 - you need strong developers, architects, designers, database architects, domain architects etc.
But for simple to medium complex applications - one person can do the review - provided he networks and seeks help in areas which he is not hands-on.
Coming to the review part, first and foremost - the reviewer (or the review team) should understand from the stakeholders:
Why this review is being conducted?
What are the existing concerns?
What measures have they taken already to address the issues? What have they learned till now?
Or is it a pro-active measure by the management?
These questions would set the right direction for the reviewer. He should exercise his personal judgment and be unbiased.
At Macro Level - the focus should be on the
- Big picture
- What problem is being solved?
- Looking at Architectural layers, Domain objects, their dependencies
- Metrics (Size of the system, violations, outliers)
- How are the NFRs addressed?
- History, timeline of the project execution
- Bug database - if one exists
- What kind of tools the team uses?
- Continuous Integration (i.e. are nightly builds happening)
- Process, guidelines, standards followed
- Team Dynamics
- Code review using many opensource or commercial tools i.e. static analysis of the code
- Class Design
- Build file - How is the build done?
- Does the team has Source Control? Look at the commit history? What is the trend?
- Are there unit testcases?
- Coding standards and guidelines
- Peer review process
1 comment:
Can you explain the micro level architecture and macro level architecture in developers point of view, who develops a brand new system.
Post a Comment