Code Review: Restructuring

The importance of code review: skipping to do a code review because it looks involved, could end up costing you — since you have to add to that code and it wasn’t well structured to begin with.

One good heuristic on when something needs to be restructured is: if there is too much going in a class to keep in your head, call that out in your review — ask people to break it out into a separate class.

This is also the “S” in SOLID — Single Responsibility Principle. You can get technical and argue what a responsibility is. But if you can’t keep everything going on in the class in your head, that’s too much. If the tests for that class look large and/or complex, that’s too much.

The smaller class will ensure the code is more comprehensively tested — since you can see all the different behaviors. Each class will be a lot easier to understand too.

How do you ensure that you don’t have class explosion? Class explosion is bad when you have 1 object that needs to depend on 20 objects to do its work. If 1 object, only depends on 5 — it’s small enough to wrap your mind over how it works. Each of those objects can depend on 4 other objects and in the context of each class it’s easy to understand what they do. This is good.

Lots of classes is not a problem, lots of dependencies is the problem. If each class has a small number of dependencies where each dependency has a small focussed mission, that’ll be easy to understand and easy to maintain, and that is a good thing.

Originally published at www.floatingpoint.ca.