Wednesday, September 11, 2013

Sashimi Coding


Sashimi is a Japanese delicacy consisting of very fresh raw meat or fish sliced into thin pieces. - Wikipedia
Sashimi-coding* is the art of slicing up code into the smallest possible parts. Sashimi-coding works best when used consistently across the entire application. It may seem painful at first, but once you get used to it, you'll wonder how you ever lived without it.

Sashimi-Functions are Tiny

Sashimi-functions are the smallest possible functions.

  • 10 lines max for dynamic languages (Javascript, Coffeescript, Ruby, Python)
  • 20 lines max for static languages (Java, C++, Objective-C)

The Five Benefits of Sashimi-Functions

  1. Easier to understand
  2. Easier to test
  3. More reusable
  4. Self documenting
  5. Inheritance & monkey-patching friendly

Easier to Understand

A function which is twice as long is more than twice as hard to understand. Sashimi-functions are not just a little easier to understand, they are typically much easier to understand.

Easier to Test

Breaking a large function into sashimi-functions allows you to test simpler components in isolation before testing them together.

More Reusable

Slicing a function into many sashimi-functions opens up the possibility of reusing sub-parts of the original function.

Self Documenting

Comments in the middle of functions are a code-smell. Sashimi-functions eliminate the need for these comments. Split the function in two, and the comment becomes the name of the new function.

Inheritance & Monkey-Patching

In both cases, adding custom code must be done in whole-function units. Sashimi-functions make it easy to augment or replace only the code you care about.

Performance Cost?

There is one down-side. There may be a performance cost to sashimi-functions. In static languages the compiler can usually inline away any overhead, but in dynamic languages it depends a lot on how smart the runtime environment is. 

In almost all cases the large increase in developer productivity wins over the small decrease in performance. As always, avoid premature optimization and profile-first so you only optimize what needs optimizing.

* I heard the term Sashimi Coding first from Jason Thane who in turn heard it from Nathan McCoy.

5 comments:

  1. No limits on width though, right? :)

    I remember you talking about this a few months ago and have been actively trying to follow it in spirit ever since.

    Though I have noticed a jarring effect when I have to jump around from function to function while debugging.

    ReplyDelete
  2. Excellent point. I've seen that too. Largely I'm underwhelmed with debuggers for many reasons. Some IDEs such as LightTable are experimenting with presenting your code one function at a time so you could potentially see all the related functions together in one debugging session.

    I've also found when I slice a large function up, the sashimi functions logically go nearby. This helps reduce the mental context switching while stepping through with a debugger.

    ReplyDelete
  3. I just discovered that Sashimi is used in Scrum programming to mean: "A report that something is 'done'." - http://en.wikipedia.org/wiki/Scrum_(software_development)

    ReplyDelete
  4. The two meanings are related, and I think one is a derivative of the other. In Scrum, Sashimi means complete - and clean, clearly defined, conforming to standard expectations, well packaged and shippable, with no "loose ends" (like little scraggly bits of fish flesh).

    I think the corresponding idea in code is exactly what you describe above: self-documenting, clean, completely packaged, divided up thinly enough to be predictable and easily understood, with no loose ends or unexpected side effects.

    From http://www.coldewey.com/publikationen/conferences/oopsla2003/KenSchwaber.pdf

    "This introduces the concept of sashimi, a slice of the whole equivalent in content to all other slices of the whole. For the Daily Scrum, the slice of sashimi is a report that something is done. Done implies accepted engineering practices that indicate that done means coded. Or maybe it means coded, unit tested, checked in, built, and acceptance tested. Either way, there must be a common understanding; otherwise mistakes may be made as various team members inappropriately adapt based on incorrect assumptions of what they inspected. Similarly, the increment created every iteration must be well-defined and similar every time. In Scrum, each increment is an increment of potentially shippable product functionality."

    ReplyDelete
    Replies
    1. (this is from Jason Thane - couldn't get my name or profile photo to appear!)

      Delete