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

ebook

Autor: Joost Visser, Sylvan Rigal, Gijs Wijnholds
ISBN: 978-14-919-5449-2
stron: 172, Format: ebook
Data wydania: 2016-06-08
Księgarnia: Helion

Cena książki: 84,92 zł (poprzednio: 98,74 zł)
Oszczędzasz: 14% (-13,82 zł)

Osoby, które kupiły tę książkę, wybierały także »

Tagi: C# - Programowanie

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 constructors
Write simple units of code: limit the number of branch points per method
Write code once, rather than risk copying buggy code
Keep unit interfaces small by extracting parameters into objects
Separate concerns to avoid building large classes
Couple architecture components loosely
Balance the number and size of top-level components in your code
Keep your codebase as small as possible
Automate tests for your codebase
Write clean code, avoiding "code smells" that indicate deeper problems

Osoby które kupowały "Building Maintainable Software, C# Edition. Ten Guidelines for Future-Proof Code", wybierały także:

C# 9.0 w pigułce 173,87 zł, (53,90 zł -69%)
Gray Hat C#. Język C# w kontroli i łamaniu zabezpieczeń 57,74 zł, (17,90 zł -69%)
ASP.NET Core 6. Kurs video. Rozwijaj aplikacje webowe z Entity Framework Core 179,00 zł, (71,60 zł -60%)
Platforma Xamarin. Kurs video. Poziom drugi. Zaawansowane techniki tworzenia aplikacji cross-platform 99,00 zł, (39,60 zł -60%)
Testowanie automatyczne w .NET. Kurs video. Zastosowania frameworka nUnit 169,00 zł, (76,05 zł -55%)

Spis treści

Building Maintainable Software, C# Edition. Ten Guidelines for Future-Proof Code eBook -- spis treści

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
1. Introduction
- What Is Maintainability?
  - The Four Types of Software Maintenance
- Why Is Maintainability Important?
  - Maintainability Has Significant Business Impact
  - Maintainability Is an Enabler for Other Quality Characteristics
- 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
- 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
- Rating Maintainability
- An Overview of the Maintainability Guidelines
2. Write Short Units of Code
- Motivation
  - Short Units Are Easy to Test
  - Short Units Are Easy to Analyze
  - Short Units Are Easy to Reuse
- How to Apply the Guideline
  - When Writing a New Unit
  - When Extending a Unit with New Functionality
  - Using Refactoring Techniques to Apply the Guideline
    - Refactoring technique: Extract Method
    - Refactoring technique: Replace Method with Method Object
- 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
- See Also
3. Write Simple Units of Code
- Motivation
  - Simple Units Are Easier to Modify
  - Simple Units Are Easier to Test
- How to Apply the Guideline
  - Dealing with Conditional Chains
  - Dealing with Nesting
- Common Objections to Writing Simple Units of Code
  - Objection: High Complexity Cannot Be Avoided
  - Objection: Splitting Up Methods Does Not Reduce Complexity
- See Also
4. Write Code Once
- Types of Duplication
- Motivation
  - Duplicated Code Is Harder to Analyze
  - Duplicated Code Is Harder to Modify
- How to Apply the Guideline
  - The Extract Superclass Refactoring Technique
- 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
- See Also
5. Keep Unit Interfaces Small
- Motivation
  - Small Interfaces Are Easier to Understand and Reuse
  - Methods with Small Interfaces Are Easier to Modify
- How to Apply the Guideline
- 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
- See Also
6. Separate Concerns in Modules
- 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
- How to Apply the Guideline
  - Split Classes to Separate Concerns
  - Hide Specialized Implementations Behind Interfaces
  - Replace Custom Code with Third-Party Libraries/Frameworks
- 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
7. Couple Architecture Components Loosely
- Motivation
  - Low Component Dependence Allows for Isolated Maintenance
  - Low Component Dependence Separates Maintenance Responsibilities
  - Low Component Dependence Eases Testing
- How to Apply the Guideline
  - Abstract Factory Design Pattern
- 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
- See Also
8. Keep Architecture Components Balanced
- 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
- How to Apply the Guideline
  - Decide on the Right Conceptual Level for Grouping Functionality into Components
  - Clarify the Systems Domains and Apply Those Consistently
- Common Objections to Balancing Components
  - Objection: Component Imbalance Works Just Fine
  - Objection: Entanglement Is Impairing Component Balance
- See Also
9. Keep Your Codebase Small
- 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
- How to Apply the Guideline
  - Functional Measures
  - Technical Measures
- 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
10. Automate Tests
- 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
- 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
- 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?
- See Also
11. Write Clean Code
- Leave No Trace
- 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
    - Unreachable code in methods
    - Unused private methods
    - Code in comments
  - Rule 5: Leave No Long Identifiers Behind
  - Rule 6: Leave No Magic Constants Behind
  - Rule 7: Leave No Badly Handled Exception Behind
- Common Objections to Writing Clean Code
  - Objection: Comments Are Our Documentation
  - Objection: Exception Handling Causes Code Additions
  - Objection: Why Only These Coding Guidelines?
12. Next Steps
- Turning the Guidelines into Practice
- Lower-Level (Unit) Guidelines Take Precedence Over Higher-Level (Component) Guidelines
- Remember That Every Commit Counts
- Development Process Best Practices Are Discussed in the Follow-Up Book
A. How SIG Measures Maintainability
Index