Entries

スポンサーサイト

カテゴリ:スポンサー広告
更新日:--------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

2011年9月5日の作業日報。APIで担当を分けないほうがいいんじゃないだろうか?

カテゴリ:作業日報
タグ: Ajax  API 
更新日:2011-09-05
T社。Delhi+MySQLシステム

センサーごとに通信部をDLL化して、センサー追加で本体を変更しなくてもいいようにしようとしたけど、不具合がありそうなので、とりあえずDLL化をあきらめて組み込むことにした。まずは、安定して動かないことにはどうしようもない。

3ポモドーロ。

fintopo。ライフログ「ペリドット」

レポート編集機能のAjax化。

4ポモドーロ。


Ajax化すると、従来はページ遷移での設計が、APIによる設計に変わる。で、いろいろ修正していて、今考えているのは、APIの設計は、ユーザーインターフェースを設計している人が一緒に設計したほうがいいんじゃないか、ということ。

たぶん、一般にはAPIで切り分けて、サーバープログラムの開発とクライアントプログラムの開発の担当を分けてるんじゃなかろうか?だけど、これだとAPIが枷になって、それぞれに効率的なコードが組めないように思う。「こんなデータ構造になってれば、コードが簡単になるのに~!」みたいな。それに、汎用的なAPIを考えるのも、結構難しい。

それより、サーバープログラムとクライアントプログラムを作る人が一緒で、その人がAPIを設計するなら、それぞれにとって効率の良いプログラムになるんじゃないだろうか?サーバーに負荷を増やすのか、クライアントで処理するのかは、開発している端末の性能によっても変わるだろう。APIを変えるために、わざわざ担当者と打ち合わせをする必要もない。

代わりにデータモデルとの間にインタフェースを儲ける。モデルインターフェース?てか、RDBやオブジェクト指向などの違いはあっても、データモデルが構築されるとモデルインターフェースは自然と決まってくる。特性の差はあるけど、これはアーキテクチャや開発モデルの選択時の問題だろう。

Web-APIに限らず、通信プロトコルを決めて送信側と受信側で開発を分担するというのは、よくあると思うけど、すでにオープンな規格ならともかく、そこそこクローズドな環境での開発なら担当を分けないほうが楽だよね。特にユーザーインターフェースで使いやすさを考えていくときには、APIは固定していないほうがいい。ある程度、機能や構造が安定してくればAPIで切り分けるのもいいだろうけど。

課題としては、プログラマーにサーバープログラムとクライアントプログラムの両方の技術が必要になること、代わりの役割分担をどうするか、APIの重複の回避、外部ユーザーに対する公開APIの設計はどうするか、など。役割分担は機能別でも良さそう。APIの重複や公開APIの整理は、ある程度、構造が決まってきてから、リファクタリングか?


モミジ模様が綺麗な急須。今年の紅葉はどうだろうかねぇ?


スポンサーサイト

Appendix

プロフィール

いむら@fintopo いむら@fintopo

フリーのシステムエンジニア兼プログラマです。趣味はガーデニングとカメラ。2017年4月にα7IIを買いました。フルサイズ一眼初心者です。

このページのQRコード

季節暦

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。