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.

--

--

Adventuring through life. Stories of software development, engineering, fun, and reflection.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aishwar Muthuraman

Adventuring through life. Stories of software development, engineering, fun, and reflection.