| Book Name: | Object-oriented reengineering patterns |
| Category: | Computer Books ( CE & IT ) |
| Free Download: | Available |
Object-oriented reengineering patterns
The documentation is missing or obsolete, and the original developers have departed. Your team has a limited understanding of the system, and unit tests are missing for many, if not all, components. When you fix a bug in one place, another bug pops up somewhere else in the system. Long rebuild times make any change difficult. All of these are signs of software that is close to the breaking point. Many systems can be upgraded or thrown away if they no longer serve their purpose. Legacy software, however, is crucial for operations and needs to be continually available and upgraded. How can you reduce the complexity of a legacy system sufficiently so that it can continue to be used and adapted at an acceptable cost? Based on the authors’ industrial experiences, this book guides on how to reverse engineer legacy systems to understand their problems and reengineer those systems to meet new demands. Patterns are used to clarify and explain the process of understanding large code bases, transforming them to meet new requirements. The critical insight is that your system’s right design and organization cannot be evident from the initial conditions alone but rather as a consequence of understanding how these requirements evolve. It describes how to reverse engineer a monolithic system to know how it works and how to identify potential problems. Includes reengineering patterns that tackle well-known reengineering techniques often encountered in object-oriented programming, such as introducing polymorphism, factoring out expected behavior, detecting duplicated code, and understanding design.* This shows how to build a continuous reengineering culture to achieve flexible and maintainable object-oriented systems.
Book Description
The authors wrote better than they thought. My experience is that reverse engineering accounts for at least 20% of a typical software engineer’s day. It’s the study that a developer puts towards understanding a system well enough to make necessary changes and discovering sufficient about the plan to enable the task at hand. The authors addressed their book to specific re-engineering projects as isolated events, but they wrote about the everyday life of almost every programmer.
As Johnson points out in the foreword, much of the information has an “everybody knows that” feel. I found a few new tips or phrases, but mostly I found a clear, systematic organization of facts and techniques that are widely applied. The authors’ arrangement of known techniques makes them especially valuable, much the way a collection of ordinary playing cards can become a helpful hand in poker.
Among other things, these authors are the first to convince me that software metrics can be a net gain for a developer. My sad exposure to metrics has been normative, a stick wielded blindly in the name of misunderstood “quality.” This book shows how to use metrics in a constructive, exploratory way. The complexity (or whatever) scores are not the output of the process; they are intermediate results to be discarded as soon as they’ve pointed the way to the real problems.
I found only a very few points to disagree with. For example, the authors point out the pros and cons of prototypes but miss the most significant danger of a working prototype: no matter what caveats are given, it can be mistaken for a natural system. Over-eager clients or managers driven by a false sense of efficiency may demand that the developers just add a feature or two (usually, the system’s full capability) and ship it tomorrow. Elsewhere, the authors noted that converting from a command-line interface to a GUI can be jarring for users but did not point out that a GUI can provide a command entry field, at least as a transition aid. I would also have been happier with a more extended discussion in ch.10 of type checking; I agree with the authors but feel they missed some common variations on the type-testing theme and its reasons.
The authors suggested using dot plots for describing the similarity between bodies of code, a representation I first saw in genome analysis. It strengthens the image of a program as a living, evolving thing and suggests that other genomic tools could have value in understanding software. Programs are just long strings, and geneticists have a massive box of subtle tools for analyzing long strings. The mating of the two fields could spawn new techniques for extracting information from existing software.
I recommend this book very highly. It’s thorough, practical, and readable. It addresses software maintenance—i.e., most of the software industry—as a valuable task severe worth study and investment in tools. A brief review can’t do justice to the book’s rich content. I hope you explore it for yourself.
Object Oriented Reengineering Patterns (The Morgan Kaufmann Series in Software Engineering and Programming) PDF
Author(s): Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz
Series: The Morgan Kaufmann Series in Software Engineering and Programming
Publisher: Morgan Kaufman Publishers, Year: 2003
ISBN: 9781558606395
