設計を知ることは原則を知ること。『プリンシプル オブ プログラミング』
久しくソフトウェア設計的な本に触れてなかったので、以下の本を読んでみました。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者:上田 勲
- 発売日: 2016/03/23
- メディア: 単行本
「3年目までに読んでおくべき」とありますが、具体的なコード例などはなく抽象度高めの話が続くのであまり経験のない新人がいきなり読んでもいまいちわからないかもです。むしろある程度手を動かした＆アンチパターンを踏んだ経験のある人が読むことで、経験を体系的に整理する（原理原則として活用する）助けになる本です。
著者
上田勲氏が執筆されています。2020年2月時点でキャノンITソリューションズ株式会社にてアドバイザリーソフトウェアデベロップメントスペシャリスト（長い）として働いていたようです。検索すると登壇記事がヒットしたので、書籍と合わせて対外的な活動にも積極的な方なのかも。
概要
ソフトウェア開発現場で度々登場する設計指針や原則、思想、週間などを一つ一つトピックとして解説している本です。章立て毎に中身を一部抜粋したものは以下。
- 前提（すべてに共通する不変の真実）
- プログラムは本質的に複雑であり、常に改善し続ける必要がある
- コードこそがソフトの振る舞いを正確かつ完全に表現し、コードは設計書であることに留意する
- 原則（設計時のガイドライン）
- KISS（コードはシンプルに保つ）
- DRY（同じ処理を繰り返さない）
- YAGNI（変更は必要最小限に留める）
- PIE（コードに『意図』を埋め込む）
- SLAP（抽象化レベルを統一する）
- 思想（一貫したイデオロギー）
- 視点（コードの品質指標）
- 凝集度
- 結合度
- 直行性
- 習慣（良いとされる心構え）
- ボーイスカウトの規則（変更前よりもコードをきれいにしてから去る）
- エゴを捨ててプログラミングをする
- 手法（設計する上でのtips）
- 防御的プログラミング（想定内・想定外でエラーチェックを切り分ける）
- ラバーダッキング（話してみると考えがまとまる）
- 法則（アンチパターン）
- 割れた窓の法則（一部悪いコードがあると全体が悪化していく）
- ヤクの毛刈り（問題が芋づる式に発生した場合、早々に打ち切る or メモを取りながら順番に解決する）
101の原理原則とあるだけにすごく多い（UNIX思想・哲学で数稼ぎすぎだけど）ので、すべて取り上げることはできません。また互いに矛盾するような内容の原理もあるため、その時々で何を優先するかを決定しなければなりません。
よく言うSOLID原則はこの本には載ってませんでした。まあOCPとかポリシーと実装の分離とか、関連するような内容は含まれているのでこれを読んでから知識補間するのもよいかも。
実践
特にインパクトが強そうなものをピックアップし、実践します。自分の知識ドメインや設計経験が偏っているせいで、UNIX思想・哲学はピンとこないところが多かったので触れないことにします…そのうちわかるようになりたい。。
SLAP
「原則」の章はどれも重要なものですが、特にコードを読む上で重要なのはこれです。関数の抽象度レベルを揃え、処理の構造をわかりやすくする効果があります。詳細は以下サイトが参考になります。
SLAP実践の上では凝集度と照らしながらやるのがよさそうな気がします。何も考えず複合関数を列挙すると暗号的・論理的強度のような低凝集に嵌まりかねないので、意味や機能を意識したいところですね。
直行性
コード同士が独立性、分離性を持つように設計します。そのためにやるべきことはいくつかありますが、まず結合度が小さくなるように設計する必要があります。そのためには同一抽象度で機能をまとめたレイヤーを定め、厳格にそれを守った設計をすることです。
組み込みソフトウェアの設計では、マイコンのポート操作のような物理的な制御とアプリケーション毎のビジネスロジックでは抽象度が異なるため、レイヤー化のような手法は度々行われています。むしろハードやペリフェラルICが関わる分、具体→抽象のレイヤー化は他のソフトウェアより容易かもしれません。まあその分処理性能のとのトレードオフが出てくるため、組み込み開発は面倒なわけですが…
ボーイスカウトの規則
誰が名付けたんだって感じの規則ですが（笑）
ボーイスカウトが「来た時よりもきれいにして帰る」というのをもじって「変更する周辺の箇所が汚れていたらリファクタし、元の状態よりきれいにする」という心構えです。ボトムアップでコツコツ改善する方法なのでアーキテクチャや設計全体に大きく影響を与えることはないですが、チームのメンバーが全員これを徹底すればかなり改善効果が期待できます。別の法則として「割れた窓の法則」というのがありますが、継続的に改善することでメンバーの意識を高く維持できる（きれいな状態から汚すのは心理的ハードルが上がる）というメリットがあります。結局ソフトウェアは一人で作るものではないため、チーム全体に広く影響する原則は実践の費用対効果が高そう。
まとめ
ソフトウェアの設計原則に関する本を読みました。「プログラミング」と書かれていますが、さらに抽象度を高めるとエンジニアリング全般に通ずるような内容も多分に見受けられるので、設計者なら教養として読んでおくのもいいかも。
