GUIプログラムは複雑になりがち・・・

今日はあるシステムの改善に関してずっとミーティングを行っていました。プログラムと言っても様々なタイプがありますが、私が経験したもの中では、断然GUIプログラムが複雑です。

GUIプログラムは、GUI構築ツールを使い、自動生成されるソースの雛形をベースに処理を記述していきますが、単に結果をファイルやプリンターに出力するくらいならまだしも、同時に通信トランザクションなどを扱うことになるとひどいソースになりやすいのです。イベント駆動型のGUIの記述と、通信などのトランザクション処理を両立させるのが非常に面倒なのが原因です。

GUIのプログラムでは、ボタンが押されたなどのイベントに対して、コールバック関数が呼ばれ、そこで必要な処理を行ってリターンするとまたGUIが使える状態になります。コールバック関数ないで時間のかかる処理を行ってしまうと、その間、GUIが固まってしまうので、そのような場合は別スレッドで行うように作ることが多くなります。ところが、別スレッドでもGUIのパーツにアクセスする必要があることがあるなどして、ソースがひどい状態になるばかりか、デッドロックの心配も出てきます。さらに、通信制御なども行うとなるとスレッドが増え、複雑怪奇なプログラムができあがるのです。

GUI構築ツールが完全にソースの自動管理をしてくれればいいのですが、どのツールも大抵は中途半端で、あとでGUIパーツを増やしたり変更したりするとソースがごちゃごちゃになり、仕様変更が重なるたびに管理不能な状態に陥ります。

こうなってしまうと、もはや仕様書などで理解できるレベルではなくなり、作った本人が、頭の中に様々な情報が展開されているとき以外は誰も全体を把握できないソースになります。

このようなソースでは、十分なテストを行っても、様々な組み合わせやタイミングにより、ある日突然予想もできないような障害が発生したりするものです。ところが、そもそも解析すらできない状態になることが多く、お客さんはカンカン、現場は火の海、というプロジェクトを何度も見てきました。

WEBシステムはGUIと処理を別にできるため、その複雑さを回避できると思いきや、結局リッチなUIを、との要求から、複雑なスクリプトを駆使したり、Flashなどの環境を使うようになり、いつになってもGUIのシステムはメンテナンスが楽にならないという気がしています。

基本的には、GUIプログラムと、他に並列で行うべき処理を1つのプログラムにするのは避けるべきで、別プログラムをうまく連携させるような構成が、あとで融通が利くことが多いのですが、大抵は勢いで1プログラムを肥大化させてしまい、あとで困ったことになることが多いものです。常に動き続けなければならないサーバ的なプログラムとGUIを組み合わせるのはもっとも怖いです。

そんなわけで、私自身はGUIプログラムは昔CADシステムを作っていた頃に嫌というほど経験し、その後の受託開発などでも火の海を見てきたので、あまり気分が乗らず、ノウハウさえあればシンプルで綺麗なソースが書けるネットワークプログラムが好きになっていったのですが、ネットワーク関連は触れたくないというプログラマーも多く、人それぞれ好みがあるということでしょう。

「なんでこんな簡単な処理の変更で、そんなにソースの修正に時間がかかるんだ！」と雷が落ちるときは、大抵このような複雑怪奇なソースになっていることが多いものです。開発した側も本当はそんなソースにしたくないものですが、短納期で何とかしろといわれ、考えながら作っていたらそんなことになっていたり、度重なる仕様変更でつじつま合わせだらけになっていたりするもので、プログラマーが一方的に悪いということではないと思うのですよね。雷を落としても、なおさら付け焼き刃の対策をしてしまうでしょうから、依頼する側も良く状況を把握しながら進めさせることがポイントだと思います。