共通化の罠
このところ出張や会合などが非常に多く、なかなか書いている時間が取れなかったのですが、ネタはたくさん溜まりましたので、徐々に追記していきます。
ある工場のシステムの開発の一部（伝送関連）を私の会社で担当しているのですが、先日工場にて実機と接続して疎通確認を行いました。古いシステムのリプレースが目的の開発なのですが、仕様書は20年近く前のもので、途中細かい改修が行われていたり、そもそもあまり厳密な記載が無いなど、結局は実際に動いているものを見て探るしかないものなのです。資料は参考にはなりますが、あまり頼れない場合が多いものです。
伝送関連の開発では、まずはプロトコルの把握が大切です。最近のようにイーサーネットでTCP/IPなどを使うのであればアプリケーションレベルのプロトコルを把握すればほぼ問題ない場合が多いのですが、古いシステムですとまだまだRS232Cなどシリアル通信が多く、同期の仕組みなどが非常に多様で、まずは伝送手順の確認、それから伝送内容の確認が必要になります。
一番確実なのは、実際に動いている状態での、トレースデータが得られるとかなり開発が確実になります。シリアル通信ですと、コミュニケーションアナライザを使って通信状態を確認します。イーサネットであればパケットキャプチャがポイントになります。さらに古いシステムのソースコードを確認できれば確実になります。
トレースデータの採取とともに大切なのが、テストプログラムを作成して実際に疎通を確認することです。仕様書やトレースデータを基にしてそれらしい通信を行うテストプログラムを作成し、想定が正しいかどうかを確認します。シリアル通信ですとループバックテストが通信プロトコルに存在する場合が多く、最低限ループバックテスト、できればそれ以外の通信も行ってみます。イーサネットであれば単純にコネクションが確立できるか、さらにそれらしいデータを送受信してみると理解が深まります。
テストプログラムの準備は、実は意外とノウハウが必要で、ポイントとしては疎通確認時に如何様にでも修正が容易に行えるようにしておくことが大切です。疎通確認は短い時間で多くの確認をする必要がある場合が多く、テストしてみて仕様の思い違いに気がつき、即座に修正して正常に疎通できるまで確認する必要があります。プログラム自体をシンプルに修正しやすくしておくことが重要です。
ここでよく陥るパターンが、通信関連のプログラムは大抵似たようなものが多く、共通化を考えすぎてしまうことです。確かに共通化は開発効率の面でも、品質の面でも非常に効果があります。しかし、テストプログラムは上記のように即座に如何様にでも変更できることが最重要項目です。共通化しすぎると、変更の影響範囲が広くなってしまい、実は意外と手間がかかることが多いのです。
共通化を全く行わない方が良いということではなく、共通化のレベルをきちんとわきまえておくことが重要です。一般的にアプリケーションレベルのプロトコル処理は共通化は難しいと考えた方が良いでしょう。最近のシステムは物理層まで含めて汎用の構成で組む場合が多いのですが、古いシステムはかなりの割合で通信全体を専用に作りこんでいるものがあり、同じような通信でも実は細かい方言が多く、共通化は意外と困難なのです。
同様に、汎用化もテストプログラムでは裏目に出ることが多いものです。ソースコードにデータをハードコーディングするのはもってのほか、と、教えられるものですが、テストプログラムではハードコーディングしてある方がピンポイントで修正して試すのに向いているのです。汎用化を考慮するとパラメータ化したり、データファイルから読み込んで送信する、などという感じの作りになっていきますが、それによって想定外のデータを送らねばならなくなってしまった場合に手間取るのです。
テストプログラムで十分動きを確認し、仕様がほぼ把握できてから共通化、汎用化を考えた方が安全です。が、その場合もやりすぎてはいけません。実際リリース後に問題が発覚した場合ピンポイントでしか入れ替えられないことは多く、汎用化・共通化しすぎていると逆に強引な修正をしなければならなくなってしまうことが良くあります。
最近ではWEBシステムの開発でもフレームワークを使って迅速に高品質のシステムを作る方法が主流ですが、想定外の修正依頼が来ると非常に手間がかかるケースが良くあります。共通化・汎用化が悪いということではなく、実際にどのような修正・リリースを要求されるかを考え、「作りの問題で修正は困難です」とお客さんに言わねばならない状況にならないようにしておくのも賢いプログラマーの選択ではないでしょうか。何事においてもやりすぎは良くないものです。
2007.6.15
from 2007/1/13