Reconstruction: improve the design of existing code (commentary version); Comment sort

Reconstruction: improve the design of existing code (commentary version); Comment sort

 

Comments sort

In the past decade, it has been difficult to bypass martinfowler's classic book to discuss how to improve the quality of code. This book has already influenced several generations of programmers, and may continuously influence a group of future programmers. Unfortunately, in reality, we still see the difficulty of restructuring. On the one hand, it is because the refactoring skills of programmers are still to be honed, and on the other hand, it is because of Project pressure that we often regard refactoring as a chicken rib.

Is refactoring dispensable? Andyhunt, author of practicesof an agile developer, believes that "it takes time and effort to keep the code Clean and bright. In the project, the code should be brilliant, and there should be no darkness ." I believe that programmers who have maintained the legacy code will feel "at ease" in the face of ambiguous and complex and chaotic code. Refactoring is an effective way to clean up code spam. It helps to create a clear program structure, consistent code style, and effective reuse of duties, it can find the beauty of code between simplicity and complexity, weigh the code quality and development efficiency reasonably, and promote code to the realm of elegant coding.

How to present the beauty of refactoring? The key is to find ugly and intolerable. Hate for ugliness is actually a powerful driving force that will drive you to use refactoring until it turns into a natural and indispensable breath. Reconstruction can be performed anytime, anywhere, without special stages. Regular refactoring ensures that the code is always updated, such as sharp. The practice of ignoring the code quality in order to pursue the development speed in a single way is actually a killer. The expected result is that the system's "broken windows" gradually spread, finally, the end is unmanageable. Refactoring is not unfeasible. The key lies in our attitude towards refactoring and the habit of using refactoring. We must recognize the importance of refactoring in our thinking. Then, we must constantly improve refactoring skills in terms of skills and use refactoring tools to maximize the positive side of refactoring in software development.

To improve refactoring skills, you must read this book without exception. So, is there a need to comment on such a classic? Are we doing anything stupid? Martinfowler has done a good job. Is any comment a cool? Not all! As a Ratcher, if I am satisfied with posting irrelevant words in the corner of the book, I should not comment on such comments. When I started my comments on this book, I positioned myself as: I am not a reviewer, and I am a creator. In the course of commenting on this book, I wrote my own book.

Most of the comments in this book are not just words. Many of them are self-built experiences and the use of refactoring techniques. I read a lot of books, for example, "Programmer Cultivation", "Reconstruction and mode", "field-driven design", "anti-pattern", "Art of software architecture", "Art of code modification"," more than 10 related books, such as the clean code. After all, from the perspective of the Software world, martinfowler's book writing age is already quite old. After that, many wonderful design techniques, reconstruction ideas and methods were created. For example, in the content related to refactoring, this book has not discussed such content as architecture reconstruction, interface reconstruction, database reconstruction, and reconstruction mode. During the review, I hope to provide an open description of my experience in reading this book, describe my own experience of restructuring, and give my own opinions and opinions within the scope of my ability.

As a programmer, I have seen many colleagues who ignore or ignore spam code, including me. But when I got stuck in the pain of the legacy code, it became a pain point for this situation. In recent years, the implementation of software technology and agile methods in the software industry has improved people's views to some extent, but it is still difficult to implement it. The biggest reason is that we position programmers as "code workers" and think that coding is the responsibility of low-end programmers. We attempted to create a "software factory" in the machinery manufacturing industry, but ignored the artistic aspect of software programming. I always think that code is still part of the architecture. Code quality determines the architecture quality, while refactoring is the source of life that delays the aging of the system. The so-called "a journey of thousands of miles begins with a single step", let the reconstruction journey begin with this book.

 

 

Collation

The concept of "refactoring" comes from the Smalltalk circle, and it won't be long before it enters the other language camp. Since refactoring is an indispensable part of framework development, this term is born when framework developers discuss their work. When they refine their class inheritance system and yell at how many lines of code they can take away, the concept of refactoring gradually emerges. Framework designers know that this is not exactly the right thing at the beginning. It will evolve as the designer's experience grows. They also know that, code is read and modified much more than it is written. The key to keeping code readable and easy to modify is refactoring-so for the framework and for general software.

Great. What's the problem? Obviously, refactoring is risky. It must modify the program in operation, which may introduce some imperceptible errors. If the refactoring method is inappropriate, it may destroy the results of several days or even weeks. If you are not prepared for the reconstruction and do not comply with the rules, the risk will be even greater. You mine your own code and soon find something worth modifying, So you dig deeper. The deeper you dig, the more reconstruction opportunities you will find, and the more modifications you will make ...... Finally, you dug a big hole for yourself, but you couldn't climb it. To avoid self-digging, reconstruction must be systematic. I mentioned to three other authors in the design patterns book that design patterns provide a goal for refactoring. However, "determining goals" is only part of the problem. It is another difficulty to transform the program to achieve the goal.

