FrontCover; Refactoring forSoftware DesignSmells; Copyright; Dedication; Contents; Foreword by Grady Booch; Foreword by Dr. Stéphane Ducasse; Preface; WHAT IS THIS BOOK ABOUT?; WHAT DOES THIS BOOK COVER?; WHO SHOULD READ THIS BOOK?; WHAT ARE THE PREREQUISITES FOR READING THIS BOOK?; HOW TO READ THIS BOOK?; WHERE CAN I FIND MORE INFORMATION?; WHY DID WE WRITE THIS BOOK?; Acknowledgments; Chapter 1 -- Technical Debt; 1.1 WHAT IS TECHNICAL DEBT?; 1.2 WHAT CONSTITUTES TECHNICAL DEBT?; 1.3 WHAT IS THE IMPACT OF TECHNICAL DEBT?; 1.4 WHAT CAUSES TECHNICAL DEBT?; 1.5 HOW TO MANAGE TECHNICAL DEBT?;Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing, what design principles were overlooked or misapplied, and what principles need to be applied properly to address those smells through refactoring. Developers and software engineers may ""know"" principles and patterns, but are not aware of the ""smells"" that exist in their design because of wrong or mis-application of principles or patterns. These smells tend to contribute heavily to technical debt - further time owed to fix projects thought to b. FrontCover Refactoring forSoftware DesignSmells Copyright Dedication Contents Foreword by Grady Booch Foreword by Dr. Stéphane Ducasse Preface WHAT IS THIS BOOK ABOUT? WHAT DOES THIS BOOK COVER? WHO SHOULD READ THIS BOOK? WHAT ARE THE PREREQUISITES FOR READING THIS BOOK? HOW TO READ THIS BOOK? WHERE CAN I FIND MORE INFORMATION? WHY DID WE WRITE THIS BOOK? Acknowledgments Chapter 1 -- Technical Debt 1.1 WHAT IS TECHNICAL DEBT? 1.2 WHAT CONSTITUTES TECHNICAL DEBT? 1.3 WHAT IS THE IMPACT OF TECHNICAL DEBT? 1.4 WHAT CAUSES TECHNICAL DEBT? 1.5 HOW TO MANAGE TECHNICAL DEBT? Chapter 2 -- Design Smells2.1 WHY CARE ABOUT SMELLS? 2.2 WHAT CAUSES SMELLS? 2.3 HOW TO ADDRESS SMELLS? 2.4 WHAT SMELLS ARE COVERED IN THIS BOOK? 2.5 A CLASSIFICATION OF DESIGN SMELLS Chapter 3 -- Abstraction Smells 3.1 MISSING ABSTRACTION 3.2 IMPERATIVE ABSTRACTION 3.3 INCOMPLETE ABSTRACTION 3.4 MULTIFACETED ABSTRACTION 3.5 UNNECESSARY ABSTRACTION 3.6 UNUTILIZED ABSTRACTION 3.7 DUPLICATE ABSTRACTION Chapter 4 -- Encapsulation Smells 4.1 DEFICIENT ENCAPSULATION 4.2 LEAKY ENCAPSULATION 4.3 MISSING ENCAPSULATION 4.4 UNEXPLOITED ENCAPSULATION Chapter 5 -- Modularization Smells. 5.1 BROKEN MODULARIZATION5.2 INSUFFICIENT MODULARIZATION 5.3 CYCLICALLY-DEPENDENT MODULARIZATION 5.4 HUB-LIKE MODULARIZATION Chapter 6 -- Hierarchy Smells 6.1 MISSING HIERARCHY 6.2 UNNECESSARY HIERARCHY 6.3 UNFACTORED HIERARCHY 6.4 WIDE HIERARCHY 6.5 SPECULATIVE HIERARCHY 6.6 DEEP HIERARCHY 6.7 REBELLIOUS HIERARCHY 6.8 BROKEN HIERARCHY 6.9 MULTIPATH HIERARCHY 6.10 CYCLIC HIERARCHY Chapter 7 -- The Smell Ecosystem 7.1 THE ROLE OF CONTEXT 7.2 INTERPLAY OF SMELLS Chapter 8 -- Repaying Technical Debt in Practice 8.1 THE TOOLS 8.2 THE PROCESS 8.3 THE PEOPLE. Appendix A -- Software Design PrinciplesA.1 ABSTRACTION A.2 ACYCLIC DEPENDENCIES PRINCIPLE A.3 DON'T REPEAT YOURSELF PRINCIPLE A.4 ENCAPSULATION A.5 INFORMATION HIDING PRINCIPLE A.6 KEEP IT SIMPLE SILLY A.7 LISKOV'S SUBSTITUTION PRINCIPLE A.8 HIERARCHY A.9 MODULARIZATION A.10 OPEN/CLOSE PRINCIPLE A.11 SINGLE RESPONSIBILITY PRINCIPLE A.12 VARIATION ENCAPSULATION PRINCIPLE Appendix B -- Tools for Repaying Technical Debt Appendix C -- Notations for Figures Appendix D -- Suggested Reading D.1 ESSENTIALS D.2 REFACTORING AND REENGINEERING D.3 PATTERNS AND ANTI-PATTERNS. D.4 TECHNICAL DEBTBibliography Index. Awareness of design smells {u2013} indicators of common design problems {u2013} helps developers or software engineers understand mistakes made while designing, what design principles were overlooked or misapplied, and what principles need to be applied properly to address those smells through refactoring. Developers and software engineers may "know" principles and patterns, but are not aware of the "smells" that exist in their design because of wrong or mis-application of principles or patterns. These smells tend to contribute heavily to technical debt {u2013} further time owed to fix projects thought to be complete {u2013} and need to be addressed via proper refactoring. Refactoring for Software Design Smells presents 25 structural design smells, their role in identifying design issues, and potential refactoring solutions. Organized across common areas of software design, each smell is presented with diagrams and examples illustrating the poor design practices and the problems that result, creating a catalog of nuggets of readily usable information that developers or engineers can apply in their projects. The authors distill their research and experience as consultants and trainers, providing insights that have been used to improve refactoring and reduce the time and costs of managing software projects. Along the way they recount anecdotes from actual projects on which the relevant smell helped address a design issue. Contains a comprehensive catalog of 25 structural design smells (organized around four fundamental design principles) that contribute to technical debt in software projects Presents a unique naming scheme for smells that helps understand the cause of a smell as well as points toward its potential refactoring Includes illustrative examples that showcase the poor design practices underlying a smell and the problems that result Covers pragmatic techniques for refactoring design smells to manage technical debt and to create and maintain high-quality software in practice Presents insightful anecdotes and case studies drawn from the trenches of real-world projects Awareness of design smells – indicators of common design problems – helps developers or software engineers understand mistakes made while designing, what design principles were overlooked or misapplied, and what principles need to be applied properly to address those smells through refactoring. Developers and software engineers may "know" principles and patterns, but are not aware of the "smells" that exist in their design because of wrong or mis-application of principles or patterns. These smells tend to contribute heavily to technical debt – further time owed to fix projects thought to be complete – and need to be addressed via proper refactoring.
Refactoring for Software Design Smells presents 25 structural design smells, their role in identifying design issues, and potential refactoring solutions. Organized across common areas of software design, each smell is presented with diagrams and examples illustrating the poor design practices and the problems that result, creating a catalog of nuggets of readily usable information that developers or engineers can apply in their projects. The authors distill their research and experience as consultants and trainers, providing insights that have been used to improve refactoring and reduce the time and costs of managing software projects. Along the way they recount anecdotes from actual projects on which the relevant smell helped address a design issue.
- A comprehensive catalogue of structural design smells and their refactoring solutions to solve problems occurring in design
- Explains the importance of smells in managing technical debt, an area of increased concern at software engineering conferences
- Each smell includes examples, source code, and visualization diagrams to facilitate understanding
- Describes solutions across common software design concepts and smells that cross multiple domains
"Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing, what design principles were overlooked or misapplied, and what principles need to be applied properly to address those smells through refactoring. Developers and software engineers may 'know' principles and patterns, but are not aware of the 'smells' that exist in their design because of wrong or mis-application of principles or patterns. These smells tend to contribute heavily to technical debt - further time owed to fix projects thought to be complete - and need to be addressed via proper refactoring. Refactoring for Software Design Smells presents 25 structural design smells, their role in identifying design issues, and potential refactoring solutions. Organized across common areas of software design, each smell is presented with diagrams and examples illustrating the poor design practices and the problems that result, creating a catalog of nuggets of readily usable information that developers or engineers can apply in their projects. The authors distill their research and experience as consultants and trainers, providing insights that have been used to improve refactoring and reduce the time and costs of managing software projects. Along the way they recount anecdotes from actual projects on which the relevant smell helped address a design issue"--Provided by publisher Refactoring for Software Design Smells, (2015) 259pp. 9780128013977