Beschreibung
This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
Autorenportrait
has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor, Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, C#, Ruby, OO, Design Patterns, UML, Agile Methodologies, and eXtreme programming.
Inhalt
There Will Be Code 2Bad Code 3The Total Cost of Owning a Mess 4Schools of Thought 12We Are Authors 13The Boy Scout Rule 14Prequel and Principles 15Conclusion 15Bibliography 15
Introduction 17Use Intention-Revealing Names 18Avoid Disinformation 19Make Meaningful Distinctions 20Use Pronounceable Names 21Use Searchable Names 22Avoid Encodings 23Avoid Mental Mapping 25Class Names 25Method Names 25Don’t Be Cute 26Pick One Word per Concept 26Don’t Pun 26Use Solution Domain Names 27Use Problem Domain Names 27Add Meaningful Context 27Don’t Add Gratuitous Context 29Final Words 30
Small! 34Do One Thing 35One Level of Abstraction per Function 36Switch Statements 37Use Descriptive Names 39Function Arguments 40Have No Side Effects 44Command Query Separation 45Prefer Exceptions to Returning Error Codes 46Don’t Repeat Yourself 48Structured Programming 48How Do You Write Functions Like This? 49Conclusion 49SetupTeardownIncluder 50Bibliography 52
Comments Do Not Make Up for Bad Code 55Explain Yourself in Code 55Good Comments 55Bad Comments 59Bibliography 74
The Purpose of Formatting 76Vertical Formatting 76Horizontal Formatting 85Team Rules 90Uncle Bob’s Formatting Rules 90Chapter 6: Objects and Data Structures 93Data Abstraction 93Data/Object Anti-Symmetry 95The Law of Demeter 97Data Transfer Objects 100Conclusion 101Bibliography 101
Use Exceptions Rather Than Return Codes 104Write Your Try-Catch-Finally Statement First 105Use Unchecked Exceptions 106Provide Context with Exceptions 107Define Exception Classes in Terms of a Caller’s Needs 107Define the Normal Flow 109Don’t Return Null 110Don’t Pass Null 111Conclusion 112Bibliography 112
Using Third-Party Code 114Exploring and Learning Boundaries 116Learning log4j 116Learning Tests Are Better Than Free 118Using Code That Does Not Yet Exist 118Clean Boundaries 120Bibliography 120
The Three Laws of TDD 122Keeping Tests Clean 123Clean Tests 124One Assert per Test 130F.I.R.S.T. 132Conclusion 133Bibliography 133
Class Organization 136Classes Should Be Small! 136Organizing for Change 147Bibliography 151
How Would You Build a City? 154Separate Constructing a System from Using It 154Scaling Up 157Java Proxies 161Pure Java AOP Frameworks 163AspectJ Aspects 166Test Drive the System Architecture 166Optimize Decision Making 167Use Standards Wisely, When They Add Demonstrable Value 168Systems Need Domain-Specific Languages 168Conclusion 169Bibliography 169
Getting Clean via Emergent Design 171Simple Design Rule 1: Runs All the Tests 172Simple Design Rules 2–4: Refactoring 172No Duplication 173Expressive 175Minimal Classes and Methods 176Conclusion 176Bibliography 176
Why Concurrency? 178Challenges 180Concurrency Defense Principles 180Know Your Library 182Know Your Execution Models 183Beware Dependencies Between Synchronized Methods 185Keep Synchronized Sections Small 185Writing Correct Shut-Down Code Is Hard 186Testing Threaded Code 186Conclusion 190Bibliography 191
Args Implementation 194Args: The Rough Draft 201String Arguments 214Conclusion 250
The JUnit Framework 252Conclusion 265
First, Make It Work 268Then Make It Right 270Conclusion 284Bibliography 284
Comments 286Environment 287Functions 288General 288Java 307Names 309Tests 313Conclusion 314Bibliography 315
Client/Server Example 317Possible Paths of Execution 321Knowing Your Library 326Dependencies Between Methods Can Break Concurrent Code 329Increasing Throughput 333Deadlock 335Testing Multithreaded Code 339Tool Support for Testing Thread-Based Code 342Conclusion 342Tutorial: Full Code Examples 343
