loading...
Cover image for Tidying Up Your Code: KonMari Style

Tidying Up Your Code: KonMari Style

kaydacode profile image Kim Arnett  ・3 min read

If you've been on Netflix, the internet, or talked to anyone recently, chances are you've heard of Marie Kondo or "that one tidying show", aka Tidying Up with Marie Kondo. Marie's method (KonMari) focuses on sparking joy during the tidying process. As best said on her website here

"The KonMari Method™ encourages tidying by category – not by location – beginning with clothes, then moving on to books, papers, komono (miscellaneous items), and, finally, sentimental items. Keep only those things that speak to the heart, and discard items that no longer spark joy. Thank them for their service – then let them go."

Software's architecture is often compared to the structure of a home -- the foundation and building blocks to what will become a house. So doesn't it make sense to compare our code to the clutter in our home? Some homes have more, less, but there's almost always room for improvement. Marie Kondo focuses on creating an organized home that sparks joy. Let's do it! What can we apply from the tidying expert to get our code in better shape and spark joy?

First step: Identify Joy. To some it may be the feeling of holding a puppy, but for technologists, it may be the feeling of opening a file and being able to easily navigate it. Determine what makes you happy when going through code, and aim to get that feeling in your own codebase.

Note: Take an agile approach and make this process work for your team/workflow.

As KonMari does, let's start breaking things down by category.

Challenge: Open your project, and organize things by category. For most codebases, I imagine this would be feature driven, but use what works best for your team.

For every category in the KonMari Method, Marie asks homeowners to collect their items that fit in that category, place them in the middle of the room and then hold each item individually. Items that spark joy, put in a "keep pile" and items that do not, put in a "discard pile".

Challenge: We can't go around killing off ugly code, but lets identify one thing (method, file, etc) that really bothers you or your team about the codebase, and start with that.
The idea with this challenge is not to go rouge and start rewriting your entire application, but instead find areas to improve on over time. Start with what bothers you the most, focus on it, and move on to the next item when you're ready.

  • Break out big functions into smaller scoped methods.
  • Update variable and function names to be more informative.
  • Make small, frequent changes and commits that are easier to track.
  • Streamline similar or duplicated code.
  • To take this steps further, I recommend checking out out practices in Clean Code and Read by Refactoring.

After applying some of these basics to repos I've been working in, I started seeing other areas ready for improvement. Cleaner code revealed that logic not previously tested was not much easier to write tests for.

Challenge: Look at what you've refactored, make sure appropriate unit / UI tests are there, add any that are missing, and remove any unnecessary or redundant tests. A good rule of thumb is to aim that logic is being tested first. Any if statement, data mutations, etc.

The last big area I found improvement in was removing unnecessary views. When you have a lot of contributors, things get messy over time. It's just a fact of development. Using a view debugger, something that allows you to see the layers of your application, can be very eye opening into what is redundant or never being used.

Challenge: Identify super views that have one subview, making the superview irrelevant. Identify views that are hidden and never shown. Identify views that are never added, etc. Cleaning up these views will help with the performance and maintenance of your application.

Again, feel free to modify this to fit your workflow and team's style. Do not take on an application re-write, but instead try to incorporate one small thing into what you're currently working on. Small improvements add up over time. I've been very happy with the results of applying this inspiration from Marie, Clean Code and Read by Refactoring and I think you will be too. If you try it out, be sure to circle back and share how it's going!

Happy Refactoring!

Discussion

pic
Editor guide
Collapse
marek profile image
Marek Zaluski

I find it works well to make small cleanups to a file or a function whenever you're already in the file to work on a feature or bug.

Leave the code a little bit better than you found it.

Tiny, incremental improvements add up.

And like you pointed out, code ghost can remain in a project long after it's no longer being used for anything. It's a great feeling when you can safely delete a bunch of old code and make the codebase smaller.

Collapse
qm3ster profile image
Mihail Malo

One of the biggest pitfalls of this approach is you end up with refactoring commits mixed with feature commits.
It takes discipline, organization, and understanding to put all of your refactoring first, then all of your feature, then more refactoring if you feel so inclined.

Collapse
kaydacode profile image
Kim Arnett  Author

Shoutout to @ben for his scout rule shoutout :D
dev.to/ben/the-boy-scout-rule-is-n...

Collapse
marissab profile image
Marissa B

Leave the code a little bit better than you found it.

Excellent way of going about it, just be mindful of changing too much and falling into the deep "Well I should just clean up this thing real quick... And that thing... Then these things..." pit. 🕳️

Collapse
jamesdengel profile image
James dengel

Yes, I prefer development to be iterated, recursive development leads to issues :)

Collapse
ben profile image
Ben Halpern

Great post. Bringing some concrete principles and metaphors is key to things as abstract as refactoring.

I want to give @andreagoulet for writing a similar post way before Marie Kondo hit peak popularity 😄

Collapse
joshcheek profile image
Josh Cheek

We can't go around killing off ugly code

Note that we can go around killing off process, so process is an especially great place to do this. In agile speak "Individuals and interactions over processes and tools"

Collapse
madisonkanna profile image
Madison Kanna

This is awesome. Thanks for sharing!

Collapse
grandemayta profile image
Gabriel Mayta

Uhm very interesting

Collapse
jaff profile image
Mark Jaffe

Where you wrote: "The idea with this challenge is not to go rouge and start rewriting..." I think you meant "The idea with this challenge is not to go rogue and start rewriting..."