0%

The latest title in Addison Wesley's world-renowned Robert C. Martin Series on better software development, Code That Fits in Your Head offers indispensable practical advice for writing code at a sustainable pace, and controlling the complexity that causes too many software projects to spin out of control.

Reflecting decades of experience consulting on software projects and helping development teams succeed, Mark Seemann shares proven practices and heuristics, supported by realistic advice. His guidance ranges from checklists to teamwork, encapsulation to decomposition, API design to unit testing and troubleshooting.

Throughout, Seemann illuminates his insights with up-to-date code examples drawn from a start to finish sample project. Seemann's examples are written in C#, and designed to be clear and useful to every object-oriented enterprise developer, whether they use C#, Java, or another language. Code That Fits in Your Head is accompanied by the complete code base for this sample application, organized in a Git repository to facilitate further exploration of details that dont fit in the text.

Table of Contents

  1. Cover Page
  2. Title Page
  3. Contents at a Glance
  4. Contents
  5. Preface
    1. 0.1 Who Should Read This Book
    2. 0.2 Organisation
    3. 0.3 A note on the bibliography
    4. 0.4 Acknowledgements
  6. Part I: Acceleration
    1. Chapter 1. Art or Science?
    2. 1.1 Building a house
    3. 1.2 Growing a garden
    4. 1.3 Towards engineering
    5. 1.4 Conclusion
    6. Chapter 2. Checklists
    7. 2.1 An aid to memory
    8. 2.2 Checklist for a new code base
    9. 2.3 Adding checks to existing code bases
    10. 2.4 Conclusion
    11. Chapter 3. Tackling Complexity
    12. 3.1 Purpose
    13. 3.2 Why programming is difficult
    14. 3.3 Towards software engineering
    15. 3.4 Conclusion
    16. Chapter 4. Vertical Slice
    17. 4.1 Start with working software
    18. 4.2 Walking Skeleton
    19. 4.3 Outside-in
    20. 4.4 Complete the slice
    21. 4.5 Conclusion
    22. Chapter 5. Encapsulation
    23. 5.1 Save the data
    24. 5.2 Validation
    25. 5.3 Protection of invariants
    26. 5.4 Conclusion
    27. Chapter 6. Triangulation
    28. 6.1 Short-term versus long-term memory
    29. 6.2 Capacity
    30. 6.3 Conclusion
    31. Chapter 7. Decomposition
    32. 7.1 Code rot
    33. 7.2 Code that fits in your brain
    34. 7.3 Conclusion
    35. Chapter 8. API design
    36. 8.1 Principles of API design
    37. 8.2 API design example
    38. 8.3 Conclusion
    39. Chapter 9. Teamwork
    40. 9.1 Git
    41. 9.2 Collective code ownership
    42. 9.3 Conclusion
  7. Part II: Sustainability
    1. Chapter 10. Augmenting Code
    2. 10.1 Feature flags
    3. 10.2 The Strangler Pattern
    4. 10.3 Versioning
    5. 10.4 Conclusion
    6. Chapter 11. Editing Unit Tests
    7. 11.1 Refactoring unit tests
    8. 11.2 See tests fail
    9. 11.3 Conclusion
    10. Chapter 12. Troubleshooting
    11. 12.1 Understanding
    12. 12.2 Defects
    13. 12.3 Bisection
    14. 12.4 Conclusion
    15. Chapter 13. Separation of Concerns
    16. 13.1 Composition
    17. 13.2 Cross-cutting concerns
    18. 13.3 Conclusion
    19. Chapter 14. Rhythm
    20. 14.1 Personal rhythm
    21. 14.2 Team rhythm
    22. 14.3 Conclusion
    23. Chapter 15. The usual suspects
    24. 15.1 Performance
    25. 15.2 Security
    26. 15.3 Other techniques
    27. 15.4 Conclusion
    28. Chapter 16. Tour
    29. 16.1 Navigation
    30. 16.2 Architecture
    31. 16.3 Usage
    32. 16.4 Conclusion
  8. Appendix A. List of practices
    1. A.1 The 50/72 rule
    2. A.2 The 80/24 rule
    3. A.3 Arrange Act Assert
    4. A.4 Bisection
    5. A.5 Checklist for a new code base
    6. A.6 Command Query Separation
    7. A.7 Count the variables
    8. A.8 Cyclomatic complexity
    9. A.9 Decorators for cross-cutting concerns
    10. A.10 Devil’s Advocate
    11. A.11 Feature flag
    12. A.12 Functional core, imperative shell
    13. A.13 Hierarchy of communication
    14. A.14 Justify exceptions from the rule
    15. A.15 Parse, don’t validate
    16. A.16 Postel’s law
    17. A.17 Red Green Refactor
    18. A.18 Regularly update dependencies
    19. A.19 Reproduce defects as tests
    20. A.20 Review code
    21. A.21 Semantic Versioning
    22. A.22 Separate refactoring of test and production code
    23. A.23 Slice
    24. A.24 Strangler
    25. A.25 Threat-model
    26. A.26 Transformation Priority Premise
    27. A.27 X-driven development
    28. A.28 X out names
  9. Bibliography
18.217.144.32