mediba advent calendar 2016 12日目担当の @h-sugawara です。
はじめに
油断や慢心し始めた頃に初心に帰るための自戒として記載した目的の記事です。
プログラミングにおける代表的な原則を6つピックアップしてみました。
原則たち
1. KISS
「Keep It Short and Simple.」の英文の各単語の頭文字を集めたもので、「コードは短くシンプルにする」という原則です。つまり、目的の実装をするために不必要なコードを書かないということです。
新しく覚えた技術や将来必要になるかもしれない機能を入れ込みたくなる時もありますが、それが機能の目的と無関係あるいは必要性が無いのであれば、書いてはいけません。この原則は、PIE や Naming is important といった原則にも関連性があり、保守性や可読性を高める意図を持っています。
2. DRY
「Don't Repeat Yourself.」の英文の各単語の頭文字を集めたもので、「繰り返さない」という原則です。つまり、コピペプログラミング禁止ということになります。
同じプロジェクト内で同一の目的を果たすためにコピペをする・しているコードを見かけますが、これは保守性を著しく下げるため、行ってはいけません。同じ内容がいくつも存在するということは、依存関係も複雑になっているため、どこから呼び出されているのか等を把握するのが非常に難しくなっています。そのため、かなり慎重に動かないと修正が不十分なままリリースを行い意図せぬ不具合が発生することになります。
3. YAGNI
「You Aren't Going to Neet it.」の英文の各単語の頭文字を集めたもので、「それは必要にならない」という原則です。必要な時に必要なものだけを用意するようにしましょうということです。
この原則は、KISS 原則にも深く関連しており、今必要ではないコードは書かない、ということです。必要になるだろう、と考えて予め考えて書いておいたコードが、その後に必要になることはあまりありません（仕様を握っている人がプログラミングしていない限り）。むしろ、必要なコードでないものが混入することで、可読性や保守性が低下します。
4. PIE
「Program Intently and Expressively」の英文の各単語の頭文字を集めたもので、「コードの意図を表すプログラミングをする」という原則です。
コードは人が読むものであり、コードそのものが仕様書になるということは往々にしてあります。そんな時に、意図が分かりにくいコードだったら、辟易とするはずです。そういった相手から見た視点で考えた時に、自分が書きやすいコードよりも、相手が見やすいコードを重視しましょう、という視点が、この原則となります。コードは書く回数よりも読まれる回数の方が圧倒的に大きくなるので、読みやすいコードを書くことが品質向上のカギとなるのです。
5. OCP
「Open-Closed Principle」というフレーズの各単語の頭文字を集めたもので、「開放・閉鎖原則」と呼ばれるものです。
「開放・閉鎖原則」とは、拡張が容易で、その修正の影響は受けない、という原則です。機能の拡張が簡単でき、その上で既存の機能に影響を与えない設計のものが、この原則を満たしていると言えます。KISS や YAGNI、そして PIE のような原則を満たしていれば、この原則を満たすこともそれほど難しいことではないのではないでしょうか。この原則に従えているプロジェクトは、高い保守性と拡張性を持っていることになります。
6. Naming is important
名前が重要という原則です。名づけは非常に重要で、名前から判断できない処理を行ってはいけません。getメソッドなのにsetメソッドのような挙動をしたり、○○という処理の名前が付いているメソッドなのに○○の後に△△の処理を行っていたり等です。
振る舞いに名前を付ける時に気付きますが、一つの単語に二つ以上の振る舞いを持つ単語はないと思います。そうした時に、名前に違和感があった場合、それは設計が正しく行われていないことを示します。名前と処理が一対一になるようにした時、KISS や YAGNI などの原則も同時に満たせるようになっていくのです。
まとめ
エンジニアとしては、新しい技術を負うのはもちろん大切なことです。
しかし、それは、プログラミングの原則や思想（今回の記事には記載してはいませんが）を理解し、正しく実践できるようになってからの話ではないかと思います。
原則や思想を理解せず、技術だけを追っているその姿は、食事マナーが悪い状態で新しい料理を食い散らかす姿そのものです。正しいマナーを守って料理を食べられるようになりましょう（ブーメラン）。