JavaOne2013レポート002-Practices and Tools for Building Better APIs(後半)

前半記事はこちらから

JavaOne2013レポート001-Practices and Tools for Building Better APIs(前半) - desi-gneer(designer_engineer)

4# Usableとは

前半に記載したが、Peter氏は、良いAPIの定義として

1.Valuable(always important)

2.Usable(more important if used more)

3.Stable(more important if used more and longer)

を上げている。

API design は human intarface designに似ているとした上で、

APIのUsableを次の5つの項目に分けた。

1.Learnability(学びやすさ)

どれだけ早く仕様を把握してもらえますか？

2.Efficiency(効率的)

一度ユーザがデザインを把握すれば、「すぐに使える」ことが大切と。

3.Memorability(覚えていやすい)

一度使ったら忘れない。そんな設計素敵ですよね

4.Errors rate(エラーの評価がされている)

エラーからの復帰しやすさも大切とのこと

5.Satisfaction(満足できるものであること)

満足、してますか？

改めて言葉にすると当たり前の要素もあると思いますが、

この5つすべてに不満が無いAPIを作れる人もなかなかいないのでは。

5# Internal Designについて

内部設計については

Example first

Example is most important in API documentation.

と、サンプルがとにかく大事だと述べていた。

これは自分も非常に共感する所で、

APIのドキュメントをみる時はやっぱりまずはサンプルをみます。

あー、大体こんな感じか。。ってのが分かりますもんね。

なければ仕様書を見るわけですが。。

サンプルが充実してると凄く嬉しいですよね、使う側にとっては。

仕様書読めば分かるでしょうというのは、少なからずエゴも含まれていると感じます。

サンプル見ただけで殆ど使い方が分かるAPIは、やっぱり使いやすい。

続いて、

concrete use case,

usability check(具体的なユースケース、ユーザビリティのチェック)

が大切と。

2.Usable(more important if used more)

の

1.Learnability(学びやすさ)

2.Efficiency(効率的)

3.Memorability(覚えていやすい)

を意識してといった所でしょうか。

6# Shapeするために(null check)

繰り返しですが、Peter氏はAPIをshapeすることの重要性を度々述べている。ここから、コードレベルの話に入っていく。
まずは、

Smaller APIs are easier to use.(小さければより使いやすい)

less classes

less methods

less parameters

と。当たり前ですよね。少ない方が使いやすい(usable)、安定する(stable)

本セミナーでは、Null check/Lambda式を例に上げていくつかのコード比較を例に出していました。

pubric void sample(String param){
    if (param == null){
        return;
    }
    //処理
}

こんなコード、書いてませんかって。
あります。うちにはあります。。(涙目
認識してるけど、改めて突きつけられると
JavaOneでの発表ということもあって、
良い例として、
Java SE7で追加されたrequireNonNullを使ったコードが挙げられていました。
Objects (Java Platform SE 7 )
コードが少し短くなることもさることながら、
エラーはちゃんと起こしましょう。

ってのも大事ですよね。

pubric void sample(String param){
    Objects.requireNonNull(param);
    //処理
}

もちろん、googleのguavaを使って、checkNotNullでもいいと思います。

pubric void sample(String param){
    checkNotNull(param,"this parameter must be null hogehoge");
    //処理
}

こっちだとNullPointerException発生時のエラーメッセージ足せるし。

また、JSR305/FIndbugsを利用して、アノテーションを利用して想定外の
null関連の問題が発生を防ぐことも大切と。
@Nonnull: nullを許容しない
@Nullable: nullを許容する
@CheckForNull: nullになる可能性を考慮してチェックを促す
参考:
FindBugs の @NonNull @CheckForNull アノテーション - あるプログラマの日記

話を聞きながら、当たり前だよねと思いつつ胸が痛む自分が。。
基本、、なんですよね。これは。

続いて、基本的にNullを許容しない方針を前提に、
Nullを許容しないInterfaceを作成して、各クラスに
@ParameterAndReturnsAreNonNullByDefalut
のようなアノテーションをつけると、より管理しやすくなるとのこと。
たしかに。

7#Shapeするために(lambda式)

同じくコードをShapeさせる上でLambda式は威力を発揮すると
知っての通り、コード量は減ることが明らかだが、
ビジネスロジックが分かりやすくなることで、

Learnability(学びやすさ)

の面でも効果があると。

###編集中###
(一応コード例をのせる予定)

8#Cheat Sheet書けよ！

そして最後に、Cheat Sheet書けよ！といって、例を見せてくれた。
作ろう、、すぐ作ろう。。

f:id:takahiro-f:20130912003837j:plain

9#まとめ

改めて見直しても、基本的な話が多かったです。

見ていて「はいはい、当たり前ですね。」と思う方もたくさんいらっしゃるかもしれませんが、

当日の反響がそれなりにあったことからも、

実際こういったことを徹底出来ていないサービスを抱えている人

は結構沢山いらっしゃるのではないでしょうか。
もちろん、自分もその一人でした。

また、個人的な見解でもありますが、Learnabilityは、頭のどこかでは分かりつつも、実際に形にしては何かをしているとか、

指標の一つとして目標にすることは少ないのではないでしょうか。

こういった視点の大切さを改めて認識出来ただけでも、このセミナーは自分にとって有意義なものでした。

(おわり)