Building Maintainable Software, C# Edition Ten Guidelines for Future-Proof Code

Description

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 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