4.2 守破離
4.3 第一原理
4.4 原則となるために
4.5 プラクティスとなるために
4.6 原則がプラクティスをガイドする
内容
ソフトウェア開発を守破離に則った考えで説明。
- 守
ルールや形式知を学び、背景の理論、目的をそこまで深く知らずに型から入る。型から入るのは、背景の理論や目的は抽象的で理解しづらいから、実践し経験しながら理解を深める。
ソフトウェア開発で例えると「TDDのルールを覚える」など。 - 破
実践し経験しながら、背景の理論、目的を理解していくフェーズ。
ソフトウェア開発で例えると「TDDを実践し、メリットを体で感じる」など。 - 離
背景の理論、目的を体現した状態で、さらに新しい理論を導き出すことができるようになる。継続的な学習・鍛錬で行き着くことができる。
ソフトウェア開発においても同じことが言える。
ソフトウェア開発の「守」にあたる原則として代表的なもので、「単一責務の原則」「オープン・クローズドの原則」などがある。
単一責務の原則
原則：クラスを変更する理由は１つでなければならない。
理論：システム内のクラスがそれぞれ一意の役割を持つことで、クラス間の相互作用がわかりやすくなる。テストもしやすくなる。
オープン・クローズドの原則
原則：エンティティは拡張に対して開いていて、変更に対して閉じているべき。
理論：既存コードを変更するほうが新しいコードを作るよりバグが発生しやすいから、機能追加する場合は既存コードを変更せずに新しいコードを追加できるようにしたほうがよい。
これらはソフトウェア開発で重要な原則の一部として一般的だが、原則なだけであって、どうやればそれができるかは語らない。
実現するためのプラクティスはいろいろあるが、さまざまな経験を通して理論を実感し体で理解していかないと、「変更可能な品質を作り出すためにプラクティスを使いこなしている」ということにはならない。
また、ソフトウェア開発もまだまだ未発達なので新しい原則やプラクティスが生まれることもあると考えられる。
原則は簡潔でなければならない。
原則は良いソフトウェア開発に導いてくれるため、くどくどとわかりにくいものではだめだ。
原則ができたのなら合わせてプラクティスも必要で、プラクティスは
- ほとんどの場合に価値がある
- 学ぶこと、教えることが簡単
- 考えなくてもいいくらい実施が簡単
でないと、チームの習慣化はできない。
原則とプラクティスがこの条件を満たしたとき、これらは良いソフトウェア開発のためのツールとなり得る。
この本では、これらの条件を満たした９つのプラクティスを紹介する。
学び
- 守破離の例がわかりやすい
- 頭だけ理解してもだめ。体でも理解しないと。
- 実際に経験するには、自分で機会を作っていかないと、会社の案件だけではチャンスが恵まれない可能性もある。
学びを活かすアイディア・行動
- 自分でサービスを作り、プラクティスの練習をする
