自分で書いているプログラムを理解しているか？ 株式会社ピーデー 川俣 晶 2003/02/15

---

Webサービス・インターフェイスを付けよう

　日本XMLユーザーグループのメーリングリスト・サーバで、過去ログをWebサービスで取得可能とする実験インターフェイスを付けることになった。いくつかのテスト的なコードを記述して、配信ソフトのりすと亭内部の情報を、Webサービス経由でアクセスできるようにすることが可能であることは検証済みだったので、ちょっとしたコードを追加すればできると思って取り組んでみた。

　余談だが、Visual Studio .NETで作成するWebサービスは、IIS経由で提供する形態になる。それに対して、りすと亭は、Windowsのサービスとしてバックグラウンドで実行されるプログラムとして実装している。簡単にWindowsのサービスにWebサービス・インターフェイスを付けることはできそうにない。また、りすと亭の簡易httpd機能と、httpによるWebサービスで使うポート番号が重なってしまうと、同時に使うことができなくなる。

　この問題にどう対処すればよいか最初は分からなかったのだが、長い時間悩んでいるうちに解決法が見えた。Webサービスは制約が多いのだが、リモーティング機能はそれほど制約がきつくない。サービスの中に、リモーティング機能で外部からのアクセスを受け付け可能にするのは容易である。そこで、りすと亭自身は、独自のリモーティング・インターフェイスで機能を公開し、それに中継を行うWebサービスのインターフェイスを別途公開すればよい、ということになった。これで、りすと亭内部の情報をWebサービス・インターフェイスで提供できるし、Webサービス・インターフェイスを提供するホストは、りすと亭サービスと異なるホストで実行しても問題ないことになり、ポート番号の衝突は解決できた。

　話を本筋に戻そう。Webサービス経由のインターフェイスを付けるコードを書き始めるとき、あることに気付いた。

　「そうだ、りすと亭は非公開のメーリング・リストも設定できるので、無条件で情報を返すとまずいな。ユーザーIDとパスワードも引数に加えて認証させよう。まあ、単純に引数に渡すとパスワードが暗号化されずに送信されてしまうが、現時点では実験だから、それでよしとしよう。どうせ、実際に実験で使われるメーリング・リストは認証なしで過去ログを提供しているものばかりだろうから、パスワードを指定する必要はないし。これで大きな障害はクリアされたぞ」

　だが、それは間違いだった。本当に大きな障害はクリアされていなかったのである。

見通しの悪い汚いソースを直す

　りすと亭は、簡易httpd機能でWebブラウザからのアクセスを受け付ける。提供される個々のページには、セキュリティ・クラスというものが設定されていて、そのページへのアクセスを許可する条件を指定する役割を持っている。条件は管理者の設定によってカスタマイズ可能であり、設定によって動作が変わる。Webサービス経由でアクセスする場合でも、このセキュリティ・クラスを反映したものにしたいと思ったわけである。

　しかし、ソースを見てがくぜんとした。セキュリティ・クラスを判定して、管理者の設定を調べ、結果のhttpメッセージを作成するところまでが、すべて1個の巨大メソッドに記述されていたのである。もちろん、そんな悪夢のような巨大メソッドを最初から作ろうと思っていたわけではない。機能を追加しているうちに、いつの間にか大きくなってしまったのである。

　このような巨大なメソッドがこれまで放置されてきたのは、単純に、中身を変更する必要に迫られていなかったことと、動いているものを書き換えるのは怖いという心理による。しかし、過去ログを閲覧するセキュリティ・クラスの判定ロジックだけをコピーして、別のメソッドに埋め込むのは気が進まなかった。同じ機能がソース・コード内に重複して存在すると修正時に漏れが起こりやすく、特にセキュリティ判定のような重要な機能で修正漏れが起こる事態は避けたいのである。そこで、この巨大メソッドを分割してきれいに分かりやすく書き直すしかない、と筆者は決意した。

