Scout Refactor & Complex Tramp Data

 https://retailobjects.scoutshop.org/media/catalog/product/cache/6dcc7aa04f12a2312f508892eb3ceb7f/6/1/618739.jpg

 Scouts' Rule

The Scouts have a rule, "Leave a place at least as clean as you found it."  The Scout Rule as adopted to refactoring applies this principle to code, if you touch the code and there's an opportunity to fix something, even if beyond the scope of your assignment, fix it.

Some simple examples (focused on improving encapsulation):

  • if a clause, method, or class isn't used or is used only be a unit test, delete it
  • if a clause, method, or class is used only by another class, move it to that class and mark it private
  • if a clause, method, or class is used only by another package, move it to that package and mark it protected

Tramp Data

One code smell that's somewhat common is Tramp Data.  Tramp Data is a when a method argument is simply passed to a sub-method without being directly visited or used.  When this happens several levels deep, it creates undue cognitive load as the developer has to hold onto the full call stack before identifying why/how the argument is used.

Compounding Tramp Data is when the argument is non-primative. 

Example:

class Widget {
    int a;
    String b;
    String c;
    Map d;
} 

doX(widget) {
    ...
    doY(widget);
    ...
}

doY(widget) {
    ...
    doZ(widget);
    ...
}

doZ(widget){
    print( widget.a );
}

Here, not only does the developer have to delve several layers down to understand how the argument is used, anytime he/she wants to change Widget, it may be necessary to perform this investigation.  First, it would be better to alter the method signature/call to doX(widget.a).  This way at least, the impact of changes to Widget cease at the doX call.  This eliminates 3 layers of call stack from the developer's limited cognitive load.

 https://cdn8.openculture.com/2020/10/22214022/Daisugi-3.jpg

Trim the Tree

By starting at leaf methods like doZ and working your way up, successively pruning inputs, you'll soon find your overall code easier to follow.  This can be easily applied in Scout fashion, opportunistically upon method visit.

Conflicts

This refactor sometimes conflicts with a "Too Many Parameters" code smell.  Static code analysis may in fact discourage this practice because a real world example may replace a single Widget-like input with supernumerary parameters.The warning here wouldn't be incorrect.  It may be appropriate to create a new subset grouping of Widget's members for this sect of functionality or refactor Widget itself.

Developers should be aware of both "Too Many Parameters" and the problem explored here.  It's best to weigh the trade-offs rather than naively follow the code-analysis.

Links

Comments

Post a Comment

Popular posts from this blog

Engineering Truisms

This is a brief collection of quotes, laws, and truisms that I've gathered over the years.  I've kept those that have consistently proved themselves across organizations and projects during my career.
Read more

The Telescoping Constructor (Anti-Pattern)

Image
The Telescoping Constructor Looks like this: Widget(varA) {...} Widget(varA, varB) {...} Widget(varA, varB, varC) {...} or Widget widget = new Widget(x); widget.setVarA(...) widget.setVarB(...) widget.setVarC(...) There are both shared and specific problems for each variety.  Let's talk about both. The 1st case, supernumerary constructors. What's wrong with this? Well, the good news is you provide  quiet consumption since there's a bespoke constructor for every use case.  Rather than have noisy construction, where the consumer must fill in a bunch of nulls, you move the noise into the implementation.  We shouldn't make assumptions on how many times the class will be used, so keeping the complexity to ourselves is generous and will lead to a more maintainable macro system. However, one problem here is that the end consumer is not restricted in their choice of constructors.  Like shopping at the super ...
Read more

Software Capex: The Cost of Flexibility

We tend to think of flexibility as a good thing.  When it comes to interpersonal relationships, the ability to compromise is considered a sign of maturity.  Shouldn't this be the case for software?  After all, software is just a human solution to a human problem. Well, it turns out that it depends on what exactly we mean by "flexibility."   Flexibility as software extensibility is generally positive.  It's unlikely that we perfectly capture the problem space in an optimal fashion in the first go.  We should strive to make our future selves' lives easier.  Extensibility means, holding all else equal, building a version of the solution that is easier to expand upon in the future.  This kind of flexibility is good.  It means spending a little extra time now to save time in an ongoing fashion in the future.  We'll return to this idea later.   When by "flexibility" we mean producing a solution to an ambiguously defined problem, that's wh...
Read more