Bradley Irby - Reengineering .NET: Injecting Quality, Testability, and Architecture into Existing Systems

Bradley Irby

Upper Saddle River, NJ Boston Indianapolis San Francisco
New York Toronto Montreal London Munich Paris Madrid
Capetown Sydney Tokyo Singapore Mexico City

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

The .NET logo is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries and is used under license from Microsoft.

The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact:

U.S. Corporate and Government Sales
(800) 382-3419

For sales outside the United States, please contact:

International Sales

Visit us on the Web: informit.com/aw

The Library of Congress cataloging-in-publication data is on file.

Copyright 2013 Pearson Education, Inc.

All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. To obtain permission to use material from this work, please submit a written request to Pearson Education, Inc., Permissions Department, One Lake Street, Upper Saddle River, New Jersey 07458, or you may fax your request to (201) 236-3290.

ISBN-13: 978-0-321-82145-4
ISBN-10: 0-321-82145-9

Text printed in the United States on recycled paper at
R.R. Donnelley in Crawfordsville, Indiana.
First printing: October 2012

I would like to say thank you to my friends and family for their support and kind words; my children, Max and Lucas, for forgiving me for all those nights when I was writing and couldnt read them a story; and especially my wife, sweet Marcela, for her seemingly unlimited patience, understanding, faith, and encouragement. Many Chuicks!

Any developer who has been practicing his craft for more than a few years has been confronted with the task of enhancing an application that is difficult to work with. Navigating the code is difficult, figuring out where to start tracking down a defect is difficult, and making changes is difficult. Everything is difficult with these applications. Enhancements and bug fixes can be time-consuming, risky, and expensive.

One option for these legacy applications is to take them offline for a year or more to rewrite from scratch. Often these applications are so critical to the operation of the business, however, that feature development cannot be stopped for such an extended period of time. Therefore, work on the legacy system continues on, making patches and fixes to try to get through the next release cycle.

There is another option to help these legacy systemssoftware reengineering.

After a software application is built, it immediately begins to age. Software engineering is a young field, and new ways of building applications are created every day. As new tools are introduced to the industry, if current applications are not retrofitted to use these tools, they become more and more difficult to maintain.

Software can become old for many reasons. The most obvious is the breathtakingly rapid pace of technology improvement in the world today. New software technology that was developed just a few years ago is already considered old and difficult to maintain.

The rapidity of job changes that is becoming a standard can also add to the deterioration of code. As the original developers pack their bags and move on to other companies, the original intent of much of the code is forgotten, leaving the remaining developers to pick up the pieces and hack together solutions as best they can.

By continually reengineering the system to modern technologies, this dependence on the original architects becomes less crippling. New developers can easily adapt to the system architecture because it is up to date and plenty of information can be found about it on the Web.

Certain signs can tell when a system reaches the point it needs to be reengineered.

If developers resist the efforts by management or users to enhance an application, it might be because the system is too difficult to work with. Over time, the software can become fragile, causing any feature development to become difficult and frustrating.

If the development team is swamped with defect notices immediately after a new release of the software, it indicates a lack of modern quality tools. Part of the reengineering process involves introducing these automated quality tools so that the defect rate should decrease significantly.

Old software can often display its age by the number of defects it contains and the effort necessary to fix them. The older and more fragile software gets, the more difficult it is to fix problems without breaking something else. If you see two defects appear for every one that is fixed, this is a sign that the application needs to be reengineered.

Legacy applications are especially prone to quality problems because they cannot support the new quality assurance approaches of Unit Testing and System Mocking. Without these tools in place, making changes to a system can result in creating a defect in an area seemingly and totally unrelated to the change made.

The goal of software reengineering is to incrementally improve an existing system by injecting modern architecture and software development techniques, while continuing to enhance the system with new features and while never having to take the system offline. This means we can take an existing system and slowly improve on it until it is brought up to modern software development standards without the need for a large, concerted rewrite effort. Throughout the reengineering project, the system is ready for production release. In other words, we can keep the plane in the air while we fix it.

The architecture of a software system is what determines how the many necessary details are built. Trying to use the latest approach to build a new data entry form for an old system is like trying to attach a jet engine to a biplane. You might get it off the ground, but the frame is not going to hold up for long.

The first reaction of most managers when they hear that the system architecture must be updated is to assume the application must be rewritten from scratch. This is not necessarily true. Bringing the architecture up to date can be done incrementally, as long as the new pieces are introduced in the proper order and using the proper steps.