最近土日開催になって、個人的には参加しやすくなったJJUG（ジェイジャグ）に参加して来た。今回はJava EE 7とか、ScaleなどのJVM言語などのリリース話、まぁ後はコズミネクサスがどんだけスゴいかっていう宣伝スポンサー様の講演などなど。相変わらず狭義のJavaにとどまらない多種多様なセッションがあって非常にためになった。
個人的には、直近のプロジェクトでは、開発標準化支援や、もっと低級なところだとAPI設計・ネーミングルール策定とかをワシワシやっているので、山本裕介（@yusuke）の下記の発表が本当に勉強になった。Twitter4Jのような広く一般的に拡散していくライブラリのAPI設計方針と、MUT行程でPGが100人を超すくらいの規模のSIでの共通部品設計方針って、結構似たところがあるなあと思った。
- 性悪説に基づく
- そのAPIに基づく全ての開発者が高いレベルを有しているわけではない
- 開発者はJavaDocなどを確認せずにメソッド名から機能を推察して利用する
- コピペ開発
- 拡散したものに手を加えて修正することは大変
- すぐにはupdateしてもらえない
- etc…
みたいな。そのような時にしっかり回すために大切なのは、わかりやすい（利用しやすい）API設計と、「No GGRKS（ノーググレカス）」ポリシーなのだねえ。非常に勉強になりました。発表資料もアップされていたので、あとでまた見返してみよう。
特に印象に残ったのは、下記のくだり。
例えば、Twitter側が「ユーザ情報」と、フォロワー数などの付加的な情報を「ユーザ詳細情報」みたいに分けて提供していたので、JavaのAPIのVersion1.0としても下記のように提供していました、と。
Version1.0
Class User{}
Class UserWithStatus extends User{
getFriendsCount();
getFollowersCount();
}
ところがTwitter側が提供するAPI仕様が変って、フォロワー数などの情報も「ユーザ詳細情報」ではなく「ユーザ情報」に含めるようになりました、と。こういうデカい仕様変更を、どうやってライブラリ側で緩衝していくか（利用者側に対して隠すか）というと、いきなり削除するのではなくて、いったんメソッドを非推奨にして、「利用は出来るんだけどもIDE上では警告が出る」ようにしますと。
Version1.04
Class User{
getFriendsCount();
getFollowersCount();
}
/** @deprecated */
Class UserWithStatus extends User{
}
そしてメジャーバージョンが上がるような大きな更新の時にバッサリ削除すると。
Version2.0
Class User{
getFriendsCount();
getFollowersCount();
}
こうすると利用者側からも比較的変更が緩やかになるね、と。確かに。部品側のAPIを変えるのは利用者（SIだとアプリチームとか）からも苦情がくるし、億劫になりがちなんだけども、だからと言ってイビツな設計のまま時が経ってアプリが育っても、傷口が広がるだけだもんねぇ。こういうところはライブラリ管理方針とかリリース方針（○○な変更はメジャーバージョンアップあげますよ、とかの決めごと）などと合わせてプロジェクト内で整備していくと、利用者（アプリ）側も準備ができるし、事故が防げそうなので、実践していこう！勉強になりました！
JJUGを見終わったら、アベ君から電話で
「今日どっかで壁登りましょうよ〜〜。」
と電話があったので、2日連続になっちゃうけど、二つ返事でOKして、恵比寿J&Sへ。今日は先日残してた7級を平らげて終了！
あべ君は6級を倒して、5級は苦戦してて宿題になってた。こちらも勉強になりました！