2008-02-11

コードと Communication

Kent Beck の Implementation Patterns を読んだ. 薄いのがエライ. 内容は Java のイディオムをまとめたようなものだけれど, イディオムという言葉の印象ほどトリッキーなものは多くない. 凡庸なものだ. だからパターンなのだろう. 新鮮味のない, ある意味どうでもいい内容ではあったけれど, 逆にこりゃひどい, というものもあまり無い. 良いパターンと言えるのかもしれない. パターンといいつつパターン言語の様式に揃える様子がさらさら無いあたりは宗主の貫禄. そのせいでいまいち納得できない部分もあったけれど, 薄さとのトレードオフという気はする.

本編はさておき, 前書きと導入部はなかなか読ませる. Kent Beck は自身のプログラミング原則として, その一つ目に "Communication" を置いている. コードの可読性を高くしろ, と主張するのはよく聞くけれど, この原則は可読性の根拠を端的に伝えている.

ただ Kent Beck は自身の原則を過小評価しているのではないかとも思う. 書き手の意図とは無関係にコードは他人と communicate してしまう. 書き手がどれだけツンな態度を取ったところで, 読み手はコードから様々な意図を読み取る. だからコードは communication のためにあるべきだ, という主張は主張にすらならない. 高級言語で書かれたコードは所与の性質として communication を行う. だから原則としての communication に言及するなら, コードは 書き手の意図どおりに communication すべきだ, とでも言うべきだろう. 仮に Intensive Communication の原則とでも呼んでおこう.

Communication と意図

Intensive でない communication とは何だろう. 世の中には伝えたくないことが伝わってしまう communication もある. 自信なさげに研究発表をする学生は, 額の汗や早口から自身の成果がもつ弱点を漏らしてしまうだろう. 神経質で焦りがちな男達は, デートをしている女の子の身振りから 隠された不穏な(稀に嬉しい)メッセージを読み解こうとするだろう.

コードも書き手の意図しない思惑を伝えてしまう. なげやりな設計はやる気のなさを伝えている. 大量の FIXME は切迫感を伝えている. 一貫性のないインデントや変数名はチームの意思不統一や個人の迷いを伝えている. 過剰な indirection は不信感を伝えている. cryptgraphic なコードはハッカー的な虚栄心を伝えている. など.

Intensive な communication にも様々な種類がある. Kent Beck が言及しているのはそのごく一部にすぎない. 前書きから引用すると, KB の communication 原則は次のように問う. "What do I want to tell a reader about this code?" これは <説明> としてのコードを示唆している. KB のいう communication は, その大半が説明に見える. たまに <指示> があるかもしれない. そのほかの intensive communication はどこに行ってしまったのだろう. たとえば <恫喝> するコード, なんてのはあるだろうか.

様々な Communication


さすがに仕事で恫喝はしないにせよ, 仕事の communication が <説明> と <指示> で済むなら PM が胃を痛めることはないだろう.

たとえば短い名前の関数は, その利用を <勧めている> かも知れない. XxxManager は設計のまずさを <謝っている> かもしれない. 誰かの作ったインターフェイスを実装するのはある種の <合意> だろうし, クラスを継承するのは <君を信じてる> と言うようなものだ. 既存の API をプロジェクトやモジュール独自でラップしたら, それは <不満> や <不信> の意思表示と取れなくもない. インターフェイスの定義は <提案> や <説得> を含むことがある. facade の裏にある実装へのアクセスを一切禁止するのは <威嚇> かもしれない.

コードの上の communication 不全を正すのも PM の仕事だろうか. ちょっと無責任な気がする. プログラマ同士で何とかすべきだろう. 技術主任なんてのはそのためにいるんだろうし. コードを精査して不信や対立, ぎこちなさをを洗いだす. refactoring でそれを正す. コードにおける dis-communication の解消は そんな形をとるのだろう. コードの外でも話をつける必要はあるだろうけど...ちょっと胃が痛い...

仕事の話は味気なくなりがちだなあ. ヒトはもっと趣のある communication の様式を持っているはず. たとえば花言葉. このくらいの情緒が欲しい. コード言葉があっていい.

美しい同僚が職場を去るという. あなたは密かな恋心を抱いていた. この溢れる想いを伝えたい. 彼女のブランチをチェックアウトしたあなたは最後のコミットをする.

Index: ChangeLog
===================================================================
--- ChangeLog  (revision 1630)
+++ ChangeLog  (revision 1631)
@@ -1,3 +1,40 @@
+2008-02-07  omo <omo at dodgson.com>
+
+	* my last fix for you
+
Index: lib/read_record.c
===================================================================
--- lib/read_record.c  (revision 1630)
+++ lib/read_record.c  (revision 1631)
@@ -992,6 +992,7 @@
     res = read_from_file(f, &ctx->msg);
+   } else {
+     res = NULL != gets(&ctx->msg);
   }
   return res;
 }

翌日.

Index: ChangeLog
===================================================================
--- ChangeLog  (revision 1631)
+++ ChangeLog  (revision 1632)
@@ -1,3 +1,40 @@
+2008-02-08  alice <alice at dodgson.com>
+
+	* no overflowed message is welcome (including yours)
+
Index: lib/read_record.c
===================================================================
--- lib/read_record.c  (revision 1631)
+++ lib/read_record.c  (revision 1632)
@@ -992,6 +992,7 @@
   } else {
-     res = NULL != gets(&ctx->msg);
+     res = NULL != fgets(&ctx->msg, sizeof(message_t), stdin);
   }
   return res;
 }