2007-05-14

近況と免責事項

今月から Community Engine という会社で働いている. ドジ研つながりな人がおり, そののつてでまぜてもらった. 私はこれまで(もっぱら会社や上司への愚痴を書くために)匿名でやってきたけれど, 今回は ボス に身元が割れている. 一番面倒な相手(雇用主+株主)に正体をつかまれている以上, その他の読者から身を隠しても仕方ない. どうせなら会社での暮らしをもっと書くことにしよう.

真面目な会社員であるところの私は仕事をしていると色々思うことがある. でもこれまでは所在を隠すために頑張って文脈を切り離す必要があった. 切り離すのに挫けて書けなかったことも多い. そういう苦労がないのはいいかもしらん. 愚痴を書けないのは寂しいけれど.

忘れないうちに免責事項: このサイトに書かれた主張そのほかは私個人のものであり, 私の所属する組織や団体の意見を反映するものではありません.

近況つづき

会社に入ってしばらくはヒマなもので, 他所のプロジェクトのミーティングを覗いたりしている. このあいだは社内で作っている rails アプリのコードをレビューする会に参加した. 教科書以外の rails コードを見るのははじめてだ. ちょっと感動.

コードで印象的だったのは, Object#send に類するリフレクション機能が けっこう頻繁に使われていたこと. (eval も一箇所あったがダメだしされていた.) 私の中では リフレクション = プログラミングのダークサイド なので, そういうコードを見ると腰が引ける. convention over configuration の流儀に従うと, convention から名前を類推するコードが多くなるのだという. そんなものかも知れない.

一番参ったのは ActiveSupport の Infections::constantize(). 文字列からクラスを作るメソッドが String に定義されている. ひどい... 具体的な使われ方としては, たとえば仮にハンバーガー屋の業務システムがあるとして,

new_burger = (filling + "Burger").constantize.new

という風に使っている. filling はどこかからやってくるパラメタ. "Cheese" など具の名前が入っている. もちろんこんなコードがあちこちに散在しているわけではない. 各 Burger クラスは AbstractBurger (まずそう...) を継承し, インスタンス化は make_burger() のような factory method に局所化されている.

それにしても不穏だ. このコードが不穏というより, Infections#constantize() が不穏なのだと思う. 私の脳内には, 文字列引数 -> リフレクション -> ダークサイド というチェック機構がある. constantize() は, self に文字列を隠して この脳内チェックを切り抜けようとする. それが怖い. 間違ったコードは間違って見えるようにする の原則に反し, その簡潔な名前はむしろよく使えと促す. (使いやすいライブラリAPIデザイン(PDF)|http://ja.reddit.com/info/7n1a/comments 参照.) 少し前, Apple のデザインを "they look more perfect than they really are." と評する 記事 があった. rails の API もそれに似たところがある. 本来目につくべき粗, ロジックの複雑さを隠してしまう.

ただ, そもそも ruby でのリフレクションはどれだけダークなんだろう. いまいち確信がない. リフレクションが危険だと感じるのは型システムの支援を受けられなくなるからだが, duck typing な言語にはそもそも型チェックがない. JavaScript のオブジェクトに至っては単なるハッシュ表だ. リフレクションも何もない. この動的な世界で, コンパイラへの期待から身に付けた習慣を どれだけひきずれるのか. いっそ String#burgerize() を実装してしまうのが dynamic/rails way なのかもしれない.

API のユーザビリティ・テスト (が欲しい)

API の良し悪しで思いだしたこと.

このごろ友達が API 設計に凝っているらしく, 本屋に行くと "良い API を作るための本はないかなあ" という. "GoF とか PoEAA は?" とやる気のない答えをしたら酷寒であしらわれた. PoEAA を読んでないのがバレたかと思ったが違うらしい. 彼が探しているのは, API のユーザビリティテストをする方法や, その結果をふまえたデザインの手法だという. たしかにそういう話は見たことがない.

良い API の設計に関する言い伝えは多い. しかし API の良さを定量的に扱う方法は多くない. 私が知っているのは依存関係から複雑さを測る方法くらい. UI の議論をすると, 最後はいつもユーザビリティテストの話に行き着く. このテストはそれなりに定量的な手法と言える. API の設計に関する議論が同じように進まないなんて, 考えてみれば不思議なものだ. API や, より広くソフトウェアの設計が Art や Cult の世界に留まっているのは, プログラマに残る未熟さのあらわれかもしれない.

テスト・ファーストや設計レビューといったアドホックな兆しはある. この路線を推し進め, 感情的にならず統計的な方法で API の良し悪しを議論できたらいいと思う. やっぱりユーザビリティ・テストだな. この API でコードを書いてもらえませんか. 道ゆくプログラマをつかまえて尋ねる. ノート PC を手渡す. コード. そして実行. 例外が発生し, テストは fail する. 私はカメラから画面を覗き, 悩んだ末に渡された引数の null を前にうなだれる. その引数が null なのはなぜかと司会役が訊く. Object 型だったから, 彼女は答える. なんでもいいのかなって. 違うんだ. 私はつぶやく. あなたが悪いんじゃないんです. 悪いのはこの API です. 司会役は申しわけなさそうに告げ, セッションが終わる. ご協力ありがとうございました.

あ, 想定ペルソナは "明るく可愛い課のアイドル(22). レガシー API を盾にとった上司のセクハラが悩み" といったところでよろしく.

追記 : リファラから

Ruby のリフレクションはダークサイドか より

IDEによる支援がほとんど無い Ruby なら一度ダークサイドに落ちてみるのもどうでしょうか:D

とのこと. この一言を待っていたかも! 普段のやっつけスクリプトだとそもそもリフレクションの出番を思いうかないから, フレームワークっぽいものを作りたいなあ.