Nguồn ngoài
Object-Oriented Reengineering Patterns
This text is a guide on how to reverse engineer legacy systems to understand their problems, and then reengineer those systems to meet new demands. Patterns are used to clarify and explain the process of understanding large code bases, to transform them to meet new requirements. The key insight is that the right design and organization of your system is not something that can be evident from the initial requirements alone, but as a consequence of understanding how these requirements evolve.
- Tác giả
- Serge Demeyer, Stéphane Ducasse, & Oscar Nierstrasz
- Nhà xuất bản
- LibreTexts
- Nguồn
- LibreTexts
- Giấy phép
- CC BY-SA
- Ngôn ngữ
- EN
- Danh mục
- Công nghệ thông tin
Mục lục· 77 mục
- 01: Reengineering Patterns
- 1.01: Why do we Reengineer
- 1.02: The Reengineering Lifecycle
- 1.03: Reengineering Patterns
- 1.04: The Form of a Reengineering Pattern
- 1.05: A Map of Reengineering Patterns
- 02: Setting Direction
- 2.01: Setting Direction
- 2.02: Agree on Maxims
- 2.03: Appoint a Navigator
- 2.04: Speak to the Round Table
- 2.05: Most Valuable First
- 2.06: Fix Problems Not Symptoms
- 2.07: If It Aint Broke Dont Fix It
- 2.08: Keep It Simple
- 03: First Contact
- 3.01: First Contact
- 3.02: Chat with the Maintainers
- 3.03: Read all the Code in One Hour
- 3.04: Skim the Documentation
- 3.05: Interview During Demo
- 3.06: Do a Mock Installation
- 04: Initial Understanding
- 4.01: Initial Understanding
- 4.02: Analyze the Persistent Data
- 4.03: Speculate about Design
- 4.04: Study the Exceptional Entities
- 05: Detailed Model Capture
- 5.01: Detailed Model Capture
- 5.02: Tie Code and Questions
- 5.03: Refactor to Understand
- 5.04: Step Through the Execution
- 5.05: Look for the Contracts
- 5.06: Learn from the Past
- 06: Tests Your Life Insurance
- 6.01: Tests Your Life Insurance
- 6.02: Write Tests to Enable Evolution
- 6.03: Grow Your Test Base Incrementally
- 6.04: Use a Testing Framework
- 6.05: Test the Interface Not the Implementation
- 6.06: Record Business Rules as Tests
- 6.07: Write Tests to Understand
- 07: Migration Strategies
- 7.01: Migration Strategies
- 7.02: Involve the Users
- 7.03: Build Confidence
- 7.04: Migrate Systems Incrementally
- 7.05: Prototype the Target Solution
- 7.06: Always Have a Running Version
- 7.07: Regression Test After Every Change
- 7.08: Make a Bridge to the New Town
- 7.09: Present the Right Interface
- 7.10: Distinguish Public from Published Interface
- 7.11: Deprecate Obsolete Interfaces
- 7.12: Conserve Familiarity
- 7.13: Use Profiler Before Optimizing
- 08: Detecting Duplicated Code
- 8.01: Detecting Duplicated Code
- 8.02: Compare Code Mechanically
- 8.03: Visualize Code as Dotplots
- 09: Redistribute Responsibilities
- 9.01: Redistribute Responsibilities
- 9.02: Move Behavior Close to Data
- 9.03: Eliminate Navigation Code
- 9.04: Split Up God Class
- 10: Transform Conditionals to Polymorphism
- 10.01: Transform Conditionals to Polymorphism
- 10.02: Transform Self Type Checks
- 10.03: Transform Client Type Checks
- 10.04: Factor out State
- 10.05: Factor out Strategy
- 10.06: Introduce Null Object
- 10.07: Transform Conditionals into Registration
- 11: Appendix A Thumbnail Patterns
- 11.01: Testing Patterns
- 11.02: Refactorings
- 11.03: Design Patterns