SOLID, KISS, YAGNIをどう活かすのか
SOLID, KISS, YAGNIはいずれもソフトウェア開発において重要とされる原則です。原則というくらいなので、様々な形態を持つソフトウェア開発において共通して適用することができます。逆に言えば、特定のコンテキストに依存しない程度に抽象化されていると言えるのではないでしょうか。
私はこれらの原則を聞いたことはあるのですが、「わかるわ～」程度の刺さり方しかしませんでした。重要であるけれどいまいち具体的な対処がわからないこれら原則について、今一度おさらいします。
SOLID
オブジェクト指向を用いた開発で、メンテナンスが容易なプログラムを作るための5つの原則の総称。
最高にわかりやすい記事を見つけたので、私が説明をすることはDRYの原則に反します。 postd.cc
単一責任の原則の説明に、まさにActiveRecordのインターフェースを持ったクラスが良くない例として載っています。そうでした。Railsを使っているのですっかり忘れていましたが、本来ActiveRecordはたくさんの責務を持っているのでした。
自分なりの理解
- 単一責任の原則: 一つのクラスが一つのことに関する知識を持つように設計する。
- 開放閉鎖の原則: クラスを追加、拡張しようとしたとき、他のクラスもつられて修正しなくてもいいようにする。
- リスコフの置換原則: サブクラスに依存した実装が存在しないようにする
- インタフェース分離の原則: すべての実装クラスで必要なものだけをインターフェースにまとめる。必要なら細分化する。
- 依存性逆転の原則: 実装でなくインターフェースに依存させる。実装クラスは引数として外から渡す。
SOLIDすべてを満たして設計～実装するのは、慣れていないとなかなかに骨の折れることのように思います。作るときの労力で言えば、新しくクラスを作るよりも、if文を追加してしまったほうがはるかに少ない、というケースが現実にはよくあるからです。
それでも、「ここはこの原則に反しているけど、適用するほど変更が加わりそうな場所でもない」とか、「この原則にしたがって設計したからこのインターフェースになっているんだな」といったことを考えることは、よりよい設計を目指す上で役に立ちそうです。
GoFのデザインパターンを思い出してみると、これらの原則に忠実に設計する方法について述べられていたんだなあと気づきました。これらの原則を意識しつつGoFのデザインパターンをおさらいすると、定着させることができるかもしれません。
KISS
"Keep it simple, stupid" の略。「シンプルにしておけバカ」という意味。
これを最初に聞いたとき、「お、おう。そうだよね。」くらいにしか思いませんでした。
ソフトウェア開発への適用についての詳しい記事を見つけたので、時間があるときに少しずつ読んでいこう。 thevaluable.dev
ソフトウェアは、すぐに複雑になりがちです。複雑なソフトウェアというのは何かというと、たくさんの要素によって構成されていたり、たくさんの要素とつながっているソフトウェアです。シンプルというのはその反対です。
ソフトウェアは、変更によってどんどん複雑になっていきます。このため、KISSの原則を一貫して徹底する、ということがソフトウェアのメンテナンスをかんたんにするという面で重要になってきます。
ソースコードをシンプルに保つ、というのは種々の技術によって実現できるでしょう。でも、システムをシンプルに保つのにはまた別の力が必要です。
とりあえず、KISSは本当に奥が深い、ということがわかったところでよしとしておきます。
YAGNI
"You ain't gonna need it"の略。「そりゃ必要にならんよ」てな意味。XPに関する格言で、必要になるまで実装するなという意味。 http://ja.wikipedia.org/wiki/YAGNI
これはめっちゃわかるし、必要のない機能を付け加えたくなる気持ちもめっちゃわかる。そういうコードの末路も見てきた。いらないコードは書かない、単純なことだけど気をつけていないと忘れがち。
References
下記の素晴らしい記事を参考にしました。
