Feeds

The secret to evolutionary code

Emergent Design: basic principles

Build a business case: developing custom apps

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:

  • Encapsulation
  • Cohesion
  • Coupling
  • Redundancy
  • Readability
  • Testability

Encapsulation

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

Secure remote control for conventional and virtual desktops

More from The Register

next story
Why has the web gone to hell? Market chaos and HUMAN NATURE
Tim Berners-Lee isn't happy, but we should be
Microsoft boots 1,500 dodgy apps from the Windows Store
DEVELOPERS! DEVELOPERS! DEVELOPERS! Naughty, misleading developers!
'Stop dissing Google or quit': OK, I quit, says Code Club co-founder
And now a message from our sponsors: 'STFU or else'
Apple promises to lift Curse of the Drained iPhone 5 Battery
Have you tried turning it off and...? Never mind, here's a replacement
Mozilla's 'Tiles' ads debut in new Firefox nightlies
You can try turning them off and on again
Linux turns 23 and Linus Torvalds celebrates as only he can
No, not with swearing, but by controlling the release cycle
Scratched PC-dispatch patch patched, hatched in batch rematch
Windows security update fixed after triggering blue screens (and screams) of death
prev story

Whitepapers

Top 10 endpoint backup mistakes
Avoid the ten endpoint backup mistakes to ensure that your critical corporate data is protected and end user productivity is improved.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Backing up distributed data
Eliminating the redundant use of bandwidth and storage capacity and application consolidation in the modern data center.
The essential guide to IT transformation
ServiceNow discusses three IT transformations that can help CIOs automate IT services to transform IT and the enterprise
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.