At Okode we have a motto: rather than reducing the number of failures we must concentrate on reducing the average time between failures. It is evident that in a changing ecosystem, where the technology of yesterday little (or nothing) has to do with today’s, we can not achieve perfection since many factors are not within our reach in a reasonable time. Our customers value much more that we concentrate on being perfect by detecting fast and quickly bugs than having any (absolutely any) bug when we publish our Apps if this implies delays in the release.
However, this should not lead developers to relax and make mistakes, it is rather a philosophy for which we decided to prioritize more the detection and correction of bugs while trying to prevent them from appearing.
And last week we decided to have a break for a moment to talk internally about prevention issues in a monographic session of code review with every developer. And that’s why we call it Okode review.
We had the opportunity to review things such as:
- Principle of sole responsibility: The idea is that a class / module should only have a reason to exist. It is more difficult than it looks. Normally, this principle should also be applied to the methods. A small rule would be that if we have to use “and” to describe what a class does, surely we are not applying the principle of sole responsibility well.
- Open / Closed Principle: If we are working with an object-oriented language, are the objects open for extension and closed for modification? What happens if we need to add another “foo” ?.
- Duplication of code: Basically refactor when necessary.
- Patterns / Anti-patterns: This point will be given by the experience, but if we already know our project we can try not to stumble twice.
- Names of variables and methods: Choosing the righ name of the classes, variables and methods is fundamental to allow the code to be correctly maintained by ourselves or by other developers of our team.
- Readability: Is the code easy to follow? Have we had to pause the review to decipher it?
- Coverage: Especially in new functionalities. Do the tests cover all the code? Are fault conditions covered? Are the tests easy to read?