I maintain a handful of open source projects in my spare time. I am the sole developer on these projects (I very rarely get pull requests or patches). How well do the principles in your book apply to projects that only have a single person working on them? Are the principles in your book more centered around large teams? Thank you!
Michael Angstadt wrote:I maintain a handful of open source projects in my spare time. I am the sole developer on these projects (I very rarely get pull requests or patches). How well do the principles in your book apply to projects that only have a single person working on them? Are the principles in your book more centered around large teams?
The principles in the book become more important with larger teams and systems. Somewhere around just 5-7 developers, social and organizational factors tend to become just as important as technical aspects. This is clearly not the case in your situation. For example, you're likely to have a high system mastery as you've written all code by yourself, and you don't need to consider aspects like coordination or loss of knowledge due to former contributors.
That said, I do use these techniques on my own side projects too. The value isn't as big as on larger projects, but the analysis techniques might still provide some insights that I use to guide refactorings:
* I use hotspots to get a visual overview of my codebase. This helps by giving me a different perspective as I get to view the code from an evolutionary perspective. It's quite easy to spot modules that start to grow out of control so that we can act on it.
* I'm also interested in long-term complexity trends. If I find a significant hotspot, is it code that continues to accumulate complexity and is likely to become worse in the future? A complexity trend answers that question.
* Finally, and perhaps most important, I look at the temporal dimension to identify change coupling in my code. That is, are there certain components/files/functions that I regularly have to modify together? If yes, did I expect the coupling or is it a surprising finding?
We developers seem to lack an intuition for change coupling and, hence, such an analysis will often provide insights about implicit dependencies that we cannot see in the code itself. I use the technique all the time to identify units to combine, split, or even re-design.
Author of Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis (2018).
You're not going crazy. You're going sane in a crazy word. Find comfort in this tiny ad: