Object Oriented Reengineering Patterns

Rating:
Summary: Practical advice for reengineering
Review: If you are charged with reengineering a piece of software; if you are considering rewriting software; or even if you are trying to evaluate whether or not it is worth further effort in maintaining a piece of code: in all of these cases, read this book before you start. Not only will it give you tried and tested advice about the motivations for reengineering, should you then decide that reengineering is necessary, this book provides suggested approaches which will help structure your work and could save you valuable time and effort.

Excluding an introductory chapter and an appendix, the book is divided into two sections: Reverse Engineering (Part 1, Chapters 2-5) and Reengineering (Part 2, Chapters 6-10). The first of these sections deals with analysing the code and seeks to answer the question: "Where does one start when presented with a large code base which is a candidate for reengineering?" The patterns presented here help one decide how (or whether) to proceed, help establish confidence in the course of action chosen and give guidance for those worrisome first steps into the unknown. The second section deals with the reengineering itself: testing, migration and restructuring of the code base. Testing ensures that what is re-created reproduces (to the extent desired) the effects produced by the original code base. How do you know that your changes haven't broken the code? Strategies for migration are clearly necessary since we want our new system to be used and evaluated as it is being reengineered. Finally the last three chapters in the book give good, solid, uncontroversial advice about the restructuring of object-oriented code.

Presented in an easy-to-read style, the patterns presented in this book should give you a head start in your reengineering endeavours.

Rating:
Summary: Plans on how to perform major reorganizations of software
Review: The authors define a reengineering pattern as one to be globally applied to a large, functioning system that needs to be improved. Their formal definition is "Reengineering is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form." Reasons for improvement could be necessity due to poor performance or just the next iteration of the upgrade cycle where major changes are necessary. In any case, the intent is to perform substantial modifications to the code, generally all the way down to the basic design. Their emphasis is not on converting legacy systems without objects to one that is object-oriented. These patterns are used to convert object-oriented systems into systems that are still object-oriented, but where the implementation is more efficient, either in speed of execution or ease of maintenance. In that sense, the book is timely, as object-oriented programming has now been around long enough that the early systems are beginning to show signs of code rot. Furthermore, our understanding of object-oriented programming has matured a great deal in the past several years, and for many it is time to take advantage of this knowledge.
The start point is expected, you begin by setting a general goal, which imposes a generic direction. This involves determining what the inadequacies are perceived to be as well as the expectations for the reengineered product. Once this is done, the next step is a feasibility analysis, which involves the following patterns: Read All the Code in One Hour, Skim the Documentation and Do a Mock Installation. While these patterns are not necessarily to be taken literally, they are very sensible. The source code that currently exists may not be the original, so the most logical first step is to attempt a compilation and install operation. Nothing could tell you more about the seriousness of the potential problems than having an attempted compile fail with a number of errors that exceeds the limits set on the compiler.
Assuming that works, the next step is to perform an hour-long scan of the source code. The idea here is not to read it all, but to examine enough of it to get a sense of how well it is put together. This time limit is of course somewhat arbitrary. It may only take you ten minutes to realize that the code was written by deviants. Finally, a cursory examination of the documentation will help you determine if it is to be of any use. This is the point where you must pay the greatest attention, so it may take longer than the other two. Although the documentation may be wonderful, it is necessary for you to read it in conjunction with the associated code, to verify that the two are synchronized. In this case, one may simply want to randomize the examination in some way, and then probe the selected sections in great detail.
Once you have performed the previous tests without running away in terror, it is necessary to begin the changes by applying more specific patterns. The first set of specific patterns are used to capture a detailed model of the system, followed by the construction of tests, migration strategies, how to detect duplicated code, redistribute responsibilities, and transform conditionals to polymorphism. The last three are standard refactorings, which shows the movement from general strategies to the more specific. However, the authors are still operating at the system level, so the patterns are more general than refactoring. For example, the patterns on duplicated code are how to identify duplicated code rather than the mechanics of how it is removed.
The patterns are described using the structure: The name of the pattern and the problem(s) it addresses, the solution, the list of trade-offs separated into the pros, cons and difficulties; an example, the reasons for applying the pattern and other patterns that are related to it. I found this approach to be refreshing, as many authors give solutions without pointing out the problems their solutions can generate. In general, the patterns form a set of sound advice, but it is up to you to make the transition from the system level to the specifics of code change.
If you are faced with a major reorganization of a large project, then I wish you well. However, like these authors I will do more than just give you sympathy and encouragement. My task is much easier, in that I will simply encourage you to read this book. They did all the hard work of constructing a plan, and you would be wise to listen to them.

Published in the online Journal of Object Technology, reprinted with permission.

Rating:
Summary: Applicable every day
Review: The authors wrote better than they knew. My own experience is that reverse engineering is at least 20% of a typical software engineer's typical day. It's the study that a developer puts towards understanding a system well enough to make necessary changes, rediscovering enough about the system to enable the task at hand. The authors addressed their book to specific re-engineering projects, as isolated events, but they really wrote about the everyday life of almost every programmer.

As Johnson points out in the foreword, much if the information has an "everybody knows that" feel about it. I found a few new tips or new 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 an arrangement of ordinary playing cards can become a valuable hand in poker.

Among other things, these authors are the first to convince me that software metrics can be a net gain to a developer. My own, 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 pros and cons of prototypes, but missed the biggest danger of a working prototype: that, no matter what caveats are given, it can be mistaken for a real 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, system's entire 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 longer discussion in ch.10 of type checking - I agree with the authors completely, but feel that they missed some common variations on the type-testing theme and reasons for it.

The authors suggested using dot plots for describing 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, but also suggests that other genomic tools could possibly have value in understanding software. Programs are really just long strings, and geneticists have a huge box of subtle tools for analyzing long strings. Mating of the two fields could spawn a new generation of 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, worth serious 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.