How to prioritize cleaning your database
First, TypeScript is good. But that is not what the article is about. It comes down to what to do if the code base in your function doesn’t have enough of it.
Do you use TypeScript in your React database? I asked my future boss in a job interview.
“Yes.” was the answer.
“Wow!”
Unfortunately, it wasn’t great. I should have asked, “How [much] Do you use TypeScript? TypeScript adoption is not a binary case, but a spectrum.
Like many older React projects, the w . source codeaIt is rewritten to TypeScript in a way to “write new things in TypeScript, and fix old things when you have the time”. But without a specific goal and measure of progress, the incentive is always to introduce new features rather than resolve technical debt.
After several months of switching, most of the code was still unwritten, and progress was slow. We knew that rewriting to TypeScript was valuable in the long run. But to justify spending time developing on it, we wanted to track and visualize our progress.
- Explain to decision makers that enabling TypeScript everywhere will help you charge faster and sleep better.
- Build a progress bar to have a look at.
This is. The progress bars are magic. It’s very simple, but it works. RPG players will grind for hours to get their Elder Paladin to level 75 or something else. Clarity of purpose drives motivation. People do things to see the numbers go up. The developers will fix TypeScript errors for the same reason. You can buy pizza for every great teacher.
Don’t get me wrong, developers are intrinsically motivated to improve code quality and they should. But then this happens:
“Why is this task taking so long?” – evening
Well, there was a lot of TypeScript to add and fix. – Dave
“Ah, well, it sounds like an excuse, but whatever, can we focus on delivering customer value here, please?” – PM (in the head, probably)
Maybe next time you leave the code just as messy as you found it to move on with your next task. Your work of fixing technical debt is invisible and only gets in the way. Or the conversation can take place as follows:
“Why is this task taking so long?” – evening
“Okay, there was a lot of TypeScript to add and fix, so I fixed it. See the progress bar? We went from 54% to 60% of TypeScript coverage in this fast sprint. The closer we get to 100, the faster we’ll be in the long run as a team.” – Dave
“I see, good job.” – evening
Your business is not invisible anymore. The team moves towards a specific goal by a certain amount. What can be measured can be done. It applies well here.
The measure of TypeScript adaptation depends on your taste in not actually adopting TypeScript.
maybe you have .js(x) And .ts(x) The files live side by side. This is the cleanest alternative. You can count them with a little mega-magic:
In fact, both GitHub and GitLab display language statistics for your repositories automatically.
It might be all your files .ts But you wrote everything on it any. It is better to use a file analyzer tool any Usage and reports:
Maybe your situation is messy. Your files are .ts It contains some types, but most of them contain @ts-nocheck Flags right at the top. Then you need to count the offending files:
You can do something similar to @ts-ignore. Whatever the problem, you need to adjust the scaling accordingly.
Percentages are fine, but you really want a colorful progress bar. Red is bad, green is good. Crucially, it pays to see progress in time, to see green slowly defeat red, and slowly make their way to victory. A timeline can help, too.
Our report – smashed together during a one-day hackathon – looked like this:
We used a bash script to count the number of files and create an HTML file with Chartist.js table and schema. But you can use anything.
The progress bar is not good if no one is looking at it. It is important to put the numbers in front of people so that they do not have to search for them. Get rid of as much friction as possible. In our case, this meant a weekly scheduled pipeline for GitLab:
- Manages
ts-reportbash script on our repository and generates the report. - Loads the report into GitLab pages.
- Sends a message to a Teams channel with a link to the report.
pages job in our area .gitlab-ci.yml file (simplified)Then once a week, we get this:
It would be better to put the report directly into the message, but that’s fine for now. Slack notification or email also works. Choose which communication tool your team uses the most.
The last step is to share your progress. Sprint Reviews has a segment dedicated to updates on technical debt, so we’re talking about our TypeScript coverage there. The progress bar can be effective, even if it is only used internally within your team. But it is better to openly commit to a goal and give stakeholders regular updates.
Since the report was created, the speed of TypeScript adoption has increased significantly. (Other factors like new team members also helped.)
This time it was TypeScript coverage, but you can apply the same idea to different types of long-term technical debt:
Make the invisible work not only visible but Easy to see regularly – It will be done faster.