16 lines
3.2 KiB
Plaintext
16 lines
3.2 KiB
Plaintext
Your new word of the week: explorify?
|
|
<p>There are a lot of things people writing software do in the world of bits that don’t have easy analogs in the world of atoms. Sometimes it can be tremendously clarifying when one of those things gets a name, as for example when Martin Fowler invented the term “refactoring” to describe modifying a codebase with the intent to improve its structure or aesthetics without changing its behavior.</p>
|
|
<p>There’s a related thing we do a lot when trying to wrap our heads around large, complicated codebases. Often the most fruitful way to explore code to modify it. Because you don’t really know you have understood a piece of code until you can modify it successfully.</p>
|
|
<p>Sometimes – often – this can feel like launching an expedition into the untamed jungle of code, from some base camp on the periphery deeper and deeper into trackless wilderness. It is certainly possible to lose your bearings. And large, old codebases can be very jungly, overgrown and organic – full of half-planned and semi-random modifications, dotted with occasional clearings where the light gets in and things locally make sense.</p>
|
|
<p><span id="more-5178"></span></p>
|
|
<p>A refactoring expedition can serve very well for this kind of exploration, but it’s not the only kind. As a trivial-sounding example, when trying to grok a large mass of older C code one of the first things I tend to do is identify where ints and chars are actually logic flags and re-type them as C99 bools.</p>
|
|
<p>This isn’t refactoring in the strict sense – no code organization or data structures change. It can be very effective, though, because identifying all the flags tends to force your mental model closer to the logic structure of the code. </p>
|
|
<p>Another thing I often do for the same reason is identify related global variables and corral them into context structures. (Note to self: must find and release the YACC mods I wrote years ago to support multiple parsers in the same runtime.)</p>
|
|
<p>For a clearer example of how this concept is different from refactoring, consider another common subtype of it: adding a small feature, not so much because the feature is needed but to improve and verify your knowledge of the code. The inverse happens – I’ve occasionally gone on exploratory hunts for dead or obsolete code – but it’s much less common.</p>
|
|
<p>I think we need a word for this. I spent a significant amount of mental search time riffling through my vocabulary looking for an existing word to repurpose, but didn’t find one. My wife, who’s as lexophilic as I am, didn’t turn up anything either.</p>
|
|
<p>Therefore I propose “explorify”, a portmanteau of “explore” and “modify”. But I’m much less attached to that particular word than I anm to having one for the concept. Perhaps one of my commenters will come up with something better.</p>
|
|
<p>Sample usage:</p>
|
|
<p>“I was explorifying and found a bug. Patch enclosed.”</p>
|
|
<p>“Yes, I can probably do that feature. But I’ll need some time to explorify first.”</p>
|
|
<p>“No, we probably didn’t need strictly hex literal recognition there. I was explorifying.”</p>
|