Martin Fowler and several other authors in this book clearly reveal the refactoring process, and their contributions to object-oriented software development are hard to measure. This book explains the principles and best practices of refactoring, and points out when and where you should start mining your code for improvement. The core of this book is a series of complete reconstruction methods, each of which introduces the motives and technologies of a code transformation technique tested in practice. Some projects such as extractmethod and move field may seem simple, but do not take it lightly, because understanding these technologies is the key to an orderly refactoring. The refactoring techniques mentioned in this book will help you modify your code in a small step, which reduces the risks in the process. Soon you will add these refactoring techniques and their names to your development dictionary, and you will be able to speak with each other.

For the first time, I experienced a very small step of restructuring. It was a pair of programming with kentbeck on a 30-000 feet high-altitude flight trip. We use the reconstruction techniques included in this book to ensure that we only take one step at a time. Finally, I was very surprised by the effect of this practice. I am not only more confident in the final result, but also have a lot less development pressure. Therefore, I strongly recommend you try these refactoring methods, so both you and your program will be better.

 

Erichgamma

First author of design pattern, main architect of eclipse Platform

Xiong Jie Translation

Preface

Once upon a time, a consultant visited the customer to investigate the development project. The core of the system is a class inheritance system. The consultant reads some code written by developers. He found that the entire system was quite messy. The upper superclasses made some assumptions about the system's operation, and the lower classes implemented these assumptions. However, these assumptions are not suitable for all subclasses, resulting in override workload. As long as you modify the superclass, a lot of overwrite work can be reduced. In other places, some intent of the superclass is not well understood, so some actions are repeated in the subclass. There are also some places where several sub-classes can actually move them to the upper layer of the inheritance system to do the same thing.

The consultant suggested the project manager to look at the code and sort it out, but the manager was not keen on it. After all, the program seemed to run, and the project was facing great progress pressure. The manager said that he would spend more time organizing the work later.

The consultant also told the programmers who work on the inheritance system about his ideas and what they might do. Programmers are very keen to see the seriousness of the problem immediately. They know that this is not all their faults. Sometimes they do need to use external forces to discover problems. The programmer immediately spent one or two days organizing the inheritance system and deleting half of the Code. They are very satisfied with this and find that adding new classes to the inheritance system or using other classes in the system is faster and easier.

The project manager is not happy. The progress is very tight and there is a lot of work to do. The system must be released a few months later, but these Programmers spend two days in vain. The work they do has nothing to do with most of the features to be delivered. The original code is still running normally, and their new design seems to be a bit too perfect. The project must be delivered to the customer. The code that can be effectively run is not perfect for your study. The consultant then suggested that such sorting should be conducted in other core components of the system, which would pause the entire project for one to two weeks. All this work is to make the Code look more beautiful and not to add any new features to the system.

What do you think of this story? Do you think this consultant's suggestion (further organizing the program) is correct? Will you follow the old engineering proverb: "If it can still run, don't touch it ."

I must admit that I have some prejudice, because I am the consultant. Six months later, the project was declared a failure, because the code was too complex to debug or obtain acceptable performance.

Later, the project was restarted and the entire system was written from scratch. kentbeck was invited as a consultant. He has done a few different things from the past. One of the most important is to insist on constantly refactoring behavior to sort out the code. The success of this project and the role of restructuring in this successful project inspired me to write this book, in this way, I will be able to spread the knowledge Kent and others have learned about "Improving Software Quality in reconstruction" to all readers.

What is refactoring?

Refactoring is a process in which code is modified without changing the external behavior of the Code to improve the internal structure of the program. Refactoring is an orderly Program Arrangement Method formed by thousands of refining, which can minimize the probability of errors introduced during the arrangement. In essence, refactoring is to improve its design after the code is written.

It's a bit strange to say "improve its design after the code is written. According to our current understanding of software development, we believe that we should first design and then code: first, we must have a good design before we can start coding. However, as time passes, people constantly modify the code, so the overall structure of the system gradually decreases according to the original design. The quality of the Code is slowly sinking, and the coding work has fallen from rigorous engineering to simple behavior.

"Refactoring" is the opposite. Even if you have a bad design, or even a bunch of messy code, you can also process it into well-designed code by refactoring. Every reconstruction step is very simple, or even a little too simple: you only need to move a field from one class to another class, and pull some code from one function to form another function, or you can simply push some code down in the inheritance system. However, with the accumulation of these small modifications, the design quality can be fundamentally improved. This is the opposite of the common idea that "software will slowly rot.

Through refactoring, you can find the balance point of change. You will find that the so-called design is no longer a prerequisite for all actions, but gradually emerges throughout the development process. In the process of building a system, you can learn how to enhance the design, and the interaction that comes with it allows a program to maintain a good design in the development process.

What does this book have?

This book is a refactoring guide written for professional programmers. My goal is to tell you how to refactor in a controllable and efficient way. You will learn how to improve the program structure in an orderly manner without introducing errors. This is the correct refactoring method.

Traditionally, books should begin with an introduction. Although I agree with this principle, it is not easy to introduce refactoring with a general discussion or definition. So I decided to use an instance as a pioneer. Chapter 2 shows a small program, which has some common design defects. I refactor it into a more qualified object-oriented program. In the meantime, we can see the reconstruction process and several useful reconstruction techniques. If you want to know what exactly refactoring is, this chapter cannot be read.

Chapter 2 discusses the general principles, definitions, and causes of refactoring. I also roughly introduced some problems existing in refactoring. In Chapter 2, kentbeck describes how to sniff out the "bad taste" in the Code and how to use refactoring to clear the bad taste. Testing plays a very important role in refactoring. Chapter 4th describes how to use a simple and open-source Java testing framework to build a testing environment in code.

The core part of this book-restructuring the list-is extended from Chapter 5th to Chapter 12th. It cannot be said to be a comprehensive list, but it's just a start, including all the refactoring techniques I 've sorted out so far at work. Whenever I want to do something like replaceconditional with polymorphism (245), this list will remind me how to proceed securely step by step. I hope this is part of your review.

This book introduces many of the research achievements of others. The last few chapters are written by several of them. In Chapter 13th, billopdyke describes some problems he encountered when applying refactoring technology to commercial development. In Chapter 2, donrobert TS and John Brant look forward to the future of refactoring technology-automated tools. I leave the last chapter (chapter 15th) to kentbeck, the top master of refactoring technology, to compress the axis.

Use refactoring in Java

Examples of this book are all written in Java. Refactoring can also be implemented in other languages, and I also hope this book can help other language users. But I think I 'd better use only Java in this book, because it is my most familiar language. I will write some tips from time to tell readers how to refactor in other languages, but I really hope that others will write more refactoring books for other languages based on this book.

To better communicate with readers about my ideas, I did not use a particularly complicated part of the Java language. Therefore, I avoid using embedded classes, reflection mechanisms, threads, and many powerful Java features. This is because I want to display the core of refactoring as clearly as possible.

I should remind you that these refactoring methods are not for concurrent or distributed programming. Those theme will lead to more consideration, which is not covered in this book.

Who should read this book?

The target reader of this book is a professional programmer, who makes a living by writing software. Examples and discussions in this book involve a lot of code that requires reading and understanding in detail. These examples are written in Java. Java is chosen because it is a widely used language and can be easily understood by anyone with a C background. Java is an object-oriented language, and the object-oriented mechanism is very helpful for refactoring.

Although the focus on objects is code, refactoring has a huge impact on system design. It is also necessary for senior designers and architects to understand the refactoring principles and to use the refactoring technology in their own projects. It is best to introduce refactoring technology by experienced and experienced developers, because such a person can fully understand the principles behind refactoring and adjust it based on the situation so that it can be applied to specific work areas. This is especially important if you are not using Java, because you must rewrite the example I provided in other languages.

I want to tell you how to make full use of the book without reading it.

Q if you want to know what the Refactoring is, read chapter 1st. The example will let you know the refactoring process.

Q if you want to know why rebuild should be done, read chapter 2 and Chapter 2. They tell you what the Refactoring is and why it should be.

Q if you want to know where to refactor, please read chapter 3rd. It will tell you some code features, which indicate "reconstruction is required here ".

Q if you want to start refactoring, please read the full section 1st ~ Chapter 4, and then read the refactoring list selectively. In the beginning, you only need to roughly browse the list to see what is in it, so you don't have to understand all the details. Once a guideline needs to be implemented, read it in detail to get help. The list part is the reference content for reference. You don't have to read it all at once. In addition, you should read the "guest chapter" of other authors after the read list, especially chapter 15th.

Standing on the shoulders of our predecessors

At the beginning of this book, I must say: This book owes me a lot of debt, it owes a lot to those who have done a lot of research work over the past decade and created a reconstruction field. This book should have been written by one of them, but in the end it was cheap for me who had time and energy.

The two earliest advocates of refactoring technology are wardcunnhan and kentbeck. They have long taken refactoring as a core component of the development process and used it in their own development process. In particular, it is precisely because of my cooperation with Kent that I truly see the importance of refactoring and directly inspire me to write this book.

