13-c-3 社内システムの構造と設計、実装のはなし
選んだ理由
- 今触っているサービスではオープンな部分の機能追加よりも、社内向けの情報を表示したり、連携したりする改修のほうが多いので、その参考に。
- よくあるダメダメな社内システムに対する改善を会社に伝えるときの参考。
ポイント
- 社内システムほど他システムとの連携をかんがえる。
- JSONAPIで連携するのが良さげ。
- OAuth流行、支配的になっている。
- WebAPIの使用制限(googleMap,他OpenWebAPI)
- トラフィック・レスポンスタイムを考慮する必要あり
- コストを払うのは誰なのかを意識すること
社内システムについて
- 性能より、機能があることのほうが優先される
- Long LifeCycle
- TargetUserが自分
問題点
- 情報と権限を管理する人が別
- 情報と機能の冗長化（悪い意味で）
- UXの欠如
- 自動化の障壁
- 全部入り -> アップデート不可能
- 社内システム連携 -> 危険極まりない
権限の分断を最小限に。
- 参照権限はフラットに、複数の方法で見れるように
- UIはAPIを使うのがBest
- 単機能ツールの連携で実現する -> アップデート容易性を担保する
- 機能はAPIとして公開する
- API互換性を担保すれば後ろ側を変えても問題ない
- プロトコル
- データ構造
- ドキュメントに頼らないことが大事
- 意味の一貫性
- Success -> OKとか
- クライアント要件の普遍性と不変性
- クライアントを含めて社内システムです
- 長期運用のことを考えると
- 見た目の分かり易さ
- アップデートの容易さ
- テストの容易さ
大事なのはコレ
- 1 times curl >>> 100 pages dosc
- ease to try >>> performance
- loosely coupled >>> strict protocol
「いま」欲しいものだけを作る
- 優先度ハック
- 機能を切り刻む
- 逆優先度ハック
- 細かい機能追加タスク
- 今いらないならあとで。
- 細かいからいつでもできるでしょう。
- 後でやればいいなら、今は作るな。
- 要件定義は難しい
- 開発・運用の前提がアーキテクチャをシンプルにする
