読者です 読者をやめる 読者になる 読者になる

Snippets

対抗して作ってみた。

DevUI

俺の Advent Calendar 5日めの記事です。

俺はメインは Androidのアプリの開発をやっています。そろそろ今やってるアプリの骨子の部分はできてきて、で、ちょっと嫌な部分になってきました。UIとかの調整です。

アプリエンジニアの中には、凝った UIを作るのがすきな人もいるのだと思います。でも、自分は苦手です。しかも、Quipper社は自分が人を集めたりしている成果、そういう Android Engineerが集まってきてしまっています。Networkの APIとか、Model Layerで整合性を取るとか、そういうのは得意なんだけど、UI調整というと逃げ腰になるという。まあ、その解消策の一つとして gradle-android-9patch-plugin を作ったりしたわけですが、これは問題の一部を解決しただけでまだまだ苦手感は有ります。

その一つというか大きな要因に、なんでそういう UIにすべきなのかよくわからない、というのがあります。

データベースとかだったら、なんでそういうスキーマにするのか、とかがわかります。今後度のデータが増えていって、どういう情報を見せたいかを考えると、このテーブルを作らなきゃいけないとか。それぞれの技術的選択にどういう得失があってどう決断するかわかります。過去のしがらみとかももちろんありますが、それも技術的負債として将来返済しようと前向きに考えられます。

でも、UIはよくわからんのです。

なんでここでこういう marginが必要なのか、ここの animationはどう動くべきなのか。まあ、画面の遷移ぐらいだと、こうしないと必要な画面にたどり着かないよね、とか判断できるけど、でもやはりわからない点も多い。

あと、やっているうちに考慮していない遷移 (エラーケースが多いけど、それ以外に正常系でも多い) が発生して、そこに対する対処が場当たりっぽいなあ、と感じたり。

で、そういうのはソースにも現れるわけです。最初は conventionつくって ちゃんと意味に則った dimensionとかを予め定義してそれから外れないようにしようと頑張ったりしたこともあったんですけど。 semanticにそういうのをまとめても結局例外とか現れたりして、最初に決めた semanticは何だったのか、ということになる。もう最近はそんなもの抽出するのを諦めて数値ベタ書きになってたりします。UIの refactoringとかできない。そもそも UIの factorってなんだそれ、俺の目には掛け合わされた合成数しか見えないぞ、って感じです。

まあ、ここまで愚痴を延々と書きましたが、そこらへんは Waterfallっぽい開発に毒された脳みそのせいもあるのだと思います。UIについてもコードと同じく継続的に評価と試行を回していくことによって factor outしていく必要があるのだろうなあ、と。

で、表題の DevUIということばにいたるわけです。 DevOpsのように、DevとUIが協調して Iterationを回すことによってお互いに納得しながらいいものを作っていけるのではないかと。

と、最後はちょっとエモくなってしまったので、もっと地に足をついたことを書いたほうがいいのでしょうが、そこまでまとまった tipsがあるわけではなし、ちょっと書けるネタは Sketch 3 Advent Calendar に書く予定なのですみません。まあ、この Advent Calendarやってるうちにも何かトライして面白い結果が出たら書いてみたいとは思います。

でも、考えてみると Webアプリの場合、そこらへんをやってるのがマークアップエンジニアって位置だったりするんでしょうか。どうなんでしょ。