Taken from Amazon.de
"Have you ever felt frustrated working with someone else's code? Difficult-to-maintain source code is a big problem in software development today, leading to costly delays and defects. Be part of the solution. With this practical book, you'll learn 10 easy-to-follow guidelines for delivering C# software that's easy to maintain and adapt. These guidelines have been derived from analyzing hundreds of real-world systems.
Written by consultants from the Software Improvement Group (SIG), this book provides clear and concise explanations, with advice for turning the guidelines into practice. Examples for this edition are written in C#, while our companion Java book provides clear examples in that language.Write short units of code: limit the length of methods and constructorsWrite simple units of code: limit the number of branch points per methodWrite code once, rather than risk copying buggy codeKeep unit interfaces small by extracting parameters into objectsSeparate concerns to avoid building large classesCouple architecture components looselyBalance the number and size of top-level components in your codeKeep your codebase as small as possibleAutomate tests for your codebaseWrite clean code, avoiding "code smells" that indicate deeper problems
Author(s): Joost Visser
Publisher: O'Reilly Media, Inc.
Year: 2016
Language: English
Pages: 172
Copyright
Table of Contents
About the Authors
Preface
The Topic of This Book: Ten Guidelines for Building Maintainable Software
Why You Should Read This Book
Who Should Read This Book
What This Book Is Not
The Follow-up Book
About the Software Improvement Group
About This Edition
Related Books
Conventions Used in This Book
Generic Names for Elements of Source Code
Using Code Examples
Safari® Books Online
How to Contact Us
Acknowledgments
Chapter 1. Introduction
1.1 What Is Maintainability?
The Four Types of Software Maintenance
1.2 Why Is Maintainability Important?
Maintainability Has Significant Business Impact
Maintainability Is an Enabler for Other Quality Characteristics
1.3 Three Principles of the Guidelines in This Book
Principle 1: Maintainability Benefits Most from Simple Guidelines
Principle 2: Maintainability Is Not an Afterthought, and Every Contribution Counts
Principle 3: Some Violations Are Worse Than Others
1.4 Misunderstandings About Maintainability
Misunderstanding: Maintainability Is Language-Dependent
Misunderstanding: Maintainability Is Industry-Dependent
Misunderstanding: Maintainability Is the Same as the Absence of Bugs
Misunderstanding: Maintainability Is a Binary Quantity
1.5 Rating Maintainability
1.6 An Overview of the Maintainability Guidelines
Chapter 2. Write Short Units of Code
2.1 Motivation
Short Units Are Easy to Test
Short Units Are Easy to Analyze
Short Units Are Easy to Reuse
2.2 How to Apply the Guideline
When Writing a New Unit
When Extending a Unit with New Functionality
Using Refactoring Techniques to Apply the Guideline
2.3 Common Objections to Writing Short Units
Objection: Having More Units Is Bad for Performance
Objection: Code Is Harder to Read When Spread Out
Guideline Encourages Improper Formatting
This Unit Is Impossible to Split Up
There Is No Visible Advantage in Splitting Units
2.4 See Also
Chapter 3. Write Simple Units of Code
3.1 Motivation
Simple Units Are Easier to Modify
Simple Units Are Easier to Test
3.2 How to Apply the Guideline
Dealing with Conditional Chains
Dealing with Nesting
3.3 Common Objections to Writing Simple Units of Code
Objection: High Complexity Cannot Be Avoided
Objection: Splitting Up Methods Does Not Reduce Complexity
3.4 See Also
Chapter 4. Write Code Once
4.1 Motivation
Duplicated Code Is Harder to Analyze
Duplicated Code Is Harder to Modify
4.2 How to Apply the Guideline
The Extract Superclass Refactoring Technique
4.3 Common Objections to Avoiding Code Duplication
Copying from Another Codebase Should Be Allowed
Slight Variations, and Hence Duplication, Are Unavoidable
This Code Will Never Change
Duplicates of Entire Files Should Be Allowed as Backups
Unit Tests Are Covering Me
Duplication in String Literals Is Unavoidable and Harmless
4.4 See Also
Chapter 5. Keep Unit Interfaces Small
5.1 Motivation
Small Interfaces Are Easier to Understand and Reuse
Methods with Small Interfaces Are Easier to Modify
5.2 How to Apply the Guideline
5.3 Common Objections to Keeping Unit Interfaces Small
Objection: Parameter Objects with Large Interfaces
Refactoring Large Interfaces Does Not Improve My Situation
Frameworks or Libraries Prescribe Interfaces with Long Parameter Lists
5.4 See Also
Chapter 6. Separate Concerns in Modules
6.1 Motivation
Small, Loosely Coupled Modules Allow Developers to Work on Isolated Parts of the Codebase
Small, Loosely Coupled Modules Ease Navigation Through the Codebase
Small, Loosely Coupled Modules Prevent No-Go Areas for New Developers
6.2 How to Apply the Guideline
Split Classes to Separate Concerns
Hide Specialized Implementations Behind Interfaces
Replace Custom Code with Third-Party Libraries/Frameworks
6.3 Common Objections to Separating Concerns
Objection: Loose Coupling Conflicts With Reuse
Objection: C# Interfaces Are Not Just for Loose Coupling
Objection: High Fan-in of Utility Classes Is Unavoidable
Objection: Not All Loose Coupling Solutions Increase Maintainability
Chapter 7. Couple Architecture Components Loosely
7.1 Motivation
Low Component Dependence Allows for Isolated Maintenance
Low Component Dependence Separates Maintenance Responsibilities
Low Component Dependence Eases Testing
7.2 How to Apply the Guideline
Abstract Factory Design Pattern
7.3 Common Objections to Loose Component Coupling
Objection: Component Dependence Cannot Be Fixed Because the Components Are Entangled
Objection: No Time to Fix
Objection: Throughput Is a Requirement
7.4 See Also
Chapter 8. Keep Architecture Components Balanced
8.1 Motivation
A Good Component Balance Eases Finding and Analyzing Code
A Good Component Balance Better Isolates Maintenance Effects
A Good Component Balance Separates Maintenance Responsibilities
8.2 How to Apply the Guideline
Decide on the Right Conceptual Level for Grouping Functionality into Components
Clarify the System’s Domains and Apply Those Consistently
8.3 Common Objections to Balancing Components
Objection: Component Imbalance Works Just Fine
Objection: Entanglement Is Impairing Component Balance
8.4 See Also
Chapter 9. Keep Your Codebase Small
9.1 Motivation
A Project That Sets Out to Build a Large Codebase Is More Likely to Fail
Large Codebases Are Harder to Maintain
Large Systems Have Higher Defect Density
9.2 How to Apply the Guideline
Functional Measures
Technical Measures
9.3 Common Objections to Keeping the Codebase Small
Objection: Reducing the Codebase Size Is Impeded by Productivity Measures
Objection: Reducing the Codebase Size is Impeded by the Programming Language
Objection: System Complexity Forces Code Copying
Objection: Splitting the Codebase Is Impossible Because of Platform Architecture
Objection: Splitting the Codebase Leads to Duplication
Objection: Splitting the Codebase Is Impossible Because of Tight Coupling
Chapter 10. Automate Tests
10.1 Motivation
Automated Testing Makes Testing Repeatable
Automated Testing Makes Development Efficient
Automated Testing Makes Code Predictable
Tests Document the Code That Is Tested
Writing Tests Make You Write Better Code
10.2 How to Apply the Guideline
Getting Started with NUnit Tests
General Principles for Writing Good Unit Tests
Measure Coverage to Determine Whether There Are Enough Tests
10.3 Common Objections to Automating Tests
Objection: We Still Need Manual Testing
Objection: I Am Not Allowed to Write Unit Tests
Objection: Why Should We Invest in Unit Tests When the Current Coverage Is Low?
10.4 See Also
Chapter 11. Write Clean Code
11.1 Leave No Trace
11.2 How to Apply the Guideline
Rule 1: Leave No-Unit Level Code Smells Behind
Rule 2: Leave No Bad Comments Behind
Rule 3: Leave No Code in Comments Behind
Rule 4: Leave No Dead Code Behind
Rule 5: Leave No Long Identifiers Behind
Rule 6: Leave No Magic Constants Behind
Rule 7: Leave No Badly Handled Exception Behind
11.3 Common Objections to Writing Clean Code
Objection: Comments Are Our Documentation
Objection: Exception Handling Causes Code Additions
Objection: Why Only These Coding Guidelines?
Chapter 12. Next Steps
12.1 Turning the Guidelines into Practice
12.2 Lower-Level (Unit) Guidelines Take Precedence Over Higher-Level (Component) Guidelines
12.3 Remember That Every Commit Counts
12.4 Development Process Best Practices Are Discussed in the Follow-Up Book
Appendix A. How SIG Measures Maintainability
Index
Colophon
