2006-07-21

近況

私の隣の新人は, このごろいつも困っている.

彼女の担当は移植の仕事. Windows で動いているアプリケーションを Linux でもなんとなく動くようにしろということらしい.

最初の頃は IDE をさわっていた. 先週は Makefile を勉強していた. 一昨日はポータブルに書かれたはずのライブラリ A が主張する未解決のシンボルに悩んでいた. 昨日はポータブルに書かれたはずの C++ のコード B に対する gcc の厳格さにうなだれていた. 今日はポータブルに書かれたはずのモジュール C のなかに潜んでいた 謎の型 HWND を前にして途方にくれている.

気の毒に. でもあまりに典型的なありさま. 思わず笑ってしまう.

私は以前, 可搬性至上主義の会社で働いていた. 可搬性のとても高い社内のコードたちは, Win32/POSIX 以外の環境でも普通に動いていた. バグだらけのコンパイラや SDK が酒の肴という社員達. 社内には奇妙な処理系の振舞いが口伝で蓄積されており, 普通に仕事をしている限り, ひどく可搬性を損ねるコードを書くことはありえなかった. 時々やってくるビルドが通らない旨のレポートはかなりマイナーな物が多く, たとえば, 8 段以上の深いネストの括弧を解釈できないプリプロセッサが 私の作ったマクロに根をあげたとか, そんな話がもっぱら.

原理主義的可搬性

そんな環境にいて, 私は段々と可搬性を嫌うようになった.

理由はいくつかある. 可搬性の実現にも相対的に上手い方法と下手な方法があって, 下手な方法を選んだコードベースを相手に仕事をするのはとても苦痛だったこと. これは話すと長くなるので保留.

可搬性を言い訳にうまれる妥協があったこと. たとえば性能面での妥協. プラットホーム固有の API やインラインの __asm を使えば 速くなる時にも大抵は使わない. 私もあまり人のことをとやかくいえないけれども.

あとは, 行き過ぎだ可搬性のために生産性を犠牲にしていたこと. たとえばあるポータブルな単体テストフレームワークがレポジトリに眠っていた. どこでも動くかわりに使うのはやや面倒なそのフレームワークは (おそらくその使いづらさ故に)普及することはなかった. 単体テストの導入はその敷居の低さがものを言う. ("テストで手を抜く"参照.) 不便で使われないくらいなら, プラットホームの機能を駆使して使いやすいものを作った方がいい.

結局, そこには可搬性信仰があった. 可搬性は宇宙の真理で, それを守り続ければいつかきっといい事がある. 色々な理由から多くの社員がそう信じていた. 可搬性についてあまり信心深い方ではない私は, それを息苦しく感じたのだと思う. (実際, "いいこと" はたまにあった. ただそれが割にあうのかはわからない.)

楽観的可搬性

一方で簡単に実現できる可搬性というのもある. そういうのはやっておいて損はない. たとえば今いる会社で求められているのは Win32 と POSIX で動けば OK という程度の可搬性だ. そのくらいは (範囲を限定すれば) 割となんとかなる. でも実際はあまりなんともなっておらず, 移植をする人々は新人に限らずそこそこ面倒を被っている.

ここには別の信仰がある. それは, 標準 C/C++ と適当な typedef とポータブルなライブラリを使っていれば そのコードはポータブルだというもの. 世間ではこちらの方が人気を集めている気がする.

私はこの信仰があてにならないのを門前の小僧として知っている. ただそれを説明するのは面倒だし知識も断片的なんだよなーと思っていたら, いいタイミングで "Write Portable Code" なる本が出ていた. ので読んだ.

ライト・ポータブル・コード

やや冗長で切れはないが, そこそこ良い本だった. C/C++ で書かれたコードのポータビリティについて議論する. (Java 使えばいいじゃん, などの態度はとりあえず棚にあげることになっている.) なにしろこの話題に絞った本は他に見当らない. 著者もそれが執筆の動機だとしている. これまで可搬性に興味がなかった人が読むには悪くない. 可搬性で問題になる話題はひととおり網羅されていると思う. いくらか原理主義寄りなのは御愛嬌.

序盤にある概念の説明がけっこういい. ちょっと引用:

ソフトッウェアを移植する際に出くわす根本的な原因の大半は,
"不適切な暗黙の前提条件" にあります.
...
このことを念頭に, 筆者は "移植可能なソフトウェアの開発とは,
抽象化を用いて特定の事柄からあ一般的な事柄を切り離すとともに,
暗黙の前提条件を明示的な要件へと変換することである" と考えています.

要するに非機能要件を関心事として明示的に分離しましょうということ. なかなか妥当な定義な気がする.

重要なのは, "コードを移植すること" と "移植可能なコードを書くこと" は
別物だという事実を認識しておくことです.
つまり, 前者は "治療" であり, 後者は "予防" です.

うまいこというね.

移植されたことが一度もないコードを "移植可能" とは呼ばないこと

こう言ってやりたい相手はけっこういるね. (自分とか.)

...

一方, やはり冗長なのはよくない. まず昔語りが長い. また結論の出ない話が多い. 特に後半.

他の話題と同じく, 可搬性の実現は幾つかの原則と それを実践するためのベスト・プラクティスの集合にマップできる. (そう私は考えている.) この本はそのへんの態度がはっきりしない. 原則があるならはっきり言ってほしいし, こうすべきというガイドラインはわかりやすい形で示してほしい. 結局どうすべきなのかがわかりにくい. トピックの中に埋もれてしまっている. どういう種類の可搬性は現実的に実現可能で, どんなものは実現可能だが困難が多くて, 何はそもそもポータブルにできないのか. せっかく序盤で原則を示しているんだから, それとの対応を明らかにしながら 話を進めてほしかった. "結局プラットホームによってまちまちなんだよねー" という話題のたびに 1 ページも 2 ページも使われると本が厚くなってしまう.

話題はいいから読んで損はないけれど, 個人的には Martin Fowler あたりの熟練した書き手に焼き直してほしい. そんなかんじの本でした. 我ながら勝手なことをいってるなあ...

可搬性への動機

そういえば, この本の想定する可搬性への動機がいまいちピンとこなかった. たとえば想定読者として登場する 3 人の開発者はみな メジャーなプラットホームの職業開発者で, ある日マイナー環境への移植を言い渡される 設定. (Bob: JBuilder@win32 -> Eclipse@IBM/AIX, Janice: VB+ACCESS -> Mac OS X, MFC -> Linux)

んー. そういうものなの? これは US と日本の差なのかもしれないけれども, あまりリアリティを感じない. 私のまわりでポータブルなコードを書きそうな人のパターンはこんなかんじ. (半分くらいフィクション.)

要するに, 1. 書くのは趣味のコード. 2. マイナー環境への愛があり, かつ Windows で動かす欲もある. という状況をまっさきに思いつく. というのは, 仕事で可搬にする必要があるなら職場にそういうノウハウがありそうなものだし, Windows から マイナー環境への移行というパターンもあまり多くなさそうだから. 実際のところはどういう人がこの本を買うんだろう. 私の会社では実際そこそこ困っているわけだから, マイナー環境への移行パターンもけっこう需要があるのかな.