Recommended
More Related Content
What's hot
What's hot (20)
Similar to Evolve your application
Similar to Evolve your application (20)
Recently uploaded
Recently uploaded (20)
Evolve your application
- 1. EvolveYour Application DO NOT LET REFACTORING SCARE YOU Mário Nogueira | Software Engineer
- 2. Legacy Code
- 3. Legacy Code • Must be maintained. • New developments must be done. • No one wants to touch it, or parts of it. • A simple bug fix may require large refactoring.
- 4. Legacy Code • We end up doing it like a carpenter and smashing a nail on to it. • And hope we didn’t break anything in the process.
- 5. CAM2
- 6. CAM2 2018
- 7. CAM2 2018 The Good • Market leader in metrology software • Has existed for over 20 years. • Continues to evolve in each release • Adding new features and enhancements
- 8. CAM2 2018 The Not So Good • Features were getting harder and harder to develop • Part of the code base was built over 20 years ago. • Customer were reporting bugs faster than we could solve them • Fix 1 bug, 2 were created. 0 2 4 6 Bugs Reported Bugs Solved
- 9. CAM2 2018 • We decided that enough was enough and was time to revert this situation • We would no longer do easy fixes • Only when no other option was available • When going through parts of the code and a refactor was calling out to be made, we would do it.
- 10. CAM2 2018 • For each bug that we were solving we created an automation test • Our automation test suite quickly grew • These tests allowed us to detect breaking behaviour faster, and fix it before releases. 0 200 400 600 800 1000 1200 1400 Start Release 1 Release 2 Release 3 Release 4 Series 1
- 11. CAM2 2018 • Number of new bugs being reported decrease to nearly zero. • We’ve also added: • Remote logging • Crash Detection • We started detecting bugs and fixing them before customers had the time to report them.
- 13. Release Cycles
- 14. Release Cycle • Two Major Releases per year. • New Features and Enhancements • One Minor Release each month. • Only Bug fixing
- 17. Persistence • Document based application. • Every thing that was important for our customers is placed in it. • Loosing or corrupt the information is not an option.
- 18. Persistence • Binary serialization. • After serialized you can’t read it. • What is in memory gets flushed to a file. • Can go from 2MB in disk to 400MB very quickly • Persisted Services • Application worked on top of it
- 19. New Persistence • Our document infrastructure works as stream holder • Basically a zip file • Moving away from binary serialization • Migrating old data to new format • No longer persist services
- 20. New Persistence • For now we are using SQLite • Saving as required instead of flushing • Saving a document is just compacting the entire stream into a .fcd
- 21. New Persistence • Creating new streams • One for SQLite database • One for each plugin FCD Document (Decompressed) Binary Data SQLite Database Plugins Plugin1 Plugin 2
- 22. New Persistence • Persistence is no longer our core, but a detail DetailUI Domain Persistance Detail
- 23. Domain
- 24. Domain • Not really like that, but messy • A lot of dependencies • Years of development on top of it • Unit testing was hard due to a higher number of dependencies • Couldn’t stop new developments in order to refactor
- 25. Domain • Scattered through the solution • Mixed with non-domain concerns • Refactoring away was not an option • That would take years… 40 years for a single developer
- 26. Domain
- 28. Services Refactoring Component Internal Implementation Entry Point Exit Point IntegrationTests
- 29. Services Refactoring Component Internal Implementation Entry Point Exit Point IntegrationTests Refactored Implementation UnitTesting
- 30. MOB Programming
- 31. MOB Programming
- 32. Conclusion
- 33. Refactoring is Fun • You shouldn’t be afraid of it • You can learn a lot from it • Refactoring will evolve your application and your expertise's
- 34. Bedtime reading
- 35. We are Hiring • Software Engineer • Software Quality Assurance Engineer • Software Research – Computer Graphics
- 36. Questions?
- 40. http://bit.ly/2I6HujY * Para quem não puder preencher durante a reunião, iremos enviar um email com o link à tarde Formulário de Avaliação
Editor's Notes
- First impressions when we think of Legacy Code, and we have to go work on it
- CAM2 2018 is a desktop application, made in WPF C#. Been around for many years and has had many faces and many names
- This is what it looks now
- As coisas que nao estao tao bem, que tem espaco para melhorar
- This would be great if we didn’t have new developments to do and could not stop them while we were refactoring :D But we were ready to start refactoring, making it more easy to develop new features, revisit old modules that were the foundation for many features on CAM2. We knew we had to star small and doing small increments between stories, and/or use some of the stories to do the refactor
- Big refactorings were only made in major releases, which allowed us to break a few functionalities while it was being developed
- As we switched to a continuous deployment module we could no longer keep things broken while the release date didn’t come. We could release at any givem moment. So we had to prepare and do the refactors with a diferent mindset
- Do a break. Explain this was our problem. Background story on what I’m talking today in here
- We decided to start with our persistence, since it’s a fundamental part of our application. For us and for our customers.
- Not an accurate representation on what our domain looks like. Only to get a notion on how coupled some of our components are. Many haven’t changed in 10 years.
- After some discussions we knew we wanted to go from the Big Ball of Mud to an Onion Architecture. AS metioned before we couldn’t just simply do it. So we had to start somewhere…
- We choose a part of our software. A somewhat instable and critical part. And started with it. Isolated the component Kept its interfaces as its API Changing it to an ACL – (Anti Corruption Layer) for the rest of the application Created a new public API for when the rest of the components are rebuilt Switching to the new API would delete the connections with the ACL
- We find entry points on our services/components. Where “Entra porco sai chourico” and built integrations tests on top of it, to gurantee that our component refactor would not break any existing functionality.
- After it was done. We were in conditions to safely refactor our code and internal implementations. This way if we borke something during the refactor our integration tests would alert us. And at the same time we were refactoring also created new and valuable unit testing.
- While we were discussing on how and when to do it, our Director of Software Enginnering came to us and purpose a challenge. Do the refactor on a component with MOB programming. At first we were septic I admin, but after the first session we were hooked up on it, and schedule pretty must one session a day. Relutantes
- It looks like a bloodbath. But its actually very helpful, cause everyone gts a chance to write code, or drag files around
- Survs ajuda com os inqueritos e Nucleo de Estudantes de Informática do ISEP que nos ajudaram e apoiaram na divulgação e na organização
- Survs ajuda com os inqueritos e Nucleo de Estudantes de Informática do ISEP que nos ajudaram e apoiaram na divulgação e na organização
- Para quem puder ir preenchendo, assim não chateio mais logo É importante para recebermos nós feedback, e para darmos feedback aos nossos oradores http://goqr.me/