Skip to main content

Code Review

๐Ÿคจ What are code reviews?โ€‹

Code reviews involve examining code by others to ensure quality, find bugs, and improve collaboration. They help catch errors early, maintain standards, and share knowledge among team members. Reviewers give feedback on coding standards, security, and design, fostering a culture of learning and improvement.

๐ŸŽฌ Start a merge requestโ€‹

If you have created a branch from the issue, this will be simple! (go to a issue -> drop down on "Create merge request" -> Create branch) Other wise if you created branch on your own then we shall follow some additional steps.

โš™๏ธ Auto-created branchโ€‹

If your branch was automatiically created as mentioned above then it should be easy.

  1. Go to the respective issue.
  2. Click Create merge request.
  3. Add your info on what the merge request is, what changes have you made. If the changes not that unique to what is mentioned in the issues then just keep the already tagged issue.
  4. Add yourself as the Assignee and a Reviewer(s).

๐Ÿ”ง Manually created branchโ€‹

  1. Go to the merge requests tab.
  2. Click New merge request.
  3. Select your banch and your target branch.
  4. Add your info on what the merge request is, what changes have you made. If the changes not that unique to what is mentioned in the issues just tag the issue. #{issue number}
  5. Add yourself as the Assignee and a Reviewer(s).

๐Ÿ“œ Merge request descriptionsโ€‹

If you merge request contains a lot of information that does not pertain to the issue that is attached to the item then break up your branch in seperate ones. For instance, if your current branch includes updates for both the login page and the profile settings, it's better to create separate branches for each feature to ensure a clearer and more focused review process.

{1 liner on what the changes are}

{a mini paragraph on what was changed, more detail}

{any supporting docs, designs, and manual tests performed.}

Example:โ€‹

Updated user profile interface

Refactored the user profile interface to improve user experience and added new features for profile customization. Modified the layout and styling to enhance readability and navigation.

test logs: pastebin.com/testPass
design doc: drive.google.com/designDoc

๐Ÿ”ฌ Code reviews should look at?โ€‹

  • ๐ŸŽจ Design: Is the code well-designed and appropriate for your system?
  • ๐Ÿš€ Functionality: Does the code behave as the author likely intended? Is the way the code behaves good for its users?
  • ๐Ÿงฉ Complexity: Could the code be made simpler? Would another developer be able to easily understand and use this code when they come across it in the future?
  • โœ… Tests: Does the code have correct and well-designed automated tests?
  • ๐Ÿ”ค Naming: Did the developer choose clear names for variables, classes, methods, etc.?
  • ๐Ÿ’ฌ Comments: Are the comments clear and useful?
  • ๐ŸŽฉ Style: Does the code follow our style guides?
  • ๐Ÿ“š Documentation: Did the developer also update relevant documentation?

๐Ÿ‘‰ Picking the Best Reviewers!โ€‹

The most effective reviewer is typically the code owner, even if they aren't listed in the OWNERS file. If your preferred reviewer is unavailable, consider including them in the conversation by CC-ing or @ them on your changes. Keep in mind there are many changes going on so you many want to nudge your reviewer and possibly add multiple ones. As of now multiple review on Gitlab is only for prem. user so as stated before, just @ them! image of requsting an addtition review

๐Ÿ‘จโ€๐Ÿ’ป๐Ÿ‘ฉโ€๐Ÿ’ป In-Person Reviews (and Pair Programming)โ€‹

If you pair-programmed a piece of code with somebody who was qualified to do a good code review on it, then that code is NOT considered reviewed. Always have someone outside of the folks writing the code to have a 2nd look and give overall approval.

How fast should code reviews be?โ€‹

Code reviews will vastly differ in duration depending what is going on. Sometime the change is large, maybe everyone is busy, etc. Ideally smaller changes should take 1-2 day.

๐Ÿ•ต๏ธโ€โ™‚๏ธ Reviewerโ€‹

If you are the reviewer try to look at the code ASAP, try to get the inital pass done with in 24 hours. If this is not possible consider passing the task to someone else. Keep in mind the code quality mentioned here.

๐Ÿ‘จโ€๐ŸŽ“ Assigneeโ€‹

If you are the assignee then you want to reply to the comments when you can, one again the sooner the better. Keep in mind you may get one comment that may pertain to multiple areas of your code, though only one comment could be left. Pass over your code to see if there are other snippets of code that could addressed based on the comments you have received. This proactive approach ensures that all relevant issues are addressed comprehensively and in a timely fashion.