書籍「ソフトウェア設計のトレードオフと誤り」
-1-
テストは粒度を高めることが正解ではない
テストの粒度は開発時間と競合
単体テストを多く立てて品質を上げるのも、統合テストで一気に仕上げるのも策
ただこれは「開発に期限があるなら」の話でもある
デザインパターンで全ての問題が解決するわけではない
シンプル（モノリシック）なパターンは、スレッド安全性などと競合したりするし
高レイヤ（マイクロサービスなど）なパターンは、開発スピードなどと競合したりする
-2-
コードの重複は悪ではない
DRY原則は絶対的でない
ライブラリなどを用いたコードの再利用は柔軟性と競合
共通のビジネスロジックの分離も同じことが言える
重複したコードが柔軟性を高める場合もある
-3-
例外処理
うまくやりましょう
RustやGoは例外処理に決まった作法があり、根本的に解決できる部分が多い
（定例会）
エラーは最終的にどうする？
ユーザーに見せる？
ログに残す？
記憶領域を圧迫しても困る
-4-
柔軟性とシンプリシティは、しばしば競合する
あらゆる新機能はシンプリシティに少なからず影響を与える
-5-
ホットパス
アプリケーションの中で最も大きくリソースの割かれる部分（パス）
ホットパス部分の処理の改善がパフォーマンスに大きく影響する
「ボトルネック」とはそもそも別の概念である
ボトルネックは問題そのもの
ホットパス以外がボトルネックとなっている場合に、そのコンポーネントは最適化を要している
最適化を切り詰めることは正解ではない
パレートの法則
努力はしばしば結果より評価されにくい
最適化をできるだけする、という前に、トラフィック数や計算時間のノルマを設けるべき
これも「期限があるなら」の話
-6-
-7-
日時の管理について
非常にデリケート
システムのタイムゾーンは文化に依存してはいけない
文字列での管理は避けて時刻用の型や外部ライブラリといった既存の枠組みを使うべき
タイムゾーンが変化する場合もある
ここでは重要ではない
-8-
ビックデータを扱う際のトレードオフ
データローカリティの話
-9-
外部ライブラリの使用について
インポートしたライブラリにも責任を負うべき
「あなたが使うライブラリはあなたのコードとなる」
テストも重要
テスタビリティもライブラリ選定の対象である
逆に言えば、自分の作ったライブラリもテストしやすいように設計する必要がある
「意思決定のためのチェックリスト」が非常に良かった
-10-
分散システムについて
「べき等性」の意味について
何度実行しても結果が同じであること
「副作用」がない、という表現よりも的確
-11-
分散システムについて