|
Presented by Algis Rudys
Refactoring is a reference and tutorial for refactoring code. It contains a description of what refactoring is and how and when to refactor code. It also contains a catalog of refactorings one can apply as well as a guide to when to apply them. Chapter one is meant to introduce the idea of refactoring. It does this by way of example. The example starts out as a very short toy object-oriented program. Over the course of the chapter, Fowler applies refactorings to the program in the process of adding capabilities. The final program has a much cleaner design. This chapter is meant to answer the question What is refactoring? Chapter two is a more philosophical discussion of refactoring. It contains the first explanation of refactoring. In addition to this definition, it explains why refactoring is a useful. Fowler says that rather than being a silver bullet, refactoring is more like silver pliers (gotta love them bad metaphors), letting you hold on to the code. Issues such as how to convince the management to buy into refactoring (my favorite suggestion: Don't tell) and how refactoring fits with the idea of designing the system are addressed. Finally, it contains some possible pitfalls, as well as a discussion of performance issues in conjunction with refactoring. This chapter is meant to answer the question Why should I refactor? Chapter three gives a partial taxonomy of clues that a class should be refactored. Fowler and Beck introduce the notion of smells: certain patterns that suggest that a refactoring may be in order. They present these one-at-a-time, and discusses the appropriate refactorings that should be applied in each case. While they don't operate on examples, the point they are trying to make is generally clear. This chapter is meant to answer the question When/Which code should I refactor? Chapter four takes a brief segue: refactoring depends on automated testing suites, and this chapter is a brief introduction to writing such suites. Fowler uses Gamma and Beck's JUnit testing framework in these examples. His technical advice is obvious to any moderately experienced programmer; the main contribution of this chapter is that automated testing can be easy. With chapter five, the Refactoring becomes a reference book. Chapters five through 12 contain a catalog of the various refactorings one can apply to code. The catalog describes each refactoring, and gives examples. It explains the rationale behind the refactoring, and when not to apply the refactoring. Perhaps most useful, it gives a step-by-step howto for applying the refactoring, including when to compile and test (sometimes multiple times) to make sure you haven't messed up. Chapter 13 begins a series of essays by the various co-authors. Chapter 13 several different issues in refactoring, including real-world issues. Chapter 14 covers tools for refactoring code. Finally, Beck concludes with chapter 15: Putting It All Together. The book is fairly well-written, and not at all a boring read (I tried to read myself to sleep with it, and failed). It has a very conversational tone about it that makes for easy and fast reading. The books technical content is equally well written. The examples are clear and well-explained. While the content is targetted to Java, its applicability to any object-oriented language and indeed to other languages as well is clear. The technical descriptions are clear, descriptive without getting bogged down in the technical detail. The conversational tone helps here. This book is incredibly useful to anyone who plans to employ refactoring as a part of their daily coding regimen. arudys@rice.eduLast modified: Fri Feb 1 02:28:55 CST 2002 |