旧gaaamiiのブログ

間違ったことを書いている時があります。コメントやTwitter、ブコメなどでご指摘ください

JSON色付けたいへん問題

考えごと

この前、以下のツイートを目にして、面白いな〜と思いました。たしかにフロントエンドの仕事は、サーバーからJSONとして返ってきたデータを人向けに表示するという仕事が多く、雑に言い表せてる感じが面白い。

上のはジョークだと思うんですが、とはいえ真面目に考えてみると、JSONを人に見やすくする作業をひたすらやっているのだから、もう少し仕事楽になってもいいんじゃないか？なんでJSON色付け係は相変わらず大変なんだ？という疑問が湧いてきます。それについて、自分なりに考えを整理しておきたいと思いました。

JSON色付け係は何をしているのか

自分の最近の仕事を振り返ると、JSON色付けの仕事は前準備と実装の2段階に分けることができます。

前準備

機能を作る以前に、1行のコードも存在しない段階。

言語やライブラリの選定

もちろんやることによって何を選ぶべきか違うと思うのですが、やることが一般的なJSON色付けなら選ぶべきものは以下の4つになると思います。

言語

ブラウザならJavaScriptで書けばいいんだろうという感じですが、ES5で書くのがしんどいけど、ES5で配らないとちゃんと動かない環境があり、そういう環境でも使ってもらいたいので、なにかしらの工夫をしてES5のJavaScriptに吐き出すような仕組みを使ってます。ここでやるのは言語選びみたいなものです。ES6で書くか、TypeScriptで書くか、はたまたほかのAltJSで書くか。

画面表示

画面に表示するものを、こういう感じで書きたいです。

<h1>{{ blogPost.title }}</h1>

こういったテンプレート機能みたいなもので、このデータはここに表示されるというのを書けるようになります。

また、パフォーマンスでいうと、画面の差分更新（仮想DOM）も多くのライブラリがサポートしている機能です。

ja.reactjs.org

状態管理

ユーザーが画面操作すると状態が変わって、画面も変わる。というのがだいたいのアプリケーションに必要な挙動です。 これをするには、状態をどっかで持っておく必要があります。Reduxとかだと一箇所に状態を集めて、react-reduxで必要なコンテナとつないで状態入れるみたいなやりかたをします。

ルーター

ページ遷移をDOMの書き換えで表現するやり方（SPA）が流行りです。なんで流行ってるかというと、そうするとサーバーとやり取りするデータ量やページの再描画する部分が減って動作が速くなったりするからですが、そういったことを実現するにはブラウザ側に、このURLだったらこのページを表示するみたいなルーターが必要です。

ビルド設定

あと、上の言語選びでも書きましたが、最近のフロントエンドはソースコード書いてサーバーにアップロードして終わりではなく、モジュールを結合して圧縮されたES5に吐き出したりする必要があります。そこで、webpackなり何なりをつかってどうやって吐き出すか、という設定を書いたりします。

実装

一通り整ったら、機能追加の際にコードを書き足すだけになっているはずです。画面を書いて、振る舞いを実装して、色を付けたりします。ここで、なるべくデザインの意図や使われ方を理解して再利用しやすい形にしておけば、以降の実装の手間が減ります。

そこで、コンポーネント指向だったりAtomic Designだったりなんやかんやの方法論で、モジュールや画面パーツの再利用性を実現します。

なにが大変なのか

だいたい上に書いたようなことをやっているわけですが、それを踏まえて改めてなにが大変なのかと考えると、やっぱり前準備がけっこうたいへんです。○○アプリを3ヶ月でつくりたい！といったときに、前準備に1ヶ月かけてしまっては相当つらいですが、何も考えてないゼロの状態から始めると1ヶ月くらいかかってしまいます。

また、ディレクトリ構造やモジュール分けをそのJSON色付け係のセンスで行ってしまうと、実装の属人性が高い状態になってしまいます。

どうするべきか

ライブラリをあれこれ選ぶことはできればプロダクト開発以前に終わらせていて、開発が始まるときには、Railsみたいにコマンドばしばし叩くと雛形が出来上がるような仕組みまでできているとよさそうです。

たとえばangular-cli だと、だいたいアプリケーションに必要なものがng generateコマンドで作れそうです。

ただ、じゃあみんなAngular CLI使えばいいかというとたぶんそんなことはないので、どのライブラリやフレームワークが適しているかなども含めて考えてこれくらいのセットアップやらその後の保守をできるJSON色付けの専門家が、コマンド叩けば適切な場所へのモジュール追加やビルドができる環境を提供する、という形がいいのじゃないかなと考えています。

で、実装者の方はドメイン知識を活かした名前付けだったり、ユーザーの気持ちよさを実現するための技巧を凝らしたCSSアニメーションだったりに集中することができると、整った開発環境の上で、安心してイケてるウェブアプリケーションを作っていけるのではないでしょうか。

それなりに大変

と、ここまで書くと、フロントエンド環境の提供みたいな部分は、JSON色付けとは全く別物ですね...。どちらかというと、実装者のほうがJSON色付け係と言えそうです。

実装するのがJSON色付け係であれば、フロントエンド環境を整える人にもなにか係名がほしいなと思いますが、実際の現場ではそもそもフロントエンド専任者というポジションでさえとても少なく、フロントエンドなんて呼び名でも贅沢なのにその中でさらに名前を持つなんてことは湯婆婆が許すとは思えませんし、その担当が分かれていることは実際にはほとんどないと思います。

ただそれはあくまでも湯婆婆の都合なので、JSON色付け係と呼ばれる仕事の中にも実はいろいろ属性の違うものが隠れとるんだということを忘れなければ、いちいち「フロントエンドなんて大したことやってない。おれはデザインできないしサーバーサイドは中途半端だしデータ分析なんて一切できない...うわあああ」みたいな気持ちにならなくて済みそうです。もちろん全部できる最強な人も世の中にはいるのですが、まあそれはおいといて、JSON色付け係もそれなりに大変だし、一つ一つ丁寧にやってくしかないという気持ちを改めて持ったのでした。