"There are a few things I look for that are good predictors of whether a project is in good shape. These are also properties I strive for in my own code.
-
Once and only once - If I only have one minute to describe good style, I reduce it to a simple rule: In a program written with good style, everything is said once and only once. This isn't much help in creating good code, but it's a darned good analytic tool. If I see several methods with the same logic, several objects with the same methods, or several systems with similar objects, I know this rule isn't satisfied. This leads us to the second property:
-
Lots of little pieces - Good code invariably has small methods and small objects. Only by factoring the system into many small pieces of state and function can you hope to satisfy the "once and only once" rule. I get lots of resistance to this idea, especially from experienced developers, but no one thing I do to systems provides as much help as breaking it into more pieces. When you are doing this, however, you must always be certain that you communicate the big picture effectively. Otherwise, you'll find yourself in a big bowl of "Pasta a la Smalltalk," which is every bit as nasty as a dish of "Fettuccine a la C."
-
Replacing objects - Good style leads to easily replaceable objects. In a really good system, every time the user says "I want to do this radically different thing," the developer says, "Oh, I'll have to make a new kind of X and plug it in." When you can extend a system solely by adding new objects without modifying any existing objects, then you have a system that is flexible and cheap to maintain. You can't do this if you don't have lots of little pieces.
-
Moving Objects - Another property of systems with good style is that their objects can be easily moved to new contexts. You should be able to say. "This object in this system does the same job in that system. ... Then, if you have a system built with lots of little pieces, you will be able to make the necessary modifications and generalizations fairly easily.
-
Rates of Change - A simple criterion I use all the time is checking rates of change. I learned this criterion from something Brad Cox said a long time ago. I've since generalized it to - don't put two rates of change together. Don't have part of a method that changes in every subclass with parts that don't change. Don't have some instance variables whose value changes every second in the same object with instance variables whose values change once a month. Don't have a collection where some elements are added and removed every second and some elements are added and removed once a month. Don't have code in an object that has to change for every piece of hardware, and code that has to change for every operating system. How do you avoid this problem? You got it, lots of little pieces."
Kent Beck, "Smalltalk Best Practice Patterns"
and can you spot two SOLID principles hidden in these lines?