| tags | created | modified | ||||
|---|---|---|---|---|---|---|
|
2024-04-04 01:42:00 -0700 |
2024-04-04 01:42:00 -0700 |
- Code Style
- Verify that the code adheres to the agreed-upon coding style guidelines.
- (https://dev.to/markadel/backend-code-review-checklist-280h?ref=dailydev#code-maintainability)Code Maintainability
- Verify that the code adheres to the clean code principles (or any other agreed-upon principles).
- Requirements
- Verify that the code fulfills the specified requirements.
- Verify that new code doesn't break any existing functionality.
- API Design
- Verify that any new APIs adhere to the agreed-upon API design guidelines.
- Documentation and Comments
- Verify that complex logic or non-obvious decisions are covered by clear comments.
- Verify that any required internal or external code documentation is provided, depending on your agreed-upon documentation processes.
- Error Handling
- Verify that exceptions are handled correctly and that error messages are informative.
- Security
- Verify that inputs are validated properly.
- Verify that sensitive data (passwords, tokens) are securely stored and aren't leaked to logs.
- Examine the code for potential security vulnerabilities, such as SQL injection or authentication issues.
- Dependencies
- Verify that dependencies are up-to-date and don't have known security vulnerabilities.
- Verify that any breaking changes are handled when updating dependencies.
- Logging
- Verify that critical places in the code are covered by logs that are useful for debugging.
- Verify that logging adheres to the agreed-upon logging guidelines.
- Testing
- Verify that the code is covered by the appropriate types of automated tests.
- Performance
- Evaluate the code for performance issues (memory, CPU, network).
- Verify that database queries are optimized.
- Version Control
- Verify that the agreed-upon version control workflow and practices are followed.
- Spelling
- Verify that the spelling is correct, as this makes the code more searchable.
Very nice checklist! I would add "Feature Validation" in specific areas where new or updated features are being pushed out to customers. This should verify that Customer Research and Market Validation was completed, verified and reviewed by the whole team (with UX and Product representatives) before the Feature can be marked as Complete. This ensures the Product Teams are accountable for ensuring "The Right Things" are built to avoid waste and "busy work" on unvalidated hypothesis or HIPPO feature requests. Product Teams should also have these quality gates, but it's good to have the same for engineers because it fosters Product Thinking and a more holistic understanding of Delivering Customer Verified Value and not just working on features because it's on an arbitrary backlog - which is pure Taylorism. Note this is not the same as a "Product Owner Review" step, this is more asking for evidence of customer research, ethnographic research and interviews etc. so the whole team understand the Product Hypothesis and the approach for market validation, including the team in on the strategy instead of treating them as simple 'builders' or executors of an external vision. This is how Servant Leadership and Autonomous teams operate within a shared vision, direction, context and understanding the the problem/solution space. Top Down systems interfere with this and ALWAYS end in with conflict and not cohesion because of the lack of shared context and trust.