Decreasing technical debt on a large codebase steadily
Everyone hates and are in a way afraid of technical debts. We do not know how to start figuring them out as most of them are too large to cope with in one go. Most of the large scale applications accumulate technical debts over a period of time.
Well don’t worry so did ours. I work at a large scale business with web application technology and we had quite a significant technical debt that was fixed over a period of time.
We had some points to improve:
- Implement fully strict typescript code style in across our codebase.
- Our web application uses feature toggles and quite often some of them get forgotten to be removed after feature release (meaning our backend side does not pass them to UI, but UI does not know that and still uses the default values). We wanted to have a CI job that tells us on UI if the setting used is not being configured anywhere from backend side.
- To have all unused javascript functions (meaning unused exports) in our project removed. Turns out, this was quite a difficult thing to do.
We needed implement all of these features softly. We did not want to fix all the problems in one go as that would require a lot of time from our developers spanning over a short period of time and blocking feature development as opposed to not adding new unwanted errors and fixing old ones whenever we get some free time from feature development.
Our acceptance criteria was to have passing builds in our CI that checked if any of the points above were broken during the new deployment. I’ll tell you how we accomplished that.
Firstly we generated XML reports containing all of the existing problems that we had at a time. There were quite a few of them. We had:
- 2000 strict typing errors
- 200 unused settings
- 300 unused javascript functions
We are almost there!
Then we made an according setup on our new CI job (we use Jenkins) to do these steps every time the job was launched after a new deployment:
1. Generate new XML documents for every new error count above.
2. Check the error count differences with the last build counts.
3. Thresholds were configured on the job to mark the job with a:
- Warning state if there were more than 1 error difference between last and the current build.
- Warning state if there were more than 2500 (2000+200+300) errors in total.
- Error state if there were more than 3 errors difference between the last and the current build.
- Error state if there were more than 2600 errors in total.
And that’s it. We are on our road to success!
With this setup we avoided new unwanted errors and we did not have to fix all of these problems in one go. Whenever we had some free time from feature development we tried to decrease the thresholds configured on the CI job.
