しゅみは人間の分析です

いらんことばかり考えます

GUIを作るならRPCのほうが向いている説 / 読めるようにコードを書くこと

たしかにドキュメントビューア向けならともかく、フルGUIのアプリケーションに向けてRESTのAPIを返すのはなんか違う。いつかのデザイン系の記事で、ユーザはオブジェクトを見つけて〜の行動をしたいのではなく、〜をしたいからアクションを始める云々というのを読んだことがある。もちろんRESTは前者である。

昔はXML RPCとかもあったそうだが、今はまだREST APIの全盛期。GithubからGraphQLが出てきたり、たしかに動詞単語APIでJSON中身いい感じにしてくれやも増えてきている。

しかし、現代のふつうの人はブラウザのアプリケーションとか使ってくれるわけもなく、スマートフォンネイティブのアプリケーションを使い、その使いやすさにも敏感*1なので、UIリッチなアプリケーションに寄せて設計をすると自然とRPC的なAPIができていくのではなかろうか。

個人的な設計の好みとしては、GraphQLのようなぶっといRPCを謎の責務的まとまりごとにエンドポイントを分けて中身はいい感じにやっていくのが良いような気がする。ここでは何をするかではなく、何に対して操作するかという切り分けが出てくるかもしれない。

 

ブラウザバックのボタンがこの世から消えたらアプリ作ってもいいよ

QAまともにやってないところのアプリだいたいブラウザバックで壊れる

ブラウザでアプリを作るな甘えるな 

上記の文脈などに呼応した思いです。ここでのアプリとはUIリッチなブラウザで動くアプリケーションのことです。

 

読めるようにコードを書くこと

その他本日の思いがひとつあって、プログラミングは文章を書くのに近いものがあるような気がしてきたという話です。

たとえば、hoge_enabledというbooleanの変数があったときに、!hoge_enabledと書くよりhoge_disabledという変数あるいはメソッドを定義したほうが読みやすいよねという話です。

!hoge_enabledくらい難なく読める、確かにそうですが、これを読み解くときにhoge_enabledの中身がtrue, falseどちらかを確認してから反転し、そのときの値を意識しながら&&の続きを読むといったスタックを多めに使う認知が働きます。対して、hoge_disabledと書かれていればプログラマ英語がふつうにできる人は、ほぼ無意識レベルの認知で読み下すことができます。なので、あきらかに後者のほうが読みやすいのは間違いないです。ここで、それくらい読めるというのもよいですが、!を使って書き下すかどうかで自転車小屋の議論をするよりhoge_disabledを選んだほうが生産的です。

まとめると、変数名は本当に重要なので手を抜くな。頭を少しでも使う処理は切り出しておけということになりそうです。こんな知見たぶん50年くらい前には発見されているでしょうが、独立に気づいたので主張した次第です。

ここで少し気になったのが、コードを書くうえで英語ネイティブの人は有利なのでは？という点です。データがないので何もいえませんが、もしかしたら有意な差は出ているかもしれません。しかし、我々はいまさら日本語でコードを書ける気がしないし、言語が統一されていると世界レベルで知見を共有できるので我々は英語を書いて読み続けるしかないのです。

*1:というかこのUIわけわからんてなると投げ出して罵倒レビューをしていく