Feeds

The secret to evolutionary code

Emergent Design: basic principles

Choosing a cloud hosting partner with confidence

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

Top 5 reasons to deploy VMware with Tegile

More from The Register

next story
Euro Parliament VOTES to BREAK UP GOOGLE. Er, OK then
It CANNA do it, captain.They DON'T have the POWER!
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
NSA SOURCE CODE LEAK: Information slurp tools to appear online
Now you can run your own intelligence agency
Post-Microsoft, post-PC programming: The portable REVOLUTION
Code jockeys: count up and grab your fabulous tablets
Twitter App Graph exposes smartphone spyware feature
You don't want everyone to compile app lists from your fondleware? BAD LUCK
Microsoft adds video offering to Office 365. Oh NOES, you'll need Adobe Flash
Lovely presentations... but not on your Flash-hating mobe
prev story

Whitepapers

10 ways wire data helps conquer IT complexity
IT teams can automatically detect problems across the IT environment, spot data theft, select unique pieces of transaction payloads to send to a data source, and more.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
How to determine if cloud backup is right for your servers
Two key factors, technical feasibility and TCO economics, that backup and IT operations managers should consider when assessing cloud backup.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security and trust: The backbone of doing business over the internet
Explores the current state of website security and the contributions Symantec is making to help organizations protect critical data and build trust with customers.