Live Aid: Agile Design to Re-architect a legacy application
From AgileOpenNorthwest
Live Aid: Agile Design to Re-architect a legacy application Hosted by: Bruce Winegarden, Katie Trout
The hosts described an existing legacy application and asked for ideas, opinions, and comments on the challenges using Agile design to re-architect in an iterative fashion with incremental delivery with minimal disruption to a large installed base.
Contents |
Profile of Legacy Application
Existing application is a hybrid .NET client server. Most of the UI functionality is programmed in a “fat client” WIN FORMS desktop application uses a C# component to talk to SQL Server database. A smaller portion of the functionalityis handled by an ASP.NET web application.
- 700 WINFORMS
- 1400 Database Tables
- Business logic is embedded in both the WIN FORM UI and in Stored Procedures in the Database tables.
- There are little to no unit tests for the WIN FORMS client.
- There are some automated UI tests however these are easily broken and difficult to maintain. As a result, a significant amount of manual regression testing is required following code complete before there is confidence in shipping the product.
- Currently do a major release every 6 to 12 months
The company has launched a significant effort to “re-architect” this application. Some of the stated goals for this effort are:
- Zero footprint web browser client so that users do not need to install anything
(However, installation may be OK for components that provide integration to desktop applications such as Outlook)
- Platform independent client so that users can use non MS machines such as Macs or smart phones
- Scalability for 5 – 10 x number of concurrent users
- Automated regression testing to reduce long delay in validating new releases
- More productive development of new features and functions
- Current application requires changes in many places when same or similar behavior is requested
Some decisions that have been made:
- AJAX web client
Purpose
Ask, what are the Measures of Success for this Rearch effort?
A clear statement of business value expected from this re-architecting effort was suggested so that it could be prioritized into chunks with value that can be delivered sooner rather than later. Search on “Chartering roadmaps by Ellen Gottesdiener” was suggested to help with clarifying this
Strategies
Start with a subset of Winforms screens to migrate to Web UI that represent some chunk of functionality that would be useful to release to customers. Think about Minimal Marketable Feature set that could be delivered in a Web UI.
Architectural Patterns to Consider:
- Model View Controller
- Model View Presenter
Legacy and Rearch use the same data services
- Extract a Domain Model / logical data model for the data services design.
- Refactor to insert use of data services interface instead to directly accessing SQL stored procedures.
It’s likely that it will eventually be desirable to move business logic out of stored procedures and into more testable and manageable code, this “seam” strategy allows this to be deferred so that the parallel development of legacy and rearch code continue to use and test the same logic.
- Reference: Working Effectively with Legacy Code, by Michael C. Feathers
Practices
- Extract logic as needed
- Look at pain points
- Long running refactoring doesn’t work –OR- Long running refactoring works, but watch out for: 1) too many at a time, 2) maintain vision to finish one area before starting another
- Integration tests first, but don’t forget unit tests
How do we be sure we don’t wind up back in same place? E.g. On rewrite treadmill where every 5-7 years feel like we need another complete rewrite.
- Continuous Integration
- Unit Tests
- Test presentation logic
- Maintain architectural vision
- Introduce pair programming to encourage collective code ownership and emphasize more understandable and therefore more maintainable code.
Suggested References:
Andrew Black – Refactoring Flossing vs root canals
Sidebar 2: Floss Refactoring vs. Root Canal Refactoring When we talk about refactoring tactics, we are referring to the choices that you make about how to mix refactoring with your other programing tasks, and how frequently you choose to refactor. To describe the tactics, we use a dental metaphor. We call one tactic “floss refactoring"; this is characterized by frequent refactoring, intermingled with other kinds of program changes. In contrast, we call the other tactic “root canal refactoring". This is characterized by infrequent, protracted periods of refactoring, during which programmers perform few if any other kinds of program changes. You perform floss refactoring to maintain healthy code, and you perform root canal refactoring to correct unhealthy code.
We use the metaphor because, for many people, flossing one's teeth every day is a practice they know that they should follow, but which they sometimes put off. Neglecting to floss can lead to tooth decay, which can be corrected with a painful and expensive trip to the dentist for a root canal procedure. Likewise, a program that is refactored frequently and dutifully is likely to be healthier and less expensive in the long run than a program whose refactoring is deferred until the most recent bug can't be fixed or the next feature can't be added. Like delaying dental flossing, delaying refactoring is a decision developers may make to save time, but one that may eventually have painful consequences.
- Excerpt From: Refactoring Tools: Fitness for Purpose, by Emerson Murphy-Hill and Andrew P. Black
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.139.191&rep=rep1&type=pdf
