ロバストネス分析をやってみるとモードレスっていうのはAPIも単純になっていいなと思った
そもそも
私、設計スキルを学ぼうと思っていて、本とか読んで、インプットだけはやっていたんですが、設計スキルを発揮するにふさわしい複雑な問題には出会ったことがなかったです。 もともと設計というプロセスを挟むことによって、時間はかかるようになるし、いつでもどこでも必要とは思っていないです。 いろいろ本を読んだ今でも、設計プロセスをむやみやたらに挟むのは良くない派です。
今回考えた問題
こんなUIが与えられているとします。(Google Keepに保存ボタンがついているものです。) このUIでは、何かしらリストを追加したり、リストの内容を変更したりすることができます。

何やら、複雑そうな気がします。
ロバストネス分析をやってみるとどうなる?
これを一度ロバストネス分析をやってみることにします。 以下の図において、赤い丸が、ユーザが行う操作で、緑の丸がブラウザ上におけるエンティティです。 また、グレーの丸がサーバ上のエンティティになります。

複雑度がお分かりいただけたでしょうか?
注目は赤枠で囲われている箇所です。
このUIだと、フロントでサーバ上のリストにある要素か、ない要素かを保存しておく必要があって、実装が複雑になりそうです。 また、APIとしてもRESTだけで表すことはできず、どうしてもリストに削除フラグなどを仕込んで、削除フラグが立っているリストの要素に対してだけ、削除を実施するなどの工夫が必要です。 私はこのロバストネス分析をやってみた結果、この実装はやりたくないなと思いました。
で、どうしたらもっと単純な実装になるUIになるのかなと考えた結果、世の中のリストUIを見ているとリスト全体を含む塊には保存ボタンがついていないことに気づきました。 つまり、モードレスなUIです。
で、モードレスなUIにするとどうなる?
リスト全体を含む塊には保存ボタンがついていない、モードレスなUIというのはつまり、こういうUIです。

こういうUIにするとロバストネス図はこのようになります。

差がお分かりいただけたでしょうか?
フロントで持っていた状態がなくなり、複雑度が一気に減っています。すごい。世の中の人はすごいですね。やはり、周りを見て、どんな実装にしているのかを確認してみるのは大事です。
いろいろやってみてロバストネス分析がどう効いたのか?
今回、ロバストネス分析をやってみましたが、主に2点有効だったかなと思います。
- 複雑な実装になりそうなことを図で表すことができて、チームでイメージが共有できる。
- 実装を簡略化したことを図で表すことができて、実装が簡単になったことを評価できる。
一度、やってみるということは、その威力が知れてよかったなと思いました。
コメント
コメントを投稿