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 [email protected].


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.