Building Maintainable Software-java篇之Write Short Units of Code

Building Maintainable Software-java篇之Write Short Units of Code

Any fool can write code that a computer can understand. Good programmers write

code that humans can understand.

—Martin Fowler

Guideline:

• Limit the length of code units to 15 lines of code.

• Do this by not writing units that are longer than 15 lines of

code in the first place, or by splitting long units into multiple

smaller units until each unit has at most 15 lines of code.

• This improves maintainability because small units are easy to

understand, easy to test, and easy to reuse.

Units are the smallest groups of code that can be maintained and executed independ‐

ently. In Java, units are methods or constructors. A unit is always executed as a whole.

It is not possible to invoke just a few lines of a unit. Therefore, the smallest piece of

code that can be reused and tested is a unit.

Motivation

The advantages of short units are that they are easy to test, easy to analyze, and easy

to reuse.

Short Units Are Easy to Test

Units encapsulate the application logic of your system, and typically much testing

effort is spent on validating the application logic’s correctness. This is because the Java

compiler will not detect errors in the application logic automatically, and neither will

your editor or IDE (integrated development environment; e.g., Eclipse). Code with a

single responsibility is easier to test. In general, short units may do only one thing,

while long units do multiple things and tend to have more responsibilities. A unit

with one responsibility is easier to test, since it implements a single indivisible task.

That allows the test to be isolated (specific to the unit) and simple. Chapter 10 dis‐

cusses testing in more detail.

Short Units Are Easy to Analyze

It takes less time to read all the code in a short unit in order to analyze how the unit

works internally than it does in a long unit. This may not be apparent when you are

writing new code, but it makes all the difference when you are modifying existing

code. This is not an exceptional situation, since maintenance begins the day after the

project is started.

Short Units Are Easy to Reuse

A unit should always be invoked in at least one method (otherwise, the unit is dead

code). In a system, you can reuse a unit by invoking it in more than one method.

Small units are better candidates for reuse than long units. Long units tend to offer

specific details or provide a specific combination of functionalities. As a result, they

have more specialized functionality than short units. This makes reuse hard, because

it is not very likely that the specific functionality of a long unit is suitable. In contrast,

short units tend to be more generic. This makes reuse easier, because it is more likely

to fit your needs. Reusing code also helps keep the total code volume low。

How to Apply the Guideline

Following this guideline is not difficult when you know the right techniques, but it

requires discipline. This section presents two techniques that we find particularly

important. When writing a new unit, never let it grow beyond 15 lines of code. That

means that well before you reach 15 lines of code, you need to start thinking about

how to add further functionality. Does it really belong in the unit you are writing, or

should it go into its own unit? When a unit grows beyond 15 lines of code despite

your efforts, you need to shorten it.

Using Refactoring Techniques to Apply the Guideline

This section discusses two refactoring techniques to apply the guideline and achieve

shorter units of code.

Refactoring technique: Extract Method

One refactoring technique that works in this case is Extract Method

Refactoring technique: Replace Method with Method Object

Common Objections to Writing Short Units

While writing short units may sound simple, software developers often find it quite

difficult in practice. The following are typical objections to the principle explained in

this chapter.

Objection: Having More Units Is Bad for Performance

“Writing short units means having more units, and therefore more method calls. That

will never perform.”

Indeed, theoretically, there is a performance penalty for having more units. There will

be more method invocations (compared to having fewer, longer units). For each invo‐

cation, a bit of work needs to be done by the Java Virtual Machine (JVM). In practice,

this is almost never a problem. In the worst case, we are talking about microseconds.

Unless a unit is executed hundreds of thousands of times in a loop, the performance

penalty of a method invocation is not noticeable. Also, the JVM is very good at opti‐

mizing the overhead of method invocations.

Except for very specific cases in enterprise software development, you can focus on

maintainability without sacrificing performance. An example is when a method is

invoked hundreds of thousands of times in the case of certain algorithms. This is

probably one of the very few cases in a programmer’s life where you can have your

cake and eat it too. We are not saying that there are no performance issues in enter‐

prise software development; however, they seldom, if ever, are caused by excessive

method calling.

Do not sacrifice maintainability to optimize for performance,

unless solid performance tests have proven that you actually have a

performance problem and your performance optimization actually

makes a difference.

Objection: Code Is Harder to Read When Spread Out

“Code becomes harder to read when spread out over multiple units.”

Well, psychology says that is not the case. People have a working memory of about

seven items, so someone who is reading a unit that is significantly longer than seven

lines of code cannot process all of it. The exception is probably the original author of

a piece of source code while he or she is working on it (but not a week later).

Write code that is easy to read and understand for your successors

(and for your future self).

读书笔记：

Building Maintainable Software: Ten Guidelines for Future-Proof Code



by Joost Visser

Copyright © 2016 Software Improvement Group, B.V. All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are

also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/

institutional sales department: 800-998-9938 or corporate@oreilly.com.

Acquisitions Editor: Rachel Roumeliotis

Editor: Nan Barber

Production Editor: Matthew Hacker

Copyeditor: Rachel Monaghan

Proofreader: Marta Justak

Indexer: WordCo Indexing Services, Inc.

Interior Designer: David Futato

Cover Designer: Randy Comer

Illustrator: Rebecca Demarest

February 2016: First Edition

Revision History for the First Edition

2016-01-25: First Release

See http://oreilly.com/catalog/errata.csp?isbn=9781491940662 for release details.