How to Do Effective Peer Code Reviews - Dice Insights
- I go away and write some code, including tests for that code.
- I run all the tests and tweak until I'm happy with the work. It functions, it's structured properly, it conforms to all of our style requirements, and it's got a really clever solution to that sorting problem.
- I commit the code to my feature or developer branch. It's not in mainline code yet, and won't ship (this is important!).
- I ask for review. If we're working in Git, then I do it by creating a pull request. If we're using some other source code management system, then I just ask for it based on the commit number, or create a patch.
- Someone else on the teamworking in Git—might be the senior engineer, might be the intern—takes a look at the code. They look for bugs, structural problems, unintentional duplications, or any of the mistakes we developers commonly make.
- I fix any problems brought up in the code review, or talk with the reviewer about why I did it that way. Repeat until we're both happy.
- One of us merges the code and checks it in.
Read full article from How to Do Effective Peer Code Reviews - Dice Insights
No comments:
Post a Comment