ソフトウェア設計のトレードオフと誤りを読みました。
業務用のソフトウェアを設計するときに検討すべき事をコードと共に説明してあります。立ち位置が業務用のソフトウェアで一貫しており、SLA（Service Level Agreement）やメンテナンスという言葉が目立ちます。SLA無しではいろんな事決まらないよねというスタンスはあまり他の本ではみないので貴重な本です。
ソースコードはJavaでライブラリ等もJava関係が多くです。Web系の開発メインで書かれていることもあり、僕の仕事とは7割くらいは関係無いのですが残りの3割がとても面白く読めました。
ただ、関係のない7割の部分のように経験していないところはあまり頭に入ってこず、経験しているところはまあそうだよねとなるので、これを読んで一気に視野が広がるかどうかは業務と自分の立ち位置によるかなと思います。人は経験から学ぶことが大半だなと感じました。
仕事する上で関係無いなと思った箇所は、データベースとメモリ、APIの同期非同期、エラー処理、分散システムと一貫性、ネットワークがからむパフォーマンス等です。本来の想定読者はここだと思う。
面白かったところを紹介していきます。
継承とコンポジションのトレードオフ
本の最初にGoFのデザインパターンが出てきたのが30年前という話から入り、デザインパターンがの整理が始まります。その中で継承とコンポジションのトレードオフについても説明があります。Javaのソースコードを例に課題と解決策が紹介されていて、その瞬間の課題が解決できるかどうかよりも、間違った継承を使う事で一般化されたクラスがそうでなくなったり、継承をした目的からずれているぞといった指摘があります。筆者の立ち位置がこれからメンテし続けるコードだぞって所が面白いです。
僕は継承とコンポジションだとコンポジションの方が良いと思っていて、「継承のために設計し、文書化する。そうでなければ継承を禁止する」の言葉通り、継承して使われるなら最初からそう設計すべきだと思う派です。（C++限定で。Pythonだと雑に継承する）
日付
ここは仕事と関係無いところだったが読み物として面白かったです。 いくつか紹介
- 国内に置いて年齢の解釈は法律で決まっているが、道路交通法は別の解釈をしている
- 2035年以降100年はうるう秒が廃止される
- 日付を扱うアプリケーションのチェックリストの最初が「あなたのアプリケーションは相対性理論を扱う必要がありますか？」
- 1月31日に一ヶ月を足して一ヶ月を引いたとき、1月31日に戻るライブラリは無い
Version管理
適当につけがちなバージョン番号にちゃんと意味を持たせる話が良かった。1.12.3-betaみたいな表記のそれぞれと、互換性との関係を文章化できていて、これは早速仕事に導入したい。初めて聞く話では無いんですが、自社のバージョン管理で悩んでいるとよく考えられているなと感じました。
シリアライズ
ここは仕事ではまりかけたところ。C++の列挙体をそのままシリアライズすると、列挙体が変わった時お手上げになる。面倒でも文字列にした方が良い。これと同じ事をProtcol Buffersを使って説明してあります。後から追加になっても、互換性を保つための工夫も書いてありました。
ただ、こういうのは一回はまると気がつくけど、はまる前にこういう本で知るのは難しいと思うんだ・・・。
API
ユーザーに公開するAPIについても、結構多くの所で説明されています。APIを内部の関数を外向けに公開します程度に考えてしまってぐだぐだになることがありますが、APIはそのアプリケーションの顔なので専門家がレビューすべきだと思う。
僕はAPIを「サービスを提供する起点だけでなくプロダクトをメンテする起点」と考えています。APIを変えずにどう中身をよくしていくか、またAPIを返るとしたらどういう戦略で変えていくのかそういう観点からの説明が多くあり、考え方は間違って無くてもっと良いAPIはどうあるべきを考えないといけないなと思いました。
アプリの設定（付録A）
アプリの設定をどうするかのトレードオフについてのまとめ。付録だけど良くまとまってました。
- ソースコードに入れてコンパイル
- コマンドライン引数
- 環境変数
- 設定ファイル
等など。
