はじめに

「読みやすいコードのガイドライン」という本を読んでいる中で、

KISS

という原則が紹介されていましたので、記事にしてみたいと思います。

なお今回も前回の「YAGNIの原則」の記事の時と同様、

Kotlinで書かれた本著の内容をDartに置き換えて書いてみました。

KISSとは

KISSとは「Keep it simple stupid」¹の略語であり、

「愚鈍なくらいシンプルにする」²

という意味からなる原則です。

先述の書籍の中では、

「自己満足のためにコードを複雑にしない」

といった踏み込んだことも言及されています。

例えば、

ライブラリ、フレームワーク、デザインパターンなどを使いたいがために使用する
フレームワークや標準ライブラリで提供されている機能を独自に再実装する

このようなことも避けるべきであると言及されており、

上記のようなことを避けて、

コードや設計を素朴に単純にしていくことが重要であるとされています。

KISSなコードとそうでないコード

ではここで、KISSなコードとそうでないコードを比較してみましょう。

なお今回のコードは

テストコードが使用するスタブのコードのため、

大元のコードから書いてみます。

// 大元のコード
Stream<List<int>> getActualDataStream() {
  return Stream.fromFuture(Isolate.run(() => dataProvider.provide()));
}

上記のコードは、新しいアイソレートでdataProvider.provide()を実行し、

その結果をFutureとして受け取り、それをストリームに変換して返しています。

KISSではないコードについて確認される際は、

このコードの見た目や戻り値に注目していただければと思います。

KISSなコード

// KISSを踏まえたコード
Stream<List<int>> getStubDataStream() {
  return Stream.value([1, 10, 100]);
}

上記のコードは先述のgetActualDataSingle関数に依存する

テストコードに対してスタブを提供する関数であり、

静的にテスト用の値を返すものです。

見た目からして大変シンプルであり、テストの際も楽になりそうですね。

KISSではないコード

ではKISSではないコードだとどうなるのでしょうか？

これも見てみましょう。

// KISSではないコード
Stream<List<int>> getStubDataStream() {
  return Stream.fromFuture(Isolate.run(() => [1, 10, 100]));
}

見ていただけますと分かりやすいかと思われますが、

大元のコードと見た目がほとんど一緒ですね。

見た目の一貫性を重視してコーディングを行ったのでしょうが、

このコードだと、

「テストで何を検証したいのか？」

これが不明瞭になってしまっています。。。

本来これはテストの際のスタブのコードなので、

KISSに則ったコードのようにシンプルに振る舞いを模してあげればいいのですが、

これだと、

「Stream型の値を返す」
「Stream型に変換する処理をする」
「アイソレートで値を持ってくる」

上記のどれにフォーカスしているのかが分かりにくくなっていまいます...

このぐらいの文量ならまだしも、

これがより長大になってきた場合、

「あれっ、これって何をしたいスタブなんだろう...？」

そんなことが起こりそうな気がしてしまいます...😅

さらに極端になると...

上記のコードでもその気配が何とはなしに感じられたかと思われますが、

ここでそれをより極端にしたものを書いてみます。

// KISSではないコードをより極端にしたもの
Stream<List<int>> getStubDataStream() {
  return Rx.range(1, 2).scan<List<int>>(
    (List<int> list, int _, int index) => [...list, list.last * 10],
    [1],
  ).asBroadcastStream();
}

ここまでくると、なんでスタブのコードを書いていたのかも分からなくなりますね😅

何をしているのか、何をしたいスタブなのか、

これが一読の限りや斜め読みで理解しづらい、

頭の中でイメージが湧いてきづらいコードになっていますね...😱

確かに端的でスマートな抽象度の高いカッコいいコードを書きたくなったりもしますし、

こういったことが求められるシーンもあると思われます。

ただ、殊に可読性という観点に立つと、

それは自分以外の誰か（未来の自分も含め）にとって

本当に優しいコードになっているのかというと、

ちょっと疑問符がついてしまいますよね。。。😭

色々な人がコードに触れ、メンテナンスもしていくので、

可読性も重視して書いていきたいですね☺️

参照

読みやすいコードのガイドライン

「Keep it simple stupid」ではなく「Keep it simple, stupid」の方が有名とのことですが、一部の文献では前者の方がオリジナルではないかとされているみたいです³ ↩
この考えはロッキード社の技術者であったKelly Johnson氏が提唱されたとのことです⁴ ↩
「読みやすいコードのガイドライン」第1章28頁 ↩
同上 ↩