Hey, hope you are having a great Thursday!
I've been engaged in various discussions about eliminating tech debt and refactoring stuff out.
One of the goals of such sessions is to prioritize issues, so we spend our precious refactoring time fixing up the most important stuff.
A helpful rule for that process is "change code that people work with and read, and don't bother about the code that is read once in a while and is relatively simple even if flawed in some ways."
This is not the only rule, but definitely a good indicator on what to look at first. At least from my experience.
But here's the problem. When it comes to debates about which code we read and change more often, most of the process is just guessing. We try to gauge that from the intuitive context that we have at the moment: recent features, major features, plans, opinions, etc.
Even though we usually end up with a not very bad estimation, there's really no good way to measure or reflect on that process.
So it got me thinking: isn't it just a technical problem that we could solve with tools?
- We could track how much (and how often) different files are changed using history from Git. The data is in front of us, and we would use something similar to https://github.com/jez/git-heatmap to assess that.
- But point 1 is just half of the story. Wouldn't it be also great to track how much developers read different parts of the code? This would probably require an editor extension that would track all the cursor movements and jumps + navigation between files — perhaps a trivial thing to code for most of the popular editors. Then we would build a similar heatmap of how the code is read.
Questions:
- Is the whole refactoring problem something that you are regularly solving at your organization as well? What's your approach and what are your struggles?
- Would that code navigation tracker be of any use to you? Can you think of a project that can already do that?
Thanks for reading! Here is a ship-shipping ship, shipping shipping ships
Top comments (0)