Self Code Review
When first exposed to working on a development team in the “real world”, I had the privilege of experiencing code review. Code review can be good for getting criticism about one’s code, but I found it especially beneficial to gain the skill of critiquing code of a much higher quality than mine. This greatly improved the quality of my own code in a very short time.
Today I work on projects mostly by myself, so I don’t have anyone around to review my code. This means that the code I produce is never criticised, which leads to sub par work (BUGS!). A week ago I decided to try reviewing my own code to hopefully gain some of the benefits that peer code review provides. This seemed like a strange idea at first, but surprisingly it has already made a big difference. I find myself catching stupid things like stray console logs, or realizing that some part of logic could be refactored or modularized. It still feels slightly weird approving my own pull requests, but it shouldn’t take long to get used to that. Here is my current workflow:
- Create a new development branch in Git
- Hack
- Commit changes
- Push branch to Bitbucket
- Create a pull request for said branch
- Look over diffs and try to find at least one thing that needs improvement
- Hack
- Check once more and go back to 7 if necessary
- Merge pull request
This workflow is working fairly well so far, but I need a better way to ensure that no implementation details are missing from a particular feature. This could obviously be done with any checklist application, but something that is tied closer to the pull request would be better. I may try doing this by listing all work items in the pull request description and making sure they are all complete during review.
All in all, my loner development process is getting better. I still think peer code review is much better than self review, but self review is better than none at all and forces you to think about what you’re doing and why you’re doing it.