Ralph Johnson leads a group at uiuc (University of Illinois at erbana-champaine), which is well known for its practical contributions to object technology. Ralph was a supporter of refactoring technology for a long time, and some of his students have been studying this topic. Billopdyke's doctoral thesis is the first detailed written result of restructuring research. Johnbrant and Don Robert Ts are no longer satisfied with writing articles. They wrote a tool called refactoringbrowser, which implements a reconstruction project for the Smalltalk program.

Thank you

Although these research results can be used for reference, I still need a lot of help to write this book. First, and most importantly, kentbeck has helped me a lot. Kent talked to me at a bar in Detroit and he was writing a paper [Beck, Hanoi] For smalltalkreport, where he broadcasted the seeds of the book. In that conversation, not only did I start to notice the refactoring technology, but I also "stole" a lot of ideas and put them in chapter 1 of this book. Kent also helped me in many other aspects. He came up with the concept of "code taste". When I encountered various difficulties, he encouraged me to be one of them, I often work with him to help me complete this book. I can't help but think that: he can write this book better by himself. Unfortunately, I am the one who has time to write books, so I can only hope that I do not do too poorly.

When I write this book, I hope to share some expert experience with you directly, so I am very grateful to those who have spent their time contributing to this book. Kentbeck, John Brant, William amopdyke, and Don Roberts compile or co-write part of this book. In addition, richgarzaniti and ronjeffries help me add some useful text annotations.

In any of these technical books, the author will tell you that technical reviewers have provided great help. As always, cartershanklin and his team from Addison-Wesley have organized a strong reviewer lineup, which are:

Qken Auer, rolemodel software company

Qjoshua Bloch, Java software department of sun

Qjohn Brant, uiuc

Qscott Corley, highvoltage software company

Qward cunnhan, cunnhan & cunnhan

Qsté phane Ducasse

Qerich gamma, Object Technology International Company

Qron Jeffries

Qralph Johnson, University of Illinois

Qjoshua kerievsky, industrial logic

Qdoug Lea, New York State University Oswego

Qsander tichelaar

They greatly improved the readability and accuracy of the book, and at least removed some mistakes that may be hidden in any manuscript. I would like to express my special thanks to the two outstanding suggestions that make my book seem refreshing: Ward and Ron suggested that I write chapter 1st in parallel with the effects before and after refactoring, joshuakerievsky recommends that I sketch the code in the refactoring list.

In addition to the formal review team, there are also many informal reviewers. These people either read my manuscripts or follow my web pages and leave helpful comments to me. They are leifbennett, Michael feathers, michaelfinney, Neil galarneau, hishamghazouli, tonygoshould, John isner, brianmarick, Ralf reissing, johnsalt, Mark Swanson, davethomas and Don Wells. I believe there are still some people I have forgotten. Please forgive me and thank you.

There is a particularly interesting review group, that is, the "Notorious" uiuc reading group. This book reflects their numerous research achievements. I would like to express my special thanks to their comments on recording. The team members include Fredrico "Fred" Balaguer, johnbrant, Ian Chai, brianfoote, Alejandra Garrido, zhijiang "John" Han, peterhatch, Ralph Johnson, songyu "Raymond" Lu, dragos-running manolescu, hiroakinakamura, jamesoverturf, donrobert ts, chieko Shirai, lestyrell, and Joe Yoder.

Any good idea should be tested in a harsh production environment. I have seen that refactoring has played a significant role in the Chrysler integrated salary system (chryslercomprehensive compensation, C3. I would like to thank all the members of that team: annanderson, edandrei, Ralph Beattie, kentbeck, David Bryant, bobcoe, Marie dearment, etetfronczak, clerk, dennisgore, Brian hacker, chethendrickson, ronjeffri, using joppie, David Kim, paulkowalsky, debbiemueller, Tom murasky, Richard dnutter, Adrian pantea, mattsaigeon, Don Thomas and donwells. The first-hand data obtained by working with them has consolidated my understanding of the principles and functions of restructuring. The progress they have made in using refactoring technology has helped me to see how the refactoring technology can play a role in large projects that have been used for many years!

I got J. cartershanklin and his team help, including krysiabebick, Susan Cestone, chuckdutton, Kristin Erickson, johnfuller, Christopher guzikoski, simonepayment and Genevieve rajeski. Cooperation with excellent publishers is a pleasant experience and they provide me with a lot of support and help.

When talking about support, the person who pays the most for a book is always closest to the author. That is, Cindy, who is now my wife. Thanks to her, I love me the same way when I work. Even when I write a book, I keep remembering her.

 

Martinfowler

Melrose, Massachusetts

Fowler@acm.org

Http://www.martinfowler.com

Http://www.refactoring.com

Xiong Jie Translation