Refactoring (Ruby Version)
Basic Information
Original Title: refactoring: Ruby Edition
Original Press: Addison-Wesley professional
Author: (US) Jay fields Jon Harvie Martin Fowler [Translator's introduction]
Translator: Xu Xuming [same translator's work]
Series name: Professional Technical Series for developers
Press: Machinery Industry Press
ISBN: 9787111300786
Mounting time:
Published on: February 1, April 2010
Start: 16
For more details, see: http://www.china-pub.com/196681
Introduction
This book is a refactoring guide specially designed for professional Ruby programmers. Its goal is to show you how to refactor in a strictly controlled and efficient way. You will learn how to introduce bugs in your code and improve the structure reconstruction method step by step. The main content of this book: Chapter 1 points out what refactoring is; Chapter 2 discusses the reasons for restructuring; Chapter 1st points out the signals for restructuring; chapter 2 discusses the important role of testing in refactoring; chapter 2 ~ Chapter 2 introduces the rebuild roster, which includes achievements in the rebuild field so far. When a task is required, this roster will remind us of our safe practices.
This book is a major new version of Martin Fowler's classic authoritative book refactoring, and uses Ruby as an example to completely rewrite it-not just to move the code from the Java version.
The book provides a detailed rebuild roster, containing over 70 refined Ruby rebuild technologies, each with detailed instructions, usage details, and sample code. Many of the refactoring technologies use Ruby's proprietary powerful features. You can download all the code from the Chinese chapter website.
The author used Fowler's initial ideas to demonstrate how to refactor in a controlled, efficient, and iterative manner, helping you improve the quality of your code in an orderly manner without introducing new bugs. This book is an indispensable reference for writing and maintaining Ruby code. Contents
Understand the core principles of refactoring and the reasons for restructuring
Discovering "Bad taste" in Ruby code"
Gradually turn poor design into well-designed code
Build tests to ensure correct refactoring
Understanding the difficulties in reconstruction and Solutions
Compile correct packaging code
Move the feature between objects and place it in the most appropriate place
Organize data into easier forms for processing
Simplified conditional expressions, more efficient use of Polymorphism
Create interfaces that are easier to understand and use
Large refactoring, which may affect the entire software system for months or even years
Successfully restructured the Ruby on Rails code.
Directory
Translator's preface
Collation
Preface
Thank you
Chapter 4 reconstruction of initial experience
1.1 starting point
1.1.1movie
1.1.2marshal
1.1.3customer
1.1.4 evaluation of the starting procedure
1.2 reconstruction Step 1
1.3statement method decomposition and combination
1.3.1 Calculation of mobile amount
1.3.2 refining the calculation of frequent customer points
1.3.3 remove temporary variables
1.4 Replace the conditional logic in the price code with Polymorphism
Conclusion 1.5
Chapter 1 Basic Principles of restructuring
2.1 The Origin of refactoring
2.2 Definition of refactoring
. 2.3 reasons for refactoring
2.3.1 Refactoring can improve the software design
2.3.2 refactoring makes software easy to understand
2.3.3 refactoring helps you discover bugs
2.3.4 Refactoring can help you program faster
2.4 reconstruction time
2.4.1 event 3
2.4.2 refactoring when adding features
2.4.3 refactoring when Bugs need to be fixed
2.4.4 refactoring during code review
2.4.5 Refactoring for better understanding (or restructuring towards the same goal)
2.5 why does refactoring work?
2.6 What should I tell my manager?
2.7 abstraction and Reconstruction
2.8 reconstruction problems
2.8.1 interface change
2.8.2 Database
2.8.3 design changes that are difficult to reconstruct
2.8.4 when should I refactor?
2.9 reconstruction and Design
2.10.
2.11 refactoring and Performance
2.12 optimize the salary system
Chapter 1 bad taste in code
3.1 duplicate code
3.2 The method is too long
3.3 category is too large
3.4 The parameter list is too long
3.5 transmission type changes
3.6 modify elastic
3.7 feature dependency
3.8 data dashboard
3.9 basic type paranoia
3.10case statement
3.11 parallel Inheritance System
3.12 million redundant category
3.13 generalization of pure speculation
3.14 temporary Fields
3.15 message chain
3.16 man-in-the-middle
3.17 too close
3.18 similar classes
3.19 imperfect Class Libraries
3.20 Data Type
3.21 rejected gifts
3.22 annotations
3.23 avid meta-Programming
3.24 disconnected APIs
3.25 repeated sample texts
Chapter 2 Build Test
4.1 Value of self-testing code
4.2test testing unit testing framework
4.3 programmer testing and quality assurance testing
4.4 Add more tests
Chapter 4 reconstruction roster
5.1 reconstruction format
5.2 search for references
Chapter 4 Organization Method
6.1 Extraction Method
6.1.1 motivation
6.1.2 Method
6.1.3 example: no local variables
6.1.4 example: use local variables
6.1.5 example: assign a value to a local variable again
6.2 join method
6.2.1 motivation
6.2.2 Method
6.3 connecting temporary variables
6.3.1 motivation
6.3.2 Method
6.4 replace temporary variables with queries
6.4.1 motivation
6.4.2 Method
6.4.3 example
6.5 replace temporary variables with chained calls
6.5.1 motivation
6.5.2 Method
6.5.3 example
6.6 introduce explanatory variables
6.6.1 motivation
6.6.2 procedure
6.6.3 example
6.6.4 methods of extraction
6.7 break down temporary variables
6.7.1 motivation
6.7.2 procedure
6.7.3 example
6.8 remove the parameter value
6.8.1 motivation
6.8.2 Method
6.8.3 example
6.9 method object replacement method
6.9.1 motivation
6.9.2 procedure
6.9.3 example
6.10 replacement algorithm
6.10.1 motivation
6.10.2 Method
6.11 use the set closure method to replace Loops
6.11.1 motivation
6.11.2 Method
6.11.3 example
6.12 refining surround Methods
6.12.1 motivation
6.12.2 Tactics
6.12.3 example
6.13 introduce class labels
6.13.1 motivation
6.13.2 Method
6.13.3 example
6.14 introduce named Parameters
6.14.1 motivation
6.14.2 Method
6.14.3 Example 1: Name all parameters
6.14.4 Example 2: only name the optional parameter
6.15 remove named Parameters
6.15.1 motivation
6.15.2 Method
6.15.3 example
6.16 Remove unused default parameters.
6.16.1 motivation
6.16.2 Method
6.16.3 example
6.17 dynamic method definition
6.17.1 motivation
6.17.2 Method
6.17.3 example: Use def_each to define similar methods
6.17.4instance _ exec Method
6.17.5 example: Use class annotation to define the instance method
6.17.6 example: Define a method by extending a dynamically defined Module
6.18 replace a dynamic receiver with a dynamic method definition
6.18.1 motivation
6.18.2 Method
6.18.3 example: Do not use method_missing for dynamic Delegation
6.18.4 example: use custom data to define a method
6.19 isolate dynamic Receivers
6.19.1 motivation
6.19.2 Method
6.19.3 example
6.20 move computing from runtime to DNS
6.20.1 motivation
6.20.2 procedure
Chapter 4 moving between objects
7.1 moving Method
7.1.1 motivation
7.1.2 Method
7.1.3 example
7.2 move a field
7.2.1 motivation
7.2.2 Method
7.2.3 example
7.2.4 example: use self-encapsulation
7.3 Refining
7.3.1 motivation
7.3.2 Method
7.3.3 example
Networking within 7.4
7.4.1 motivation
7.4.2 Method
7.4.3 example
7.5 hide Delegation
7.5.1 motivation
7.5.2 Method
7.5.3 example
7.6 remove man-in-the-middle
7.6.1 motivation
7.6.2 Method
7.6.3 example
Chapter 4 Organization data
8.1 self-encapsulated Fields
8.1.1 motivation
8.1.2 Method
8.1.3 example
8.2 replace data values with objects
8.2.1 motivation
8.2.2 Method
8.2.3 example
8.3 change the value object to a reference object
8.3.1 motivation
8.3.2 Method
8.3.3 example
8.4 change the referenced object to a value object
8.4.1 motivation
8.4.2 Method
8.4.3 example
8.5 Replace arrays with objects
8.5.1 motivation
8.5.2 Method
8.5.3 example
8.5.4 use deprecation for refactoring
8.6 replace hash with objects
8.6.1 motivation
8.6.2 Method
8.6.3 example
8.7 change one-way Association to two-way Association
8.7.1 motivation
8.7.2 Method
8.7.3 example
8.8 change bidirectional Association to unidirectional Association
8.8.1 motivation
8.8.2 Method
8.8.3 example
8.9 Replace the magic number with the symbol constant
8.9.1 motivation
8.9.2 Method
8.10 encapsulation set
8.10.1 motivation
8.10.2 Method
8.10.3 example
8.10.4 move the behavior into the class
8.11 use data to replace records
8.11.1 motivation
8.11.2 Method
8.12 replace type codes with Polymorphism
8.12.1 motivation
8.12.2 remove conditional Logic
8.12.3 Method
8.12.4 example
8.13 Replace the type code with the module Extension
8.13.1 motivation
8.13.2 Method
8.13.3 example
8.14 use status or policy mode to replace type codes
8.14.1 motivation
8.14.2 Method
8.14.3 example
8.15 use fields to replace subclass
8.15.1 motivation
8.15.2 Method
8.15.3 example
8.16 properties of inert Initialization
8.16.1 motivation
8.16.2 Method
8.16.3