仕事のアプリは諸事情により一部にカスタムなレイアウトのロジックを持っている。面倒そうなコードなのでなるべく近づかないようにしていたが、ちょっと手直しをする仕事が回ってきたので仕方なくじっと睨む。

これは書いた人がレイアウトというものをわかってないなあ・・・というコード。

べつにすごい深い知識を求めているのではなく、レイアウトというのはまず子の大きさを求めて次に位置を決めてあげる、という二段階構成が基本なんだよとか、ただし位置を決めるプロセスで制約を満たすために大きさを直したりすることもあるんだよ、だとか、縦に積むとか行を詰めてくとか代表的なパターンがいくつかあるんだよ、みたいな。Android の View にしても measure() と layout() の二段構成になっている。

そのカスタムレイアウトは諸事情により View のライフサイクルとは独立したコードになっていて、それはいいのだがレイアウトが二段構成だとか基本的なパターンがあるみたいな事実がコードにまったく反映されていない。厳しい。

しかも興味深いことに、コードの挙動をよく睨むと現状の仕様はそれほど厳しいものではなく、上に書いた conventional な感じに書き直すことができることに気づく。つまりコードが変なだけでカスタムとはいえすごく変な振る舞いをしているわけではない。

これ書いた人たちはどのくらいわかっているのだろうか・・・。たぶんすごく最初の素朴なバージョンはわかってる人がデザインして雑に書いたのを、他の人がいじるうちにわけわからなくなってしまった、とかなのだろうなあ。というわけで肝心の変更をするまえにクリーンな状態に書き直し。これでバグらず直せるぜ。

レイアウトの振る舞い自体にも奇妙なところがあるにはあるのだが、これは書き直しているとよく考えられた巧妙な仕組みであることに気づく。ダメなコードは振る舞い自体もダメなことが多いが、クリーンに書き直すことでコアのアイデアが浮かび上がってくることもたまにある。今回はそういうケース。歴代の UX のひとがよく考えた結果なのだろうな。

自分は UI のデザインをモック画像だけでコミュニケーションするのはよくないと感じている。その理由の一つがわかった。モック画像はコンパイルしたバイナリみたいなもので、UX person の考えた rationale が失われてしまう。Design Language みたいなテンプレ、モジュール化はそうした lost in translation を防ぐ試みとも解釈できる。けれどテンプレや再利用ではない、自分がいま直したコードのようにアプリケーションのユニークな振る舞いを捉えることはできない。

どうすべきか。ひとつには UX person との対話を通じて相手の意図をコードに落としてあげる、つまりモックの一方通行ではなく相手と話をする、DDD みたいなやり方が良いのだろう。自分のチームは対話するところは割とできてる感じがあるけれど、今回直した部分についてはプログラマが意図をエンコードするのに失敗していた。しかもそのために必要なのは readable code 的な hygine skill ではなく UI レイアウトというドメインの知識だった。

という上から目線の話を書きたかったわけではなく、コードはともかくレイアウトの振る舞いがすごくよく考えられていて UX 氏やるな、とおもったという話を書きたかったのだった。でも実例なしに書くのが難しく話がそれてしまったね。