Chapter 24. Refactoring

< Free Open Study >

Chapter 24. Refactoring cc2e.com/2436 Contents Kinds of Software Evolution page 564 Introduction to Refactoring page 565 Specific Refactorings page 571 Refactoring Safely page 579 Refactoring Strategies page 582 Related Topics Tips for fixing defects: Section 23.3 Code-tuning approach: Section 25.6 Design in construction: Chapter 5 Working classes: Chapter 6 High-quality routines: Chapter 7 Collaborative construction: Chapter 21 Developer testing: Chapter 22 Areas likely to change: "Identify Areas Likely to Change" in Section 5.3 Myth: a well-managed software project conducts methodical requirements development and defines a stable list of the program's responsibilities. Design follows requirements, and it is done carefully so that coding can proceed linearly, from start to finish, implying that most of the code can be written once, tested, and forgotten. According to the myth, the only time that the code is significantly modified is during the software-maintenance phase, something that happens only after the initial version of a system has been delivered. All successful software gets changed. �Fred Brooks Reality: code evolves substantially during its initial development. Many of the changes seen during initial coding are at least as dramatic as changes seen during maintenance. Coding, debugging, and unit testing consume between 30 to 65 percent of the effort on a typical project, depending on the project's size. (See Chapter 27, "How Program Size Affects Construction," for details.) If coding and unit testing were straightforward processes, they would consume no more than 20�30 percent of the total effort on a project. Even on well-managed projects, however, requirements change by about one to four percent per month (Jones 2000). Requirements changes invariably cause corresponding code changes�sometimes substantial code changes. Another reality: modern development practices increase the potential for code changes during construction. In older life cycles, the focus�successful or not�was on avoiding code changes. More modern approaches move away from coding predictability. Current approaches are more code-centered, and over the life of a project, you can expect code to evolve more than ever.

< Free Open Study >