I recently reminded folks at work that it sometimes helps to look back at the issues we put into our code in the last 3-9 months. We can formulate a short (3-5 item) bullet list in a checklist. The list is the 3-5 most-frequent types of errors we made in the recent past. The checklist reminds us during code reviews to look for the same type of bug in new code while we are reviewing the new code. Of course, the checklist must change, so there is effort in re-reviewing the last 3 months of bugs 4x per year and updating the checklist. If all the bugs we put in are unique and there are no visible patterns, this effort is not worth doing. This idea comes from Steve McConnell's book Code Complete. He calls the process "checklist driven code reviews" and he published a (long) list of common patterns of issues as examples. Steve's book and approaches are quite old and modern integrated experiences and tools enable more, better refactoring, as well as some new difficulties for reviewers.
Over the weekend, I stumbled upon this interesting post from Mike Lynch with very-useful advice for how you should formulate your pull requests so that reviewers can more-easily review your code.
(All links in this post were removed because Google claims they violate the readers's privacy. You will need to duckduckgo search for the book, the checklist, and Mike Lynch's blog post about formulating pull requests for code review.)
No comments:
Post a Comment