Building Maintainable Software-java篇之Keep Your Codebase Small

Building Maintainable Software-java篇之Keep Your Codebase Small

Program complexity grows until it exceeds the capability of the programmer who must maintain it.
—7th Law of Computer Programming

Guideline:

• Keep your codebase as small as feasible.
• Do this by avoiding codebase growth and actively reducing system size.
• This improves maintainability because having a small prodct, project, and team is a success factor.


A codebase is a collection of source code that is stored in one repository, can be compiled and deployed independently, and is maintained by one team. A system has at least one codebase. Larger systems sometimes have more than one codebase. A typical example is packaged software. There may be a codebase for the standard functionality, and there are different, independently maintained codebases for customer- or market-specific plugins.


Given two systems with the same functionality, in which one has a small codebase and the other has a large codebase, you surely would prefer the small system. In a small system it is easier to search through, analyze, and understand code. If you modify something, it is easier to tell whether the change has effects elsewhere in the system. This ease of maintenance leads to fewer mistakes and lower costs. That much is obvious.

Motivation

Software development and maintenance become increasingly hard with growing system size. Building larger systems requires larger teams and longer-lasting projects, which bring additional overhead and risks of (project) failure.  

A Project That Sets Out to Build a Large Codebase Is More Likely to Fail

There is a strong correlation between project size and project risks. A large project
leads to a larger team, complex design, and longer project duration. As a result, there
is more complex communication and coordination among stakeholders and team
members, less overview over the software design, and a larger number of requirements that change during the project. This all increases the chance of reduced quality, project delays, and project failure.

Large Codebases Are Harder to Maintain

Large Systems Have Higher Defect Density

How to Apply the Guideline

All other things being equal, a system that has less functionality will be smaller than a
system that has more functionality. Then, the implementation of that functionality
may be either concise or verbose. Therefore, achieving a small codebase first requires
keeping the functionality of a system limited, and then requires attention to keep the
amount of code limited.

Functional Measures

Functionality-related measures are not always within your span of control, but when‐
ever new or adapted functionality is being discussed with developers, the following
should be considered:


Fight scope creep:


In projects, scope creep is a common phenomenon in which requirements
extend during development. This may lead to “nice-to-have functionality” that
adds growth to the system without adding much value to the business or the user.
Fight scope creep by confronting the business with the price of additional functionality, in terms of project delays or higher future maintenance costs.


Standardize functionality:
By standardization of functionality we mean consistency in the behavior and
interactions of the program. First of all, this is intended to avoid the implementation of the same core functionality in multiple, slightly different ways. Secondly, standardization of functionality offers possibilities for reuse of code—assuming the code itself is written in a reusable way.

Technical Measures

For the technical implementation, the goal is to use less code to implement the same
functionality. You can achieve this mainly through reusing code by referral (instead
of writing or copying and pasting code again) or by avoiding coding altogether, but
using existing libraries or frameworks.


Do not copy and paste code:


Referring to existing code is always preferable to copying and pasting code in
pieces that will need to be maintained individually. If there are multiple copies of
a piece of code, maintenance needs to occur in multiple places, too. Mistakes
easily crop up if an update in one piece of logic requires individual adjustment
(or not) and testing of multiple, scattered copies. Note that the intention of the
guideline presented in Chapter 4 is precisely to avoid copying and pasting.


Refactor existing code:
While refactoring has many merits for code maintainability, it can have an imme‐
diate and visible effect in reducing the codebase. Typically, refactoring involves
revisiting code, simplifying its structure, removing code redundancies, and
improving the amount of reuse. This may be as simple as removing unused/obso‐
lete functionality. See, for example, the refactoring patterns in Chapter 4.


Use third-party libraries and frameworks:


Many applications share the same type of behavior for which a vast number of
frameworks and libraries exist—for example, UI behavior (e.g., jQuery), database
access (e.g., Hibernate), security measurements (e.g., Spring Security), logging
(e.g., SLF4J), or utilities (e.g., Google Guava). Using third-party libraries is espe‐
cially helpful for such generic functionality. If functionality is used and main‐
tained by other parties, why invent your own? Using third-party code is
especially helpful because it avoids unnecessary over-engineering. It is well worth
considering adjusting functionality to fit it to third-party code instead of building
a custom solution.


Split up a large system:


Splitting up a large system into multiple smaller systems is a way to minimize the
issues that come with larger systems. A prerequisite is that the system can be
divided into parts that are independent, from a functional, technical, and lifecycle
perspective. To the users, the systems (or plugins) must be clearly separated.
Technically, the code in the different systems must be loosely coupled; that is,
their code is related via interfaces instead of direct dependencies. Systems are
only really independent if their lifecycles are decoupled (i.e., they are developed
and released independently). Note that the split systems may well have some
mutual or shared dependencies. There is an additional advantage. It might turn
out that some of the new subsystems can be replaced by a third-party package,

completely removing the need to have any codebase for this subsystem.

读书笔记：

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://shop.oreilly.com/product/0636920049159.do