• 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

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

• Verify that the build/tests pass
• Understand the feature and associated requirements that are supposed to be implemented
• Check code implements the desired feature and that the requirements are completed
• Check code contains tests
  • Is all the new code covered by those tests?
• Verify the location of new 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
• Are there TODOs that should be completed within this review?
• Check code for code style issues

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

• Write a test that tests the common case usage of your function
• Write tests that cover edge cases of your function
• Write tests to cover all statements, branches, paths

• One liner describing what changed (not period terminated)
• A few lines describing in more details why things changed
• GPG signed commit

How to Write a Git Commit Message

• Separate subject from body with a blank line
• Limit the subject line to 50 characters
• Capitalize the subject line
• Do not end the subject line with a period
• Use the imperative mood in the subject line
• Wrap the body at 72 characters
• Use the body to explain what and why vs. how

References

• https://chris.beams.io/posts/git-commit/