As developers it is really easy to get focussed on the detail of the code you are writing ro changing. This can be a problem when you get to the end of a feature and you forget to tidy up loose ends (dot those i's and cross those t's!).
Here is a handy code/peer review checklist that I have set up in my team:
-Click around in DEVINT to ensure the new feature/bugfix and existing functionality are working sufficiently
-Does it match agreed acceptance criteria?
-Does the change integrate well into the wider platform?
-Is the code of high quality, easy to read, etc?
-Is the code change consistent with similar pieces of functionality in Atlas?
-Is there more refactoring required on old code to make it consistent with the newer (presumably better) code?
-Are there any additional tech or functional cards that need to be raised?
-Do the specs/Features cover enough scenarios and edge cases?
-Bug cards – email the team explaining how the bug was missed through dev and peer review so that we can learn from our mistakes.
Comments