I’ve been pondering good code reviews and the amount of time spent on such reviews and adjusting the code. While no reviews are definitely an anti-pattern, an overemphasis on having perfect code is as bad of an antipattern.
When making review comments for optional, nice to maybe do in my opinion things consider the following:
-
Is this really worth doing? An example of this is some new ruby syntax versus the standard syntax. Just making what’s easy to read in 3 lines as 1 line.
-
How much would a change to some code improve readability for the new developer (and, not the developer familiar with 1,000 obscure gems)?
-
Will changing this code really work toward our critical company objective of shipping software more quickly?
When making a review, if you feel compelled to offer opinions, please prefix them with IMHO: or FYI:.
Also, based on many years of experience with many commercial projects, code that is obsessively too perfect is as much of an anti-pattern for commercial success as code that is a little messy.
In fact, code that’s messy is often, though not always, correlated with a fast growing business that needs to respond to customer needs quickly.
Our most important goal is to be a learning machine and that means shipping effective code more efficiently and learning how our users respond to what we ship.