I have found this “old” movie we made back in 2002 during my work at Mercury to “educate” new employees on our code review procedure.

p.s. Raz Yalov was nominated for best supporting actor that year ;)

Enjoy…

************************************************************************

I have also copy-pasted the presentation transcript below…

• The Golden Rules of Code Review
  • Do a self-review first
  • Stick to the requirements
  • If you need to explain it, document it!
  • It’s about the code – not about you!
  • Unit testing
• Do a self-review first
  • Have you checked all extreme cases?
  • Is your solution KISS?
  • Is your code self-explanatory?
  • Check it as if it was written by someone else
  • Ask yourself the questions you think you are about to be asked…
• Keep It Simple Stupid…
• Stick to the requirements
  • Make sure all aspects of the requirements are filled
  • Make sure you have tested both trivial and extreme cases
  • Document all thoughts and limitations in the code
  • Reference the requirements documents from your code
  • I18N – make sure the code supports multilingual capability where needed
• Documentation
  • Document your files and your functions
  • Give informative comments
  • Explain the logic behind your decisions
  • If you did something that is not logical or intuitive, explain why
  • If you learned historical info while learning the code, document it (be creative :)
  • Follow a standard documentation format
  • When possible, use known design patterns and document the design pattern you chose
• Unit Testing
  • Make sure your unit test is part of the change
  • If you can’t automate the test, check-in a manual procedure to run it
  • Make sure all aspects of the requirements are covered by the tests
  • Document all the tests you wanted to do but couldn’t
  • Test the I18N behavior of your code
• The Code Review Life Cycle
  • “Self-review” your code
  • Schedule a code review
  • Schedule enough time for both people involved
  • When possible, schedule for a time during the morning
  • Split the review into a few sessions, if needed
  • Switch your mind to “listener” mode
  • Write down all comments
  • After the code review is done, apply the necessary fixes and schedule a second review if needed
  • Check-in your changes
• Code Review Tips
  • When you program, remember the last code review
  • If you disagree with the reviewer, invite a 3rd person to review and decide
  • In special cases, invite special guests to review your code
  • When change is small/simple/intuitive, do an “e-review” by mailing your change to the reviewer(s)
  • When self-reviewing, fix mistakes on the spot… :)

This was an offer I couldn’t refused…

Delver is a venture-backed internet startup developing cutting-edge web application in the domain of Internet Search and Meta Social Networks.

It is more challenging, inspiring, interesting and exciting than I expected, imagined or I can put into words so you will have to join to understand… We are looking for top-notch algorithm researchers, .Net coders, mySQL DBAs, “Hackers”, QA experts and out-of-the-box thinkers… to join our unique development team (e.g. Pitz, Boo and Gabel)

Stay tuned (…)

As most of you already know, moving between jobs is an hectic yet purifying transition which can only resemble a month of tantric yoga (which I didn’t have the pleasure to experience yet)

So stay tuned since more details will follow only after I will finish the transition period (~September)…

—
Dear Mercury familia, thank you all for the amazing ride! it was a privilege to work with you and I wish you all the best… keep in touch.