Working Effectively With Legacy Code

Prepared for ThoughtWorks Agile Technical Practices series

Transcript

2. WORKING EFFECTIVELY WITH LEGACY CODE
3. A career in software
4. The real cost of systems
5. Code quality metrics
6. The legacy system quandary $$$ Provide business value $$$ Prohibitive cost of change
7. Edit and Pray
8. Doh!
9. Cost of change is prohibitive $ Provide business value $$$$$$ $$$$$$ Prohibitive cost of change
10. Big bang re-write
11. Big Bang: cost / benefit profile
12. Big bang re-write
13. EVOLUTIONARY APPROACHES #1: STRANGLER APPLICATION
14. Strangler Application
15. Strangler Application
16. Strangler Application
17. Strangler Application
18. Strangler Application
19. Strangler Application
20. Strangler Application
21. EVOLUTIONARY APPROACHES #1: PHASED APPROACH
22. Phased Approach
23. Phased Approach
24. Phased Approach
25. Phased Approach
26. Evolutionary: cost / benefit profile
27. The Boy Scout Rule
28. AN ALTERNATIVE TO EDIT AND PRAY
29. Cover and modify !  To modify the code we need tests !  To write tests we need to modify the code Cover and modify (modify and cover and modify)
30. Legacy code change algorithm 1.  Identify change points 2.  Find test points 3.  Break dependencies 4.  Write tests 5.  Make changes and refactor
31. Getting under test #1 public class CarFactory { ... public void buildCars(int number, String model, String brand) { for (int i = 0; i < number; i++) { String serialNumber; // // 20 lines of code to calculate new serial number // Car car = new Car(model, brand, serialNumber); Car.save(car); // triggers write to prod db } } } new CarDAO().save(car); // same problem Example thanks to http://www.wakaleo.com/component/content/article/240
32. Getting under test #2 public class CarFactory { private CarDAO dao = new DefaultCarDAO(); public void setDao(CarDAO dao) { this.dao = dao; } public void buildCars(int number, String model, String brand) { for (int i = 0; i < number; i++) { String serialNumber = generateSerialNumber(model, brand); Car car = new Car(model, brand, serialNumber); dao.save (car); } } }
33. Getting under test #3 public class CarFactoryTest { @Test public void carFactoryShouldGenerateTheRightSerialNumber() { CarFactory factory = new CarFactory(); CarDao mockDao = mock(CarDao.class); factory.setDao(mockDao); // I know what the serial number should be String expectedSerialNumber = "123456"; Car aToyotaPrius = new Car("Toyota", "Prius", expectedSerialNumber); factory.buildCars(1, "Toyota", "Prius"); verify(mockDao).save(refEq(aToyotaPrius))); } } // Though might be better to test (and code) serial number generation in isolation...
34. Problematic code !   Real problem areas are the usual suspects: •  Long, excessively complex methods •  Missing abstractions (manifested as code-level duplication) •  Rampant interdependency •  Generally, poor choice of units !   Given poor units, difficult to derive meaningful unit tests (prior to change) !   May be wise to focus on mini integration tests first
35. Characterization tests !   Characterization tests are an attempt to lock existing behaviour into an untested or undocumented system. !   It may be impossible to know the "correct" behaviour or safe way to refactor when making changes to or around legacy code that has no tests. This is especially true when no specification is available, or when other code may rely on flaws in the code. !   In these situations, it is typically best to assume that the old behaviour must be preserved unless explicit changes are required. !   In order to preserve the old behaviour, characterization tests are written that use the system as it has already been used. http://c2.com/cgi/wiki?CharacterizationTest
36. When to refactor? Worst case: we don’t touch this area of code again for years (unlikely) It’s likely code will be read periodically regardless of whether or not it gets changed Likely case: changes cluster, code changed today is likely to be changed again soon
37. Case study & practical HtmlStreamTokenizer
38. Background !   Familiar domain !   Some level of relevance !   Old, no unit tests !   Not too big, not too small !   Java !   No (or minimal) dependencies
39. HtmlStreamTokenizer “Free lightweight HTML/XML parser” http://sourceforge.net/projects/htmltok/
40. The fiction ! HtmlStreamTokenizer is an important player in our systems landscape !   Carelessly, the original developers all died in a plane crash !   Safe to edit (refactor) – not a public library !   Some progress already made on characterization tests !   Pressing issues: Ø  Add support for H7 Ø  Pull definition of known tags (like H7) out of HtmlTag and into a separate class (intent, later, is to load these from config) Ø  HtmlException is a pain. We want to switch to using (well-chosen) subclasses of RuntimeException, but currently have little or no understanding of various scenarios where a HtmlException is thrown
42. References !   Michael Feathers, Working Effectively With Legacy Code !   Robert C. Martin, Clean Code !   Martin Fowler, Refactoring: Improving the Design of Existing Code !   Chris Stevenson and Andy Pols, An Agile Approach to a Legacy System !   Dan North, Pimp My Architecture (http://www.infoq.com/ presentations/north-pimp-my-architecture)