技術書読書ログ「ソフトウェア設計のトレードオフと誤り」

概要

トレードオフはどこにでもある。本書に書いてある内容以外にもたくさんある。

ベストプラックティスと言われるようなものにもトレードオフがある。

型にはまった答えを求めるのではなく、自分の状況にもっとも適したものをその都度選ぶ。

そして、その意思決定を記録・発信していく。

個人的な学び・気付きポイント3点

エラーハンドリング

• 公開API(メソッド)はエラーを明示する
  • 呼び出し元がどのように扱うか決められるようにする
  • 呼び出し元にエラーハンドリングを強制させるかどうかを状況に応じて決める
• サードパーティライブラリの例外は、自分たちのコードでラップしたほうが良いケースが多い
  • 新しい例外がもたらすメリットとメンテナンスコストのトレードオフ
  • エラーの情報を増やすことに加えて、利用者側がサードパーティライブラリと密結合になるのを防ぐためにも、ラップしたほうがいい
  • 非公開のコンポーネント内であれば、ラップしなくてもいい
• Tryモナドを使った関数型アプローチ
  • Javaのような例外を使ったオブジェクト指向言語で、Tryモナドを使う際は注意が必要
  • コードベース全体で一貫させないと可読性が悪くなる
  • メソッドのシグネチャで宣言されていない非検査例外を投げるAPIまでTryモナドで対応するのも、それはそれで読みづらく冗長でもある

日付と時間のデータ

• 日付と時間の取り扱いは注意深く学ぶ必要がある
  • どのアプリケーションでも取り扱うもの
  • 重大な問題が発生する可能性がある
  • 複雑になりやすく、バグも見落とされやすい
• スコープを制限 (今、必要なものだけ)
  • 日時に関するプロダクトの要件は曖昧になりがち
  • 事前に日時の要件を定義できれば、多くの作業を節約できる
• テクニック
  • システムタイムゾーンやシステムの文化(暦法など)への暗黙的な依存は避けて、明示的に利用するか、依存として注入する
  • コメントの活用 (日時に関するコードは理由の解読が難しく、コードだけだと意図が明確に伝わりにくい)

データライフサイクルとトレードオフ

• 変更頻度が低いマスターやリソースなどのデータが対象
• これらのデータの表現方法にもいくつもの方針があり、それぞれトレードオフがある
  • 実装の複雑さ、変更頻度、誰が変更するのか、どのタイミングでアプリケーションに読み込ませるかなど
  • アプリケーションの種類や、状況、開発スタイルにも影響する
• 手戻りがないように予め分かっていることは考慮に入れつつ、オーバースペックにならないようにも気を遣う

感想

トレードオフに対して、どのように意思決定していったか記録して、発信していくこと。
これが自分の状況に適した選択の、その精度を上げるために必要なこと。
たくさんトレードオフに関するTIPSはありましたが、これが一番大事だなと感じました。