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.
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.
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
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
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
Notes de l'éditeur
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/
