Skip to content

Instantly share code, notes, and snippets.

@alan-andrade
Last active August 29, 2015 14:24
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save alan-andrade/7fa379d22aae130c24e3 to your computer and use it in GitHub Desktop.
Save alan-andrade/7fa379d22aae130c24e3 to your computer and use it in GitHub Desktop.

Code Reviews

Engineers know who will be reviewing their tasks before they begin. Upfront planning can help avoid iteration during review.

Follow a style guide.

App knowledge is distributed. the eng. should rely on teammates to make it happen.

Encourage the use of //TODO, //FIXME, //HAX with the date and author embedded.

When more things can be done, create a task and keep going.

  • Uses clang-format for spacing rules and whatnot
  • Uses homegrown script to sort header alphabetically

At the pull resquest, the engineer must describe the following details.

  1. Which Goals this pull request is attempting to achive?

  2. How the goals were achieved?

  3. Test plan. Should describe what are the edge cases where code might break. Code should be unit tested. (Modular pieces)

When the pull request is ready for review, the attention turns to the reviewer who nitpicks on architecural details such as duplication and modularity.

Reviews facilitate a discussion between engineers that provide an opportunity for growth A thorough code review process requires significant engineering effort, but it’s emblematic of a culture that has effective communication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment