プログラミングに特効薬や万能薬はない――複雑さへの対抗手段としての抽象化とKISS：問題解決力を高めるコツはプログラミングの原則・思考にあり（3）（4/4 ページ）

[上田勲，著]

KISS

　英語　　Keep It Simple, Stupid.または　Keep It Short and Simple.

　日本語　　シンプルにしておけ、愚か者よ。または　簡潔かつ単純にしておけ。

　What　〜コードをシンプルに保つ

　コードを書く時、最優先の価値を「単純性」「簡潔性」に置きます。

　新規に書く場合だけでなく、障害を修正する場合、機能を拡張する場合も、常に、複雑にならないよう意識して、コードをシンプルに保ち続けます。

　Why　〜コードは無秩序へと向かう

　コードは、自然に任せて修正していくと、無秩序になり、複雑になっていきます。

　複雑なコードは、読みにくく、修正しにくくなります。むりやり修正しても、品質が悪くなり、時間もかかります。これでは、適切なタイミングで、修正版をリリースしたり、バージョンアップを行うことができません。それでも気にせずそのまま突き進んでいくと、いずれ誰も理解できないコードとなります。そして、最終的に、改善しようとしてもできない「腐った」コードへと行き着きます。

　これに対して、シンプルなコードは、構成する各要素がすべてシンプルで、各要素が担う責務が最小限に抑えられています。各要素同士の関連もシンプルです。よって、シンプルなコードは、読みやすく、理解しやすく、修正が容易です。各要素の責務が明確なので、テストもしやすくなります。コードを通じたプログラマ相互のコミュニケーションが楽になり、現実世界で余計な会話をしなくて済むので、コミュニケーションのコストも節約できます。開発速度を落とさずに、ソフトウェアの長期間に渡る保守が可能になります。

　コードには、必ず変更が入ります。コードをシンプルに保つことによってもたらされる「修正容易性」は、欠かせない、守っていかなければならない、コードのコンディションです。

　How　〜コードに余計なことをしない

　シンプルを、プログラミングの羅針盤としましょう。コードから、余計なこと、過剰なことを可能な限り排除します。

　そのためには、プログラミング中、「動作させるために、もっともシンプルなものは何か」と常に問いかけるようにすることです。

　精神論ですが、このことは思いのほか重要です。意識して作業をしていない限り、複雑へと向かってしまうからです。例えば、以下のようなケースが考えられます。

• 1．新しく覚えた技術を使いたい

　ある技術を覚えたての場合など、それを使用したいがために、不要にトリッキーなコードを書いてしまうことがあります。

　しかし、コードは、頭のよさをアピールする場ではありません。ユーザーに価値を提供するものです。「クレバー」になってはいけないのです。

　そのコードの書き方が、本当に必要かどうかを常に吟味し、コードがシンプルであり続けることに「愚直」に取り組んでください。

• 2．将来の必要に備えたい

　将来必要になるかもしれないので、そのためには今書くのがベストだと考え、過剰なコードを書いてしまうこともあります。

　しかし、今不要なら、今書くべきではありません。ほとんど場合、それは必要にならないからです。

　必要になった時、必要な分だけ書くようにして、シンプルを保ちましょう。

• 3．勝手に要件を加えてしまう

　勝手に要件を判断し、余計なコードを加えてしまう場合があります。必要かどうか、正しいかどうか、ユーザーに判断を仰ぐより、コードを書いてしまう方が簡単だと思ってしまうのです。

　しかし、要件を決めるのはユーザーです。プログラマが要件を決めてはいけません。

　ここで不要になる可能性のあるコードを加えてしまえば、保守にかかる手間と時間は、雪だるま式に増えることになります。要件にない、余分なコードを書かないことが、シンプルを保つ秘訣です。

　発展　〜KISSの適用範囲

　KISSは、ソフトウェア開発の中で、コードだけではなく、外部仕様にも適用できます。

　機能ばかり多くて複雑なソフトウェアは、結局使われなくなります。機能、そしてそのインタフェースをシンプルに保つと、使いやすい、使われるソフトウェアになります。

　なお、KISSは、もともとエンジニアリング全般に適用されている原則です。ただ、成果物の複雑化の傾向は、ソフトウェア開発で特に顕著に見られます。要求に対して、比較的柔軟な対応が可能であると思われていることが、その一因です。

　関連1　〜less is more

　「less is more」は「より少ないことは、より豊かなこと」という意味です。もともとは建築分野の言葉で、装飾などの表層的な要素と、空間構成などの内的な要素の両方を減らし、単純化することで、様々な外的要因に耐えうる建築物が計画でき、より豊かな空間が生まれるという思想です。

　これはソフトウェアにも当てはまります。余分なコードを書かないことによって、コードをシンプルに保ち、様々な問題を未然に回避することができるのです。また、そのようにしてできあがったソフトウェアやコードは、洗練されて美しいものになります。

　そのためにも、「今自分が書いているコードは本当に必要なものなのか」と常に自問自答しなければなりません。

　関連2　〜オッカムの剃刀

　「オッカムの剃刀」とは、「ある事柄を説明するために、必要以上に多くの前提を仮定するべきでない」という考え方です。別の言い方をすれば、「何かについて、いくつかの説明が可能な場合は、もっとも単純なものが正しい」ということになります。事柄の理解に対する、思考の負荷が減るからです。

　この考え方は、プログラミングにおいても有効です。コードが実現している機能が同じならば、余分なものを含まないコードの方が、読み手の負荷が減り、読みやすい、改善しやすいコードになります。

出典書籍

『The Art of UNIX Programming』Eric S. Raymond, アスキー（2007）

関連書籍

『達人プログラマー―システム開発の職人から名匠への道』アンドリューハント他, ピアソンエデュケーション（2000）

『ソフトウェアアーキテクトが知るべき97のこと』鈴木雄介他, オライリー・ジャパン（2009）

『プログラマが知るべき97のこと』和田卓人他, オライリー・ジャパン（2010）

『プロダクティブ・プログラマ―プログラマのための生産性向上術』Neal Ford, オライリー・ジャパン（2009）

『XPエクス

トリーム・プログラミング入門―変化を受け入れる』ケントベック, ピアソン・エデュケーション（2005）

書籍紹介

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

上田勲著
秀和システム　2,200円

一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか？ 本書は、よいコードを書く上で指針となる前提・原則・思想、つまり「プリンシプル」を解説するプログラミングスキル改善書です。初心者向けの書籍では絶対に説明しない、古今東西のプログラマーの知恵をこの一冊に凝縮しました！