社内システムの構造と設計、実装のはなし(下書きバージョン)

社内システムの構造と設計、実装のはなし Developers Summit 2014 [13-B-3] #devsumiB 2014/02/13 @tagomoris (TAGOMORI Satoshi)

TAGOMORI SATOSHI (@TAGOMORIS) LINE CORP. DEVELOPMENT SUPPORT TEAM

まとめ社内システムほど他システムとの連携を考えようつまり機能をAPIとして公開しよう社内システムではHTTP JSON APIを使おう実装は必要なところから、必要なだけやろう

Webサービス今昔 Web2.0 とかマッシュアップ全盛期 OAuth 全盛期 WebAPI 制限期

Open WebにおけるAPI トラフィック・レスポンスタイム誰がコストを払うの？互換性 API提供元もやり直したくなることは(よく)ある

社内システム非公開サービス性能よりも機能長いライフサイクル想定ユーザは「自分」

社内システムの機能認証情報共有資産管理プロトコル変換動作状況モニタリング便利UI提供データ蓄積バージョン管理可視化 ……。

何が問題なの？情報と権限の分断どこになにがある？どこで検索すればいいの？情報と機能の冗長化同じ社内でいくつパスワード持たせるんだよ！利用者の効率を考えないシステム勤怠入力300人の労力 >>>> 人事3人の労力自動化の妨げになるシステムそこにしかない情報の参照にマウスクリックが必要「全部入り」でアップデート不可能なシステム UIを持つシステム → クライアント更新も不可に

社内システムの連携 DBを見る SOAP! CORBA! 猫も子もSOAという時代があったんじゃよ Enterprise Service Bus RPC Protocols Protocol Buﬀer, Thrift, XML-RPC, ...

Make it simple! 権限: 分断を最小限にしよう全員参照できてよい情報がほとんどでは？機能: 複数の参照方法を最初から考えようブラウザでの参照 + APIとしての参照ブラウザも同じAPIを叩くのが最もシンプルモジュール化: 単機能システムを連携させようアップデートが容易な状態を保つ

1. 社内システムほど他システムとの連携を考えよう機能をAPIとして公開しよう

Closed WebにおけるAPI トラフィック・レスポンスタイムデータ量が通常小さく問題になりにくい誰がコストを払うの？会社！互換性これが最大の問題 API互換性を維持 + UIのアップデート？

APIの互換性プロトコルの互換性データ構造の互換性データそのものの一貫性の維持クライアント要件の普遍性/不変性

Protocols of internal API Thrift, Protocol Buﬀers, MessagePack-RPC IDL Performance FTP, RSH, SSH HTTP SOAP, XML-RPC, MessagePack over HTTP JSON

長期運用を前提にしようアップデートの容易さ出力部分のシンプルさデータ内容把握の容易さ見ればわかる！テストの容易さ curlで叩きたい

テスト容易性まじだいじ自動テストではなく、人が試す、こと百聞は一見に如かずちょっと試して何が返ってくる、何が見える 100ページのドキュメントより1回のcurl パフォーマンスより大事 Facebookですら、RPCはHTTPでよい (ex:presto) 疎結合

2. 社内システムではHTTP JSON APIを使おう

実装社内システムですよ自分達で作り、自分達で使います動くことが大事ドキュメント、大事？

優先度使う機能、使わない機能顧客相手なら「こんなこともあろうかと」自分相手なら？いま欲しい機能簡単に実装できる、いますぐには使わない機能欲しい気がするけど、微妙な機能

優先度ハックまあ、忙しいよねそれ、本当にJSON APIひとつ追加する30分も割けないくらい忙しいの？機能の追加ってそんな簡単じゃないよね UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい？疎結合モジュールの集合にする単機能追加の時間単位を切り刻む

逆優先度ハック切り刻まれた細かい機能追加タスクそれ、今いらないなら後でやればいいのでは？だっていつでもできるでしょ後でやればいいなら、今後何が必要か考えなくていいのでは？ (将来の)要件定義は難しい、なら後回しにしよう

3. 実装は必要なところから、必要なだけやろう

アーキテクチャと開発・運用の関係アーキテクチャの割り切りが開発・運用を加速する開発・運用の前提がアーキテクチャをシンプルにする

ビジネスへのインパクト社内システムほど試しやすい場は無い誰か損する？誰もが得するでしょ？顧客は自分自分が嫌なものは作らないでしょ？自分が使いたいものを使えるでしょ？

TO MAKE IT SIMPLE MAKES OUR OWN ENVIRONMENTS BETTER THAN BEFORE. LET’S DO WITH YOUR OWN SYSTEMS!

http://tagomoris.hatenablog.com	4967
http://feedly.com	29
https://twitter.com	4
https://plus.google.com	1
http://www.feedspot.com	1

社内システムの構造と設計、実装のはなし(下書きバージョン)

by SATOSHI TAGOMORI, Working at LINE Corp.

on Feb 14, 2014

Statistics

Views

Actions

5 Embeds 4,997

Accessibility

Categories

Upload Details

Usage Rights

Report content

社内システムの構造と設計、実装のはなし(下書きバージョン) Presentation Transcript