The secret to evolutionary code
Emergent Design: basic principles
Book extract, part one The idea of building simple code that's easy to maintain generates debate at both a philosophical and a practical level. What to we mean by "simple", how do you get there – use a model with comments or just an economy of code - and, importantly, who the hell built this mess? That kind of stuff.
Technology veteran Scott Bain's book Emergent Design: The Evolutionary Nature of Professional Software Development published by Addison Wesley this month, digs into this subject. Scott, whose thirty years' experience spans development, engineering and who is a senior consultant with training specialist NetObjectives, examines important principles in patterns, refactoring, and test-driven development for delivering and maintaining robust, reliable, and cost-effective systems.
In this, the first installment of Reg Dev's five-part chapter serialization, Scott introduces the concept and tackles the first of the qualities needed to devise simple, maintainable code: encapsulation.
Paying attention to qualities and pathologies
Historically, code has been more fun to write than to read. Writing code feels creative, progressive, and allows the author to express ideas and explore them. Reading code is tedious, sometimes confusing, and can sap one's confidence when puzzling out the intent of a piece of code.
Developers have often said that languages like C and APL are write-only languages, a sobriquet that is fairly applied to any code that is cheaper to rewrite than to figure out, when it comes time to make a change. But to say that something is cheaper to rewrite than to fix is to say that it is unmaintainable, and maintainability is one of the goals I am espousing in this book.
What would it take to write maintainable code? I suggest that it takes, at minimum, the following.
- The code must be clear. You should be able to tell, quickly and after a cursory read, what the code is intended to do, what the individual parts are for, and how they interact. Ideally, class names, method names, and method signatures should tell the bulk of the story.
- You should be able to change the code in one part of the system without adversely (or unknowingly) affecting some other part of the system. There should be no ripple effects. You should not have to wince when you make a change.
- When you need to change something, it should be obvious where the change goes, and that should be only one place in the system. In other words, once you find it, you should be able to, with confidence, stop looking elsewhere for it.
- When you make a change, you should be able to validate that you made the change you intended, that you did not change anything else, and that this validation is quick and relatively low-cost to achieve.
In this chapter, I am going to examine the qualities that describe code that is in this state. Then, as another way of considering these key concepts, I will examine the pathologies (indicators of illness) that help us to see when we are not writing code with these qualities.
Once I understand what I am looking for in quality code, I will have a much easier time evaluating a given piece of code and making changes to it that bring it in line with these qualities.
The concept of the first principle
A first principle is a basic principle from which other principles follow. First principles are powerful because they allow you to encapsulate a large amount of wisdom into a single point. An example of a first principle is the golden rule: Do unto others as you would have them do unto you. If you have kids, you have probably realized at one point or another that if you could get your children to follow this rule, you would be 90 per cent of the way toward making them into good citizens. This is because most of the other rules we want our kids to follow actually are extensions of this one basic rule. That makes it a first principle. In object orientation, we have several first principles that help to guide us at every phase of a project. A few are:
- What you hide you can change (encapsulation)
- A thing should do what it says it does, and nothing else (cohesion)
Throughout this book, I will be looking for first principles, and pointing them out whenever I find them. A good first principle should be easy to remember and easy to understand, and it should be clear why it is important and what benefits we will gain by following it. I am going to look for:
Maintainability is the goal - the ability to change the code without fear, without hesitation, and without feeling resistance. To work in an evolutionary style, we must see change not as an enemy, but as an ally, as a good thing, as something we are actually eager to do.
That is a tall order indeed.
One of our most important allies in this quest is encapsulation. Encapsulation is a fancy word for hiding. We hide one part of the system from another part of the system, and in so doing we prevent one possible place where we might do unforeseen harm.
If a system is fundamentally encapsulated, we are fundamentally free to change it. If a system largely lacks encapsulation, we are not free, and thus the system cannot evolve.
Although the things that follow-coupling, cohesion, and redundancy-are, in fact, the key qualities that define good (changeable) code, encapsulation is a first principle, because it guides us toward them.
First, we will examine each of these qualities, and then discuss how each relates to encapsulation.
Catch up with Scott in part two, as he tackles the next of his basic principles, cohesion, looking at code samples and examining the power of perspective.
This chapter is excerpted from the new book, Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain, published by Addison-Wesley Professional, March 2008 ISBN 0-321-50936-6 Copyright (c) 2008 Pearson Education, Inc. For more information, please visit informIT.com