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 lines of code.
? Do the writing units that is longer than lines of
Code in the first place, or by splitting long units into multiple
Smaller units until each unit have at the most lines of code.
? This improves maintainability because small units is easy to
Understand, easy-to-test, and easy-to-reuse.
Units is the smallest groups of code that can maintained and executed independ‐
ently. In Java, units is 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 was reused and tested is a unit.
Motivation
The advantages of short units is that they is easy-to-test, easy-to-analyze, and easy
to reuse.
Short Units is 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 won't detect errors in the application logic automatically, and neither would
Your editor or IDE (integrated development environment; e.g., Eclipse). Code with a
Single responsibility are easier to test. In general, the short units is only one thing,
While long units does multiple things and tend to has more responsibilities. A Unit
With one responsibility are easier to test, since it implements a single indivisible task.
That allows the test to being isolated (specific to the unit) and simple. Chapter dis‐
Cusses testing in more detail.
Short Units is easy to AnalyzeIt 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 is apparent when
Writing new code, but it makes all the difference is modifying existing
Code. This is a exceptional situation, since maintenance begins the day after the
Project is started.
Short Units is easy to reuseA unit should always being invoked in at least one method (otherwise, the unit is dead
Code). In the a system, you can reuse a unit by invoking it in more than one method.
Small units is 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
There are more specialized functionality than short units. This makes reuse hard, because
It is not very likely, the specific functionality of a long unit is suitable. In contrast,
Short units tend to is more generic. This makes reuse easier, because it's more likely
To fit your needs. Reusing code also helps keep the total code volume low.
How to Apply the guidelineFollowing this guideline isn't difficult when you know the right techniques, but it
Requires discipline. This section presents the techniques that we find particularly
Important. When writing a new unit, never let it grow beyond lines of code. That
means that well before you reach the lines of code, you need to the start thinking about
How to add further functionality. Does It really belong in the unit is writing, or
Should it go to its own unit? When a unit grows beyond lines of code despite
Your efforts, you need to shorten it.
Using refactoring techniques to Apply the guideline
This section discusses, refactoring techniques to apply the guideline and achieve
Shorter units of code.
refactoring technique:extract MethodOne refactoring technique that works on this case is Extract Method
refactoring Technique:replace method with method Object
Common objections to Writing short Units
While writing short units could sound simple, software developers often find it quite
Difficult in practice. The following is typical objections to the principle explained in
This chapter.
objection:having more Units was bad for performance"Writing short units means has more units, and therefore more method calls. That
Would never perform. "
Indeed, theoretically, there is a performance penalty for have more units. There would
Be more method invocations (compared to have fewer, longer units). For each invo‐
cation, a bit of work needs to is done by the Java Virtual Machine (JVM). In practice,
This is almost never a problem. In the worst case, we is 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, where can focus on
Maintainability without sacrificing performance. An example was 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 can has your
Cake and eat it too. We is not saying that there is no performance issues in enter‐
Prise software development; However, they seldom, if ever, is caused by excessive
Method calling.
Sacrifice maintainability to optimize for performance,
Unless solid performance tests has proven that you actually has a
Performance problem and your performance optimization actually
Makes a difference.
Objection:code is harder-Read when Spread out"Code becomes harder to read when spread out over multiple units."
Well, Psychology says. People has a working memory of about
Seven items, so someone who's reading a unit that's 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's working on it (and not a week later).
Write code that's easy-to-read and understand for your successors
(And for your The future self).
Reading notes:
Building maintainable Software:ten guidelines for Future-proof Code
by Joost Visser
Copyright? Software improvement Group, B.V. All rights reserved.
Printed in the states of America.
Published by O ' Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O ' Reilly Books is purchased for educational, business, or sales promotional use. Online Editions is
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.
Building maintainable Software-java Write short Units of Code
