プログラマーが知るべき7つの格言とは?

 今回のブログは、この前図書館で借りた本の中に書いてあった、
エンジニア界隈にあるらしい7つの格言をcacapon注釈をつけてまとめることにしました。
…返すと忘れちゃいそうだったので(-_-;)

 7つの格言は下記の通りです。


  1. KISS
  2. DRY
  3. YAGNI
  4. PIE
  5. SLAP
  6. OCP
  7. 名前重要

 それでは、一つずつ見ていきましょうか。

KISS (Keep It Simple, Stupid.) (Keep It Short and Simple.)

 コードは短くシンプルに、という格言です。
因みにStupidは愚か者という意味みたいです。オロカモノメ!

 コードを書いていると気を付けてないとどんどん複雑になっていきます。
また、複雑になると修正も難しくなり、テストもしにくくなるでしょう。
 なので、プログラムが腐ってオロカモノ扱いされる前に、
ちゃんと普段から単純で簡単な形になるよう心がけましょう。

DRY (Don't Repeat Yourself.)

 同じコードを繰り返して作るな、という格言です。コピペ厳禁!

 何故ダメかというと……

  1. 読む量が増えます。
  2. 修正箇所が増えます。
    つまり修正漏れが出やすくなります。

 同じ作りのコードが出てきたら、関数にまとめてみましょう。
同じ数字を使っているところがあったら定数などにしてみましょう。
参照箇所が一つだけなら、そこを直せば使うところすべてに適用されます。

YAGNI (You Aren't Goint to Need It.)

 それ要らないよ?って格言です。

 コードを書くとき、「いつかいるかもしれない」コードを書くかもしれません。
…が、基本人間の予測って外れるもの。無駄になることが多いです。
 それこそもう何年もタンスの奥底に眠っている洋服のように、
コードの中に眠り続けることになるでしょう。

 なので、コードを書くときは「今」必要なモノだけ書くようにしていきましょう。
汎用的なコードよりも単純なコードの方が好まれるらしいですよ。

 ところで、これなんて読むんですかね?ヤグニ?

PIE (Program Intently and Expressively.)

 意図を表現してプログラミングしましょうって意味らしいです。 ぴえー※

 コードは、ソフトウェアの動作を「正確に」「完全に」知るための手掛かりです。
動かしているのは「要件定義書」でも「詳細設計書」でもなく「コード」ですから。
コードとそれらの資料がリアルタイムで関連してるかなんて保証されていませんし。

 そんな手掛かりのコードが分かりにくかったら、
利用者、開発者はその分解読に時間がかかるわけです。
人が読むことを意識して、分かりやすく伝える努力をするべきなんでしょう。

 具体的な話は「リーダブルコード」が分かりやすいと思います。
もっと詳しく見たい人は「コードコンプリート」もおすすめですよ。

SLAP (Single Level of Abstraction Principle)

 抽象化のレベルを統一しましょう、という格言ですね。スマップは関係ないです。

 これの分かりやすい例は、目次かと思います。
貴方の周りに目次が書いてある本か電子書籍でもあったらちょっと開いてみてください。
…みましたか?

 どうでしょう?貴方の持っている本の目次がよほど酷いもので無ければ、
全体を理解するのにとてもすっと入るような読みやすいものになっていると思います。
何故読みやすいかは色々理由はあるかもしれませんが、
一つは「構造」が同じだからでしょう。

 この目次が章ごとにリストの深さが変わったり、
一章だけ妙に内容まで踏み込んだ目次になっていたらどうでしょう?
とても読みにくいのではないかと思うのです。

 コードも同じです。
どんどん細分化したはいいけど、一方の関数は詳細にしすぎ、
もう一方は大雑把すぎるとかありませんか?

 人というのは1度目よりも2度目、2度目より3度目の方が理解しやすいものです。
構造を似せて、コードを読む人を安心させちゃいましょう。

OCP (Open-Closed Principle)

 オープン・クローズドの原則っていうらしいです。ここだけ格言っぽくないですね。
何に対して、オープンとクローズなのでしょう?

 オープンしているのは「拡張」についてだそうです。
コードの振る舞いを拡張できることを指しているみたいです。
当たり前かもしれませんが、作り方によっては拡張が非常に難しくなるのでしょう。

 クローズしているのは「修正」についてだそうです。
コードを修正しても、他のコードは全く影響を受けない事を指しているみたいです。
これに関しては、「達人プログラマー」で「直行性」という言葉が使われていました。

 なぜこうするかというと、コードを柔軟に変更できるようにするためです。
新しい機能を追加したいと思っても、拡張しにくいコードだったら大変ですもんね。
機能追加するたび他のプログラムで不具合が出るんじゃ、機能追加できないですもんね。

 明日の自分を楽させるために、作る時はOCPを意識してみたらいかがでしょうか?

名前重要 (Naming is important.)

 プログラミングの中で一番大事なのは「命名」ですよって話です。
何故ここだけ日本語なんだ…

 変数、関数、クラス…コードを書いていると色々な場面で名前を付けます。
でも、てきとーに「tmp」とか「a」とか「retval」とかつけてませんか?
それは名前を考えていませんって言っているもんらしいです。(リーダブルコードより)

 良い名前の付いた関数は一目でそれがどんな機能なのか分かります。
中身を見なくても良いので、読む人にやさしいコードになるでしょう。

 名前を付けるのが苦手な人は、たぶん語彙が足りないです。私がそうですので。
本を読んだり、類語を調べたりして語彙を増やすといいかもしれません。
合わせて英語の語彙も増やしましょう。コードに書くのは英語ですから。



 とこんな感じでまとめてみました。

 この原則はそのままでは抽象的すぎて使えないかもしれませんが、
他の本を調べたり、色々自分で試したりしていると、
身についていくのが、筋トレみたいに徐々に実感できるようになると思います。

 このまとめが皆さんの良いコードに繋がってくれたら幸いです。
それではまた。

※…ピーアイイーなんですかね?私はぴえーって言っちゃいそうです。

参考文献