A Philosophy of Software Designを読んだので忘備録としてまとめていきます。
A Philosophy of Software Design
- 作者:Ousterhout, John
- 発売日: 2018/04/06
- メディア: ペーパーバック
10章 Define Errors Out Of Existence
例外処理は、実装が複雑になってしまったり、例外処理のテストがやりづらかったり、例外処理をする場合に起こる例外を考慮しなくてはいけないため、システム全体の複雑さを上げてしまう。
例外処理は呼び出し元が意識しなければいけないことが増えるため、インターフェースが複雑になる。
例外処理が多いクラスよりも例外処理が少ないクラスの方がよりdeepなモジュールになる。
システム全体の複雑さを減らしたいのであれば、例外処理の数を減らすこと。
実装されている例外処理が本当に正しいものなのか疑って不必要な例外処理を行わないこと。
低レイヤで例外処理を行うことで、高レイヤに例外処理をさせないこと。
重複した例外処理をスーパークラスなどにまとめることができないか考えること。
例外処理をしてもどうしようない例外の場合、ログ出力後にアプリケーションを終了すること。
例外設計では何が重要な情報で、何が重要な情報でないかを考える。
11章 Design it Twice
ソフトウェア設計は難しいため、最初の直感で設計した方法がベストな方法とは限らない。
選択肢を考え、そのメリデメを洗い出す。呼び出し側が使いやすいかどうかを考える。
シンプルなメソッドになるか。より汎用的なインターフェースになるか。
選択肢の中でベストなものがなければ、それぞれの選択肢のメリデメから新しい選択肢がないか考える。
設計そのものだけではなく設計スキルも改善することができる。
12章 Why Write Comments? The Four Excuses
正しくコメントを記述すればシステムの設計を改善することができる。
コメントを軽視していたり、コメントの書き方を知らないがために、平凡な不要なコメントがたくさん書かれてしまう。
良いコメントはソフトウェアの質を高める。
コメントを書きたくないと思っているエンジニアは、良いコードはそれ自体がドキュメントになるという勘違いをしている、コメントを書く時間がない、コメントは更新されないため誤解をうむ、悪いコメントしかみてきていない、ということを思っている。
コードで表現できないものはコメントで書くべき。読み手がコードを読む前提でコードを書いてしまうと、より理解しづらいコードになってしまう。
コメントを書くことよりも機能実装を優先してしまい、コメントのないコードが生まれてしまう。
コメントとは、コードで表現することができない設計者の意図を表現したものである。
コメントがないと、ドメインの理解をするために時間をかけたり、設計者の意図を正しく汲み取れずバグを生んでしまう。
