Dealing With Legacy: The Real-World Experience

339 views
289 views

Published on

A report of the successes and challenges of our team dealing with further development of a core webapp full of legacy code - what practices we applied, how Scrum worked for us, what worked well, what could be improved, what I'd do to avoid creating legacy code and what the hidden cost of legacy code really is.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
339
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Dealing With Legacy: The Real-World Experience

  1. 1. Dealing With Legacy:The Real-World Experience
  2. 2. Why this presentation?● Share successful practices● Get suggestions regarding the challenges we struggled with (that arent unique to us)● Provide support for pushing through design refactorings by revealing the cost of legacy
  3. 3. Agenda1.The Application & Team2.The Challenges3.What Worked Well4.What Could Be Improved5.What Id Have Loved To Have6.Some Other Lessons Learned7.Legacy Code: Manifestations, why to avoid ● Selected Anti-Patterns ● The Hidden Cost of Legacy
  4. 4. The Application & TeamApplication: ● Java 1.4, JSP, JSF● Ordering site critical to ● Ca 8 years, ~2.5k the business, 1-2k classes, 170 kLOC orders/day (400 classes and 50Team: kLOC in the core)● Team of 5+1, Scrum ● MonsterJsfBean (improved!): >10k● WS back-end LOC, 50 constants, developed by a team 300 properties + 320 abroad methods (½ public)
  5. 5. The Challenges● The whole team exchanged within 1-2 months ● Surprisingly smooth● Huge difference in expertise levels (seniors x juniors)● Preparing migration to an upgraded platform and a different application server● Planning of a major design overhaul● Legacy code* with negligible tech/biz docs *) See on the next slide
  6. 6. What did the code look like? (More about design refactoring later)
  7. 7. What Worked Well● Scrum / process ● Retrospectives → continual improvement ● Common code review sessions (could be more) ● Pair-programming → learning (cd be more) ● Timeboxing (meetings, spikes) ● Explicit commitment to each and every task● Bi-weekly releases → low uncertainty● CI & deployment package building automation● Opportunistic (boy scout rule) refactoring
  8. 8. What Could Be Improved● Scrum ● Standup – less reporting, more commitment ● Focused sprints with a clear objective● Larger-scale refactorings to improve design● Less defects (how?! more testing?)● Test-first development and refactoring ● We tried but not always (too much effort) and the tests werent always good enough (focus, coupling)
  9. 9. What Id Have Loved To Have● “Living documentation” ← Specification by Example ● Up-to-date, clear business logic documentation ● Automated integration/functional testing● Operational monitoring ● Quick discovery of defects, outages of the app/dependencies ● Knowledge of performance stats and bottlenecks ● Feedback on how features are used● Efficient UI testing (fixtures/deps, jump to
  10. 10. Some Other Lessons Learned● Its crucial to refactor the design as requirements change to tame complexity● Tests too coupled to the implementation are worse than no tests● A meeting w/o action points with assigned people and checkpoints is a waste● Sometimes you must temporarily make code uglier when refactoring it towards st. better
  11. 11. Legacy CODE
  12. 12. Selected Anti-Patterns● Copy & Paste (& Adjust)● Patch & Go (aka Never Refactor Your Design)● One Class to Rule Them All● String Is the Best Data Type (never convert!)● Singletons & Static Accessors● ArrayList instead of the highest abstraction suitable● => *plication and inconsistent design
  13. 13. The Hidden Cost of Legacy● May be only 10-20% time actually coding ● most time spent figuring out what the code does & why (partly due to slow UI)● No specs → what is a feature / bad design / workaround not needed anymore?● Prod defects due to ● not understanding hidden dependencies and varying usage of state variables ● not fixing all the copied & pasted code fragments
  14. 14. Your Action Points :-)● Dont create legacy code ● Beware the cost of legacy ● Do refactor your design to reflect the business● Be better ● Consider implementing SbE/Living document. ● Implement operational monitoring ● Make sure your app/UI is easy to test● Take inspiration from what worked for us ● Retrospectives, Common code reviews, ...
  15. 15. THANK YOU!

×