• Make sure you understand what you have to implement
• Make it work
• Write a test for what you implemented
• Refactor the code for reusability/code standard
• Verify that your code passes linting and tests
• Commit your code on a branch
• Push to the central repository
• Verify that CI passes
• Create pull request
• Annotate code to explain intent of changes

• Verify that the build/tests pass
• Read the issue title and description
• New code
  • Understand the feature and associated requirements that are supposed to be implemented
  • Verify code implements the desired feature and that the requirements are completed
• New/Changed code
  • Check code contains tests
    • Is all the new code covered by those tests?
  • Verify the location of new/moved files
    • Are the files in the right directory?
    • Are they appropriately named?
  • Verify classes, methods, functions, parameters naming
    • Are they significant of their purpose?
    • Are they clear enough?
    • Are they respecting the naming convention?
  • Does the code respect SOLID?
  • Consider that when functions/methods signature change, code may now be backward incompatible.
    • Discuss whether this is necessary
    • Backward incompatible changes should be documented
  • In a weak typed or type hinted language, are parameters and return of functions/methods typed?
  • Are there TODOs that should be completed within this review?
  • Check code for code style issues
• Bug fix
  • Verify that the fix is applied at the right location and will not "fix the symptoms, not the cause"

When reviewing

• Provide specific and actionable feedback
• Clearly mark nitpicks and optional comments
  • Alternatively, use an approach such as RFC2219 where you indicate whether a change is a MUST, SHOULD, or MAY
• Assume competence
• Provide rationale or context
• Consider how comments may be interpreted
• Don't criticize the person, criticize the code
• Don't use harsh language

Reference

• https://en.wikipedia.org/wiki/SOLID
• https://medium.com/palantir/code-review-best-practices-19e02780015f
• https://phauer.com/2018/code-review-guidelines/
• https://smartbear.com/learn/code-review/guide-to-code-review-process/
• https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
• https://nyu-cds.github.io/effective-code-reviews/03-checklist/
• https://google.github.io/eng-practices/
• https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html
• https://engineering.18f.gov/code-review/
• https://conventionalcomments.org/
• https://docs.gitlab.com/ee/development/code_review.html

• Always prioritize your work
• Always work on something that is a task in a task tracking system
  • You should always be able to tell someone else what task you are working on and link them to that task
• Always provide an agenda when you book meetings with others

• Code changes are stored in git
• Setup continuous integration
• Have a testing framework
• Use dependency management
• Define a code standard
• Prefer function/method typing over dynamic types
• On every push to git
  • Code quality check
  • Code style check
  • Unit/functional/integration/system tests
    • Code coverage should be recorded during tests and a report made available
• A project repository must have a README.md explaining how to run the project on your own computer
• A project repository must have a RELEASING.md explaining how to release the code
• Responsibilities are made explicit in terms of roles
• Critical roles, such as project lead, must have a backup/shadow individual
• Setup telemetry, alerts, profiling, logging

General

• 3 different environments: development, staging, production
• Write migrations for schema changes
• Use ORM if possible over raw queries
• Always make it possible for testers to report the version they tested against
  • Simplest is to have a meta field in the head section

Steps

• Mockups
• SRS
• Database and software architecture
• Implementation
• Test/QA
• Deployment

See also

• Software project basics