Code Complete

by Steve McConnell

When a project reaches the point at which no one completely understands the impact that code changes in one area will have on other areas, progress grinds to a halt.

There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies.

we as software developers shouldn't try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part of it at a time.

One symptom that you have bogged down in complexity overload is when you find yourself doggedly applying a method that is clearly irrelevant, at least to any outside observer. It is like the mechanically inept person whose car breaks down—so he puts water in the battery and empties the ashtrays.

How to Attack Complexity

When I am working on a problem I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong.

Avoid making "clever" designs. Clever designs are usually hard to understand.

Loose coupling. Loose coupling means designing so that you hold connections among different parts of a program to a minimum. Use the principles of good abstractions in class interfaces, encapsulation, and information hiding to design classes with as few interconnections as possible. Minimal connectedness minimizes work during integration, testing, and maintenance.

Voltaire said that a book is finished not when nothing more can be added but when nothing more can be taken away.

The data and methods the object exposes to every other object is called the object's "public interface." The parts of the object that it exposes to derived objects via inheritance is called the object's "protected interface."

Abstraction is the ability to engage with a concept while safely ignoring some of its details—handling different details at different levels.

From a complexity point of view, the principal benefit of abstraction is that it allows you to ignore irrelevant details.

If you had to deal with individual wood fibers, varnish molecules, and steel molecules every time you used your front door, you'd hardly make it in or out of your house each day.

The ability of a language to support operations like Open() or Close() without knowing until run time what kind of door you're dealing with is called "polymorphism."

Polymorphism

The secret might be an area that's likely to change,

Use volatility as a seperator

Hiding sources of change so that when change occurs, the effects are localized

Reminds me of Volatile Design

If you're a conscientious programmer, one of the barriers to effective information hiding might be thinking of class data as global data and avoiding it because you want to avoid the problems associated with global data. While the road to programming hell is paved with global variables, class data presents far fewer risks.

If your program is designed to use huge classes that contain dozens of routines each, the distinction between class data and global data will begin to blur and class data will be subject to many of the same problems as global data.

Use small class files

Business rules. Business rules tend to be the source of frequent software changes.

Compartmentalize business logic

Isolate hardware dependencies in their own subsystem or class.

Includes data storage like databases

The goal is to create classes and routines with small, direct, visible, and flexible relations to other classes and routines, which is known as "loose coupling."

Good definition of loose coupling

A routine that takes one parameter is more loosely coupled to modules that call it than a routine that takes six parameters.

Classes and routines are first and foremost intellectual tools for reducing complexity. If they're not making your job simpler, they're not doing their jobs.

Another potential trap with patterns is feature-itis: using a pattern because of a desire to try out a pattern rather than because the pattern is an appropriate design solution.

Cohesion refers to how closely all the routines in a class or all the code in a routine support a central purpose—how focused the class is.

The reduced-complexity benefit is that the fewer places you have to look for something, the easier and safer it will be to change.

It is easier to fix bugs when the code naturally guides you in the direction of what you are looking for.

Why fight your way through the last 20 percent of the design when it will drop into place easily the next time through? Why make bad decisions based on limited experience with the design when you can make good decisions based on more experience with it later?

I should take my time with coming to a solution. Instead of trying to force myself to come to an answer, it may help to step away or work on something else before coming back to it

The book Conceptual Blockbusting sounds interesting.