設計
このディレクトリ
- モジュール境界 — どこで切るか。切らない判断も含む
- 結合の度合い — 連鎖度(connascence)。結合の種類と強さ、弱い形への書き換え
- レイヤリングとドメインモデル — 層を第一の分割軸にしない。ユビキタス言語、境界づけられたコンテキスト
- デザインパターンの使いどころ — カタログとの付き合い方。「いつ使わないか」を要求する
- 分散システム — 壊れ方の設計。リトライ、期限、過負荷、カスケード障害
- API 設計 — URI、HTTP メソッド、レスポンス、ヘッダー、セキュリティ
- キャッシュ — Memcached と Redis の比較
できるだけシンプル
数年して、設計変更の機会が増えてきても結局はシンプルが一番楽に改修できる
ポーリングはしない
何回も確認するのではなく、完了したら相手に通知してもらう
- 呼び出し側が待ち続けるときの設計は 分散システム を参照
モノリス
最初はモノリスで分けるときがきたら分ける
時間の流れと共に最適なものへと柔軟に進化させる
- どこで分割するかの判断は モジュール境界 を参照
先を読む
先を考えて今やっておいても、結局使わないものにならないか
その時々で現在に最適なものに進化させるのが一番ロスが少ない場合が多い
今やっておく場合と後でやる場合の費用対効果
後でやると膨大な工数がかかる場合は今のうちにどう仕様が変わっても柔軟に対応できるようにしておく
廃止やリプレースを考えておく
廃止やリプレースが必ずやってくる
廃止やリプレースのときを想定しておくことで将来のコストを抑える
廃止やリプレースのときに徐々に移行できるか
作り込みすぎていて独自な実装や設計を極力なくし、世間一般的に最新の実装や設計との差異が少なくなるようにする
廃止やリプレースが想定されていない原子力発電所はどうか
一戸建てとタワーマンションの100年後はどちらが廃止、リプレースが楽か
とりあえず停止してではなく、依存関係を明確にしておく
APIの場合はキー等でAPIに依存しているシステムを明確にして,連絡ができるようにしておく
ユーティリティのツールを作るかどうか
何回も繰り返し行っていることで手間がけっこうかかるため、ツール化した方がよいかどうか
何回も繰り返し行っているものだが、毎回微妙に変わる場合はツール化しない方が複雑なロジックのツールができあがらない
ツール化して、手間が大幅に削減されるかどうか
ツールのメンテ工数に比べて、削減される手間の方がかなり大きいかどうか
視野を広く方針を決めておく
その方針は過去に似たような方針変更があり、結果として2度手間になる可能性はないか
方針を決める際は次にどのような問題が起こるか考えて、再度方針を変えて結局方針が元に戻るケースがないか考える
命名
何をするものかではなく、適当に付けた好きな独自の命名は思考停止を意味する
1や2等の数字やnew等を命名する人は思考が停止していることを意味する
何をするものかという視点で命名する
費用対効果
どれだけのシステムでどれだけの機能を提供できるか
投下と効果の見合いという上位の判断は 原則 にある。 コードの粒度での見方は コード。
各専門家にレビューしてもらう
セキュリティ
国際化
ストレージ要件
プライバシー
各種案の強みと弱み
車輪の再発明はしない
ビッグネームのマネージドサービスがある場合はそれを使う
ビッグネームのマネージドサービスがあるのに自作すると保守・運用に膨大なコストがかかる
ビッグネームがすでに経験してきた同じ失敗を繰り返すのは無駄
自意識過剰になり、ビッグネームのマネージドサービスを超えるものを作ろうとしても結局失敗する
大手メーカーの車があるのに俺が考えた最強の車を作るようなことはしない
推測だけではなく実行する
原則 を参照。設計判断でも同じ。