parent
1f9eb18bfb
commit
6e1072bea9
11 changed files with 88 additions and 0 deletions
File diff suppressed because one or more lines are too long
Binary file not shown.
@ -0,0 +1,47 @@ |
||||
--- |
||||
jsonUrl: '/jsons/roadmaps/code-review.json' |
||||
pdfUrl: '/pdfs/roadmaps/code-review.pdf' |
||||
order: 14 |
||||
briefTitle: 'Code Review' |
||||
briefDescription: 'Learn what to review when conducting code reviews.' |
||||
title: 'Code Review Pyramid' |
||||
description: 'Learn what to review when conducting code reviews.' |
||||
isNew: true |
||||
hasTopics: true |
||||
dimensions: |
||||
width: 968 |
||||
height: 506.06 |
||||
schema: |
||||
headline: 'Code Review Guide' |
||||
description: 'Learn what to review when conducting Code Reviews with this interactive guide. We also have resources and short descriptions attached to the roadmap items so you can get everything you want to learn in one place.' |
||||
imageUrl: 'https://roadmap.sh/roadmaps/code-review.png' |
||||
datePublished: '2023-06-03' |
||||
dateModified: '2023-06-03' |
||||
seo: |
||||
title: 'Code Review - roadmap.sh' |
||||
description: 'Learn what to review when conducting code reviews. We also have questions to ask yourself under each node of the pyramid to guide you further.' |
||||
keywords: |
||||
- 'code review tutorial' |
||||
- 'code review guide' |
||||
- 'code review for beginners' |
||||
- 'code reviews' |
||||
- 'code review best practices' |
||||
- 'code review roadmap 2023' |
||||
- 'guide to learning code review' |
||||
- 'code review roadmap' |
||||
- 'code review learning path' |
||||
- 'code review learning roadmap' |
||||
- 'what is code review' |
||||
relatedRoadmaps: |
||||
- 'backend' |
||||
- 'frontend' |
||||
- 'devops' |
||||
- 'system-design' |
||||
sitemap: |
||||
priority: 1 |
||||
changefreq: 'monthly' |
||||
tags: |
||||
- 'roadmap' |
||||
- 'main-sitemap' |
||||
- 'skill-roadmap' |
||||
--- |
@ -0,0 +1,6 @@ |
||||
# Questions to Ask |
||||
|
||||
- Is the project's formatting style applied? |
||||
- Does it adhere to the agreed-upon naming conventions? |
||||
- Is it DRY? |
||||
- Is the code sufficiently "readable" (method lengths, etc.)? |
@ -0,0 +1,7 @@ |
||||
# Questions to Ask |
||||
|
||||
- Are all tests passing? |
||||
- Are new features reasonably tested? |
||||
- Are corner cases tested? |
||||
- Is it using unit tests where possible, integration tests where necessary? |
||||
- Are there tests for NFRs, e.g. performance? |
@ -0,0 +1,5 @@ |
||||
# Questions to Ask |
||||
|
||||
- New features reasonably documented? |
||||
- Are the relevant kinds of does covered: README, API docs, user quide, reference docs, etc? |
||||
- Are docs understandable, are there no signiticant typos and grammar mistakes? |
@ -0,0 +1,10 @@ |
||||
# Questions to Ask |
||||
|
||||
- Does it satisfy the original requirements? |
||||
- Is it logically correct? |
||||
- Is there no unnecessary complexity? |
||||
- Is it robust (no concurrency issues, proper error handling, etc.)? |
||||
- Is it performant? |
||||
- Is it secure e.g., no SQL injections, etc? |
||||
- Is it observable e.g., metrics, logging, tracing, etc.? |
||||
- Do newly added dependencies pull their weight? Is their license acceptable? |
@ -0,0 +1,8 @@ |
||||
# Questions to Ask |
||||
|
||||
- API as small as possible, as large as needed? |
||||
- Is there one way of doing one thing, not multiple ones? |
||||
- Is it consistent, does it follow the principle of least surprise? |
||||
- Clean split of API/internals without internals leaking into the API? |
||||
- Are there no breaking changes to user-facing parts (API classes, configuration, metrics, log formats, etc)? |
||||
- Is a new API generally useful and not overly specific to a single use case? |
@ -0,0 +1 @@ |
||||
# |
Loading…
Reference in new issue