Comprendre et vivre avec les dettes techniques dans le « legacy code/software »
Ce soir avait lieu la première rencontre de 2010 du Groupe des utilisateurs Agiles de Montréal avec une présentation institulée Understanding and Dealing with Technical Debt in Legacy Software. Voici mon résumé de la présentation à laquelle j’ai assisté portant sur comprendre et négocier avec le « legacy code » et les dettes techniques, comment cela affecte l’équipe de développement et quels sont les moyens pour s’en sortir!
Understanding and Dealing with Technical Debt in Legacy Software
- Lieu: UQAM
- Présentateurs: Tim Snyder
Description:
« Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation. » Ward Cunnignham
Is your codebase getting harder and harder to modify? Do you find yourself and your team making quick fixes to meet a deadline that you know you will never get back to? Is your ability to add new features that work well with the existing system decreasing every day? Have you thought that it might be easier to just start from scratch? All of these are common symptoms of increasing technical debt in your software.
Attend this session to learn about incremental ways that you can start introducing automated tests into your system to act as a safety-net for change. Attend this session to learn tactical techniques to break dependencies to begin decoupling your software. Attend this session to start digging yourself out of the technical debt hole.
You will learn:
- How to write tests for legacy software every day without the need to stop delivering business value to your customer.
- How to break dependencies and incrementally make your software more amenable to change.
- How to create an environment where developers want to write tests early and often.
Notes:
- What is affected by technical debts?
- New requirements
- Defects
- Maintenance
- How technical debts affects?
- Reduce the hability to make new things/features in the code base
- Every change to the code base carry risk of software break or would require other changes prior to the initial change we want to make
- How do we fall into debt?
- Pay now –> Pay later
- Some people will argue it’s not the time to make it better cause they don’t want to pay now, but it will cost more effort, time and money later to make it clean to be able to make the software changes required in the futur.
- Development (and refactoring) is a learning experience
- Refactoring isn’t considered « value-add »
- This often lead to the shortest path for new feature development
- Cost of change in effort, time and money to
- 1) Understand the code starting point of the change
- 2) Design & Development
- 3) Find things we break
- 4) Time to fix the break
- How to get out (from the previous 4 points)?
- 1) Obviously, understand it!
- 2) Simple design and pull development (only what is needed, not more)
- 3) Tests are a safety net
- 4) Design simple and tests often
- How to get out (just more points)?
- Stop digging
- Pay down some existing debts
- Remember: Debts build Interests
- How to do that?
- Instead of using the Pay now –> Pay later as a disadvantage, use it as a reason to encourage the development team to make it better now
- Simple design and run your tests often on your base code
- Incrementally adding tests to legacy code when you work around an un-tested piece of code
- Characterization tests
- Test the actual behaviour of a legacy code not what it is suppose to be
- Just enough to understand the piece of code
- It’s valuable
- Make several to test the boundaries
- Seams
- A place where you can alter behaviour without editing in that place
- Object (polymorphism)
- Link (alternative library)
- Preprocessor (macro to replace function)
- Aspect (inject pre/post/redirect code)
- Fake alternative to introduce to enable test
- Sprouting
- Sprout a method (or a class)
- Need to add code to the method but no tests (on legacy code)
- Instead of changing method, sprout a new method and call it from the old one
- Use TDD
- Summary
- Development and refactoring are a learning experience
- Refactor is part of the cycle
- Tests allow us to refactor fearlessly
- Add test to legacy code
- Characterization tests
- Seams
- Sprouting
- Refactor reduce technical debts by reducing the complexity of the code
- Keep in mind that the objective is to discontinue the practice of adding legacy code with tests and not to fix all the missing tests, but to change our behaviour to making new code
- Livre mentionné dans la présentation:
Tags: Agile, Génie Logiciel, Montréal, Refactoring, TDD, Technical Debts, Testing, UQAM