ソフトウェア設計

KISS原則:コードをシンプルに書くことの本当の意味

開発をしていると、コードを難しく書くほど仕事ができるような気がしてしまうことがあります。

読了 5 分
KISS原則:コードをシンプルに書くことの本当の意味のカバー画像

開発をしていると、コードを難しく書くほど仕事ができるような気がしてしまうことがあります。

デザインパターンを大量に組み込み、抽象化レイヤーを積み重ね、「あとで拡張するかもしれないから」とインターフェースまで先回りして用意します。

ところが数年後にそのコードを開くと、苦労するのは未来の自分だったと気づきます。

今日は、その対極にある原則、KISSについてお話しします。

結論から言うと、KISSは「Keep It Simple, Stupid」の略です。直訳すれば「シンプルにしろ、間抜けめ」ほどの意味です。

システムは複雑に作ったときではなく、シンプルに保ったときに最もよく動くという設計思想です。


KISS原則はどこから生まれたのか?

この言葉は、もともとソフトウェア用語ではありませんでした。

1960年代のアメリカで、ロッキード社の航空エンジニアだったケリー・ジョンソン(Kelly Johnson)が生み出した言葉だとされています。彼は有名なU-2やSR-71ブラックバード偵察機を設計した人物です。

ケリー・ジョンソンがチームに求めたのは、次のことだったそうです。

戦闘中でも、一般の整備士が基本工具だけで修理できる航空機を作れ。

どれほど優れた設計でも、現場で修理できなければ意味がありません。

この精神がソフトウェアにも受け継がれました。どれほど巧妙なコードでも、仲間が読んで直せなければ良いコードとは言えません。

ちなみに「Stupid」は開発者を馬鹿にしているのではなく、「誰でも理解できるほどシンプルに」というニュアンスに近い表現です。


コードでKISSが崩れる瞬間

言葉にするのは簡単ですが、実際のコードではどのような形になるのでしょうか。私がよく見かけるパターンをいくつか紹介します。

1. いかにもすごそうな1行

// こう書くと賢そうに見えます
let result = arr.reduce([Int: Item]()) { $0.merging([$1.id: $1]) { _, new in new } }

// こちらのほうがずっと読みやすいです
var result = [Int: Item]()
for item in arr {
    result[item.id] = item
}

上のコードは短いものの、初めて見る人はしばらく読み込まなければなりません。下のコードなら、誰が見ても3秒で理解できます。

2. 使わない拡張性

ボタンを1つ作るだけなのに、ファクトリパターンやストラテジーパターンまで持ち出すケースです。「あとでボタンの種類が増えたら?」という心配が理由ですが、その「あとで」はほとんど来ません。

3. 条件分岐の迷路

ifの中にif、その中にさらにif。3段階ネストするだけで頭の中のスタックがあふれます。そんなときはearly returnで展開するだけでも、コードは一気にシンプルになります。

複雑なコードとシンプルなコードは、6か月後に差が出ます
複雑なコードとシンプルなコードは、6か月後に差が出ます

KISSを守るための実践的な3つの基準

そこで私は、コードを書くときにこの3つを基準にしています。

基準 質問
説明テスト このコードを隣の同僚に1分以内で説明できるか?
未来テスト 6か月後の自分が見ても、すぐに理解できるか?
必要性テスト 今すぐ必要だから入れたコードか、それともいつか使いそうだから入れたコードか?

1つでも「いいえ」なら、もっとシンプルな方法がないか考え直します。

特に3つ目が重要です。これはYAGNI(You Aren’t Gonna Need It)の原則にも通じます。KISSとYAGNIは、実質的にセットで機能します。


シンプルなことと雑に作ることは違う

ここで誤解してはいけないことが1つあります。

KISSは「何も考えずに書け」という意味ではありません。むしろ逆です。

複雑にするのは簡単です。思いついたものをすべて付け足せばよいからです。シンプルにするのは難しいものです。何を削るか、真剣に考えなければならないからです。

パスカルが手紙に残した有名な言葉があります。

もっと短く書く時間がなかったので、長く書きます。

コードも同じです。シンプルなコードは雑に作った結果ではなく、複雑さを取り除く努力の結果です。

シンプルさは削ぎ落とす努力の結果です
シンプルさは削ぎ落とす努力の結果です

まとめ

KISS原則をまとめると、次のようになります。

  • コードは書く時間より読まれる時間のほうがはるかに長いものです。読む人のためにシンプルに書きましょう。
  • 今必要のない拡張性は入れないでください。その心配が現実になることは、思っているほど多くありません。
  • シンプルさは実力不足ではなく、実力の証です。

最近のコードレビューでは、「これ、もっとシンプルにできませんか?」というコメントを一番多く残している気がします。不思議なことに、この一言だけでバグもレビュー時間も減ります。

あなたのコードを、隣の同僚は1分以内に理解できますか?今日は一度、自分に問いかけてみてください。

あわせて読みたい