Don't create leftovers (DCL)September 20, 2020·4 minutes read
In this post, I want to explain another pattern that I see over and over in all kind of projects and it brings problems and impacts the maintainability of your software project. It doesn't affect the source code itself but the organization of the files that compose it.
What is a leftover?
In the lifespan of a software project, code gets created and destroyed to meet users' expectations. During this period, it is easy to generate files, components, and other kinds of stuff that are not used any more. Those undesired pieces of software, make it harder to maintain, impact on your internal metrics, slow down your Continuous Integration check and other kinds of side effects.
Those leftovers from the past, don't bring any value to the project and it can get to the point where nobody is brave enough to do a right cleanup to have a healthy codebase. This goes directly to the technical debt bucket.
Those items should have been removed when the last reference to them disappeared but a developer forgot to remove them. Those leftovers can be a unused image, a unused copy, a unused test on your test suite, etc.
Why do we create leftovers?
HelloWorldcomponent disappears in the future, the copy in
en.jsonwill be forgotten unless a developer remembers to clean it up. At some point in the future, your main translation file starts to have hundreds of unused keys that make you lose money with each new language you want to support.
assetsfolder and the place where they are used is far away?
Take this easy file structure:
post1is no longer needed and it disappears, it is really probable that the
helper.spec.jsfile will be removed after a failing test but those
post1will be forgotten forever.
Check this other example:
Listcomponent disappears, maybe the
List.story.jsxwill fail as a side-effect but nobody will alert you that
ListItemneeds to be removed too.
How to detect it?
This principle shows up like references to parent components or external resources, but sometimes it is harder to detect it.
The rule of thumbs in all cases is to answer yourself the question:
With this question, you imagine yourself in the future removing this shiny new code and seeing all the unused pieces in your source code. Answering this question at this point helps you to know all the dependencies this code has.
To fix this organization problem, the best approach is to encapsulate better all the dependencies. In the case of file structures try to avoid having dependencies to parent components if a dependency is only used once and move them as child components. All those dependencies can start to use relative paths.
Following the previous example, this would be a much better organization:
This new approach has much better encapsulation and a clear set of dependencies. One direct benefit of this is that it lets you move this component to others around without breaking it.
In some cases, like the translations example, you will need some extra step in your toolchain to resolve those dependencies of your views. In the case of the assets one, you will need your builder (Ex. Webpack) to have support to resolve them.
I hope this post helps you to spot this pattern sooner rather than later to keep the maintainability of your project under control.