　ソースを書き直す方法というのは、個々人の我流を含めていろいろな方法があるだろう。筆者は、最近はやりのリファクタリングという方法を使ってみた。リファクタリングを知らない人は、ソースをきれいに書き直す1つの方法というぐらいの理解で、このオピニオンを読むには問題ない。念のために付記しておくと、リファクタリングとは、

『リファクタリング プログラミングの体質改善テクニック』
(Ｍ・ファウラー 著、児玉 公信＋友野 晶夫＋平澤 章＋梅澤 真史 訳 ピアソン・エデュケーション刊)

という本に書かれたルールに従って、ソース・コードを書き換える行為だと思えばよい（ただし、この本はJavaが前提なので、C#などでは少し書き方が変わる）。もし、詳しく知りたい人は、この本を読めばよいだろう。

目的は達成されたが……

　さて、実際にソース・コードを書き換えてみた。

　判定ロジックを独立したメソッドに切り出してみると、そのメソッドは別のクラスの情報ばかり利用していることに気付いた。そのメソッドは、そのクラスに移動させた。繰り返される“else if”はポリモーフィズムによって条件記述を置き換えた。コンストラクタをファクトリ・メソッドに置き換えることも行った（これらはリファクタリングのカタログに含まれる基本的な作業である）。

　その結果明らかになったことは、筆者の最初の想定を少々裏切るものであった。よく見れば、判定ロジックを独立したメソッドに切り出した時点で、すでに目的は達成したのも同然だった。要するに、判定ロジックを複数の個所から共通に利用したい、ということが本来の目的だったわけである。その段階で作業を終えてもよかったはずだが、ソースをきれいにすることに頭がいっていた筆者はさらにその先まで作業してしまったわけである。

　もう1つ分かったことがある。実は最も厄介な問題は判定ロジックではなく、httpの返送メッセージを組み立てる情報をいかに受け渡すかということにあった。これにはコード番号やヘッダに付加する内容、人間が読むためのメッセージなど複数の情報が含まれていて、これを扱う方法をうまく工夫する必要があったのである。そこが最も工夫を要するとは、ソースをきれいにすることに取り組む前には全く予測をしていなかった。

　これらの経験から感じたこと、それは、プログラマが自分で書いているプログラムを理解していると思い込むのは危ない、ということである。自分で書いたコードであっても、いざソースをきれいにしてみると、思いもよらない構造が現れてきたりする。だからこそ、プログラミングは神秘の秘境であり面白い、とは思わないだろうか？

　しかし、こういう経験をだれもが体験しているわけではないようだ。最初からプログラムの構造が厳密に決められ、それに沿ったコーディングしかしないとすれば、隠された真の構造は浮かび上がってこないかもしれない。それでも、きちんと必要な性能を発揮して動作すればよいという考え方もあるだろう。だが、プログラマたるもの、ソースをより簡潔に分かりやすくする余地があるなら、それに挑戦する価値があるのではないだろうか？ 簡潔で分かりやすいソースは、単なる自己満足ではない。後の手直しやメンテナンスのときに、とてもありがたいものである。

---

川俣 晶（かわまた あきら）
　株式会社ピーデー代表取締役、日本XMLユーザー・グループ代表、日本規格協会 次世代コンテンツの標準化に関する調査研究委員会 委員、日本規格協会XML関連標準化調査研究委員会 委員。1964年東京生まれ。東京農工大化学工学科卒。学生時代はENIXと契約して、ドラゴンクエスト2のMSXへの移植などの仕事を行う。卒業後はマイクロソフト株式会社に入社、Microsoft Windows 2.1〜3.0の日本語化に従事。退職後に株式会社ピーデーの代表取締役に就任し、ソフトウェア開発業を始めるとともに、パソコン雑誌などに技術解説などを執筆。Windows NT、Linux、FreeBSD、Java、XML、C#などの先進性をいち早く見抜き、率先して取り組んできている。代表的な著書は『パソコンにおける日本語処理/文字コードハンドブック』(技術評論社)。最近の代表作ソフトは、携帯用ゲーム機WonderSwanの一般向け開発キットであるWonderWitch用のプログラム言語『ワンべぇ』(小型BASICインタプリタ)。

「Insider.NET - Opinion」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）