Here’s a chance to review your peers’ code! You’re going to be jumping into a new code base, without much context. Yes, it sounds like a lot, but don’t worry! The power of Rails, and the power of well factored code is that you should be able to learn a lot simply by reading. You should not run these apps locally to do the assignment.
- Your GSI will send your team 3 links to PRs from another team in CS169
- Each review will be submitted as a pair of students.
- Your team will have PRs from the same team - you should leverage your peers on your team to help understand the other team’s code.
- Review this video about GitHub Code Review: https://www.youtube.com/watch?v=HW0RPaJqm4g
- You will read through the PR, including the description, actual code, associated checks / status reports.
- You should leave at least a few comments on individual lines of code. If you really can’t find code that can be improved, find some code that you’d love to highlight and tell the author why.
- You should leave a final review using the main “Submit Review” text box. It should use the template provided below.
- You shouldn’t run their app locally, however, you can welcome to play with a deployed version of the PR if there’s a link available.
- Remember, you’re all still learning! Be honest in your feedback, but be kind!
What are you looking for?
Review the recent lecture on Code Review for some ideas.
- Code should have a consistent style and format.
- Names, indentation should follow the conventions of the language and of the code around it.
- Is the code relatively easy to understand? Do method names make sense?
- Don’t read just the code, look at the design!
- Are the design patterns used appropriate?
- Is the data modeling sound?
- Does the feature make sense? Does the code address the requirements?
- Use the description along with any linked stories to give you context. It’s OK if you don’t have all the context.
- Are there any files that should be removed from the PR?
- Temp files, local configs, scratch notes, etc.
- Are the code comments logical and helpful?
- Comments should describe why. Rarely should a comment describe what is happening.
- Comments that describe the “what” usually mean you could choose better variable and method names!
- Do the comments around changed lines of code still make sense? It’s very easy for comments to become out of date.
- Is the code in the right places?
- The PR should still follow MVC.
- Are there any potentially dangerous actions?
- New migrations?
- Routes that can delete a lot of data?
- Actions that change permissions?
- Are there safeguards in place? Are these any tests?
Paste this block as the template for your main code review. It’s written in Markdown, so it should be nicer to read when viewed on GitHub.
**What is the goal of this PR?**
**Were you able to view screenshots, story cards, and or test the app?**
**Is the PR in a shape that makes it easy to review?**
_answer here..._ Look at the description, any links, the size. Did the authors try to make it easier to review?
**What are the status of the tests?**
Are the tests included all passing? Are the tests comprehensive? Are there any features that need to be tested? Are there any tests that are redundant?
**What is the style of the code like?**
Are there any code linters that were run automatically?
What is their status?
If there are no linters, you get to play the human code linter.
**Is there anything missing from this PR that should be included?**
**Feature Design: Are there any parts of this feature that are cause for concern?**
There might be nothing. Could this feature be abused by users? Does the code look safe in how it treats data? Are there any potential bugs that should be guarded against?
### Overall Assessment
**What does this PR do well?**
**What is something that could be improved with this PR?**
Grading and Submission
- You must submit a “Code Review” on GitHub via the official Code Review mechanism. You review you
- You will submit the link to your PR to a Gradescope assignment
- Add your partner to the submission.