4.4 KiB
4.4 KiB
name, description, source
| name | description | source |
|---|---|---|
| code-review-excellence | Systematic code review for correctness, security, performance and maintainability. Produces structured review reports. | community (pinned 2026-03-19) |
Code Review Excellence
Overview
Transform code reviews from rubber-stamping into knowledge sharing through constructive feedback, systematic analysis, and collaborative improvement.
When to Use
- Reviewing pull requests
- Establishing code review standards
- Mentoring developers through review
- Auditing for correctness, security, or performance
- Pre-delivery validation against architectural patterns
Instructions
1. Read Context First
Before touching code:
- Read the PR description, linked issues, and requirements
- Understand the architectural pattern being followed
- Check if there's a reference implementation to compare against
- Read test signals (CI status, coverage reports)
2. Review Systematically
Check in this order:
Correctness:
- Does the code do what the requirements ask?
- Are edge cases handled?
- Are error paths covered?
- Does it match the reference implementation pattern?
Security:
- Input validation present? (
@Valid,@NotNull,@Pattern) - Sensitive data masked in logs? (
authorization,customerId) - No secrets hardcoded?
- Authentication/authorization checks present?
Performance:
- No blocking I/O in hot paths (check
@PostConstructusage) - No N+1 queries or repeated file reads
- Appropriate timeouts on external calls
- Async operations use proper context propagation (MDC)
Maintainability:
- Clear naming conventions
- Single responsibility per class
- Dependencies injected, not constructed
- Proper layer separation (no business logic in adapters)
3. Provide Actionable Feedback
For each issue:
- State the severity: BLOCKING | IMPORTANT | MINOR
- Explain WHY it's a problem, not just WHAT is wrong
- Suggest a concrete fix or alternative
- Ask clarifying questions when intent is unclear
4. Acknowledge Good Patterns
- Call out well-implemented patterns explicitly
- Recognize clean abstractions and good test coverage
- Note when the code follows architectural guidelines correctly
Output Format
## Code Review Summary
### Overall Assessment
[1-2 sentence summary of the change quality]
### Blocking Issues (must fix before merge)
- **[FILE:LINE]** — [Description] → [Suggested fix]
### Important Issues (should fix)
- **[FILE:LINE]** — [Description] → [Suggested fix]
### Minor Issues (nice to have)
- **[FILE:LINE]** — [Description] → [Suggested fix]
### Questions
- [Clarifying questions about intent or requirements]
### Positive Patterns Noted
- [Good patterns worth highlighting]
### Test Coverage
- [Coverage assessment and gaps]
Review Checklist for V4 BIAN APIs
When reviewing an API implementation against guia-4-implemented-pattern.md:
REC Layer
- Resource only has
@Validand delegates to UseCase — no logic - Request DTOs use
@NotNull(message = "VDE01")and@Validon nested objects - BusXxxClient is an interface with
@RegisterRestClient(configKey = "...") - BusXxxAdapter injects with
@RestClientand readsagencyCodefrom MDC ValidationExceptionMapperpresent incommon/infrastructure/interceptor/RestClientExceptionMapperpresent and registered via@RegisterProviderInboundLoggingFilterusesSequenceInputStreamto reconstruct the stream
BUS Layer
- Service orchestrates Ports — does not implement HTTP directly
- Service availability checked before business logic
- Security trace executes in
finallyusingAsyncMdcRunner.run() - DomXxxClient has
@RegisterProvider(RestClientLoggingFilter.class)and@RegisterProvider(RestClientExceptionMapper.class) - Mapper uses
@Mapper(componentModel = "cdi")with@AfterMappingfor complex fields MessageHelperuses@PostConstruct— no file reading in constructor- Error responses always include
status = "error"andtraceId
Common Review Anti-Patterns
| Anti-Pattern | Better Approach |
|---|---|
| "Looks good to me" (LGTM without review) | Run through the checklist systematically |
| Nitpicking style while ignoring logic bugs | Prioritize correctness over formatting |
| Rewriting the PR in comments | Suggest one concrete alternative, not a full rewrite |
| Blocking on subjective preferences | Only block on correctness, security, performance |