日々の破片

_ フリップフラップ

実は非常にやっかいなプログラムを持っている。とあるコンポーネント（OCX）で、VB4の時代から利用されている。時代背景から当然のようにMFC4.0上に構築されている。MFCDUALを利用してデュアルインターフェイスを実装しているのは我ながら慧眼だったが、それはまた別の話だ。

このOCXの問題はフリップフラップ（oをアと読むのは良いよね？）だ。

Aというプログラムに貼り付けるとある特定のタイミングでハングする。

OK。修正しよう。

Aは動くようになった。

1年が過ぎる。Bというプログラムに貼り付けるとある特定のタイミングでハングする。

OK。修正しよう。

Bは動くようになった。

1年が過ぎる。A'というプログラムに貼り付けるとある特定のタイミングでハングする。

OK……これはいつか見た状態だ。Aの問題の時の修正と同一症状みたいだが……でも今、Aは元気に動いている。なぜ、同じような構造のA'が確かにハングするんだ？ 修正したはずだし……

そこで気付く。B用の修正が最初のA用の修正を打ち消してしまったことをだ。巧妙に別の方法でオリジナルの状態に戻してしまっていたということだ。

ではなぜAは問題が起きないのだろうか？

2年という歳月がインストール対象のマシンを変えたことが原因だ。

オリジナルAがインストールされたマシンはBの修正の影響を受けずに2年前の状態で稼動している。Bの修正後にAがインストールされたマシンはその時点のマシンだから影響を受けていない。

つまり、AとBはこのOCXを全く逆の使い方をしているために、本来両立しない仕様を要求していたのだ。しかし、時代が変わりCPUやメモリーやHDDはムーアの法則にしたがったりしながら進歩して、元の構造のまずさを打ち消してしまったのだ。

でも、時代は新たな機能を要求し、Aをさらに重くでかく複雑にしたA'を生み出した。A'には最新のマシンも能力不足で元の仕様の逆をつく問題が顕現してしまったということだ。

そこでA'のために、B用の修正を元に戻す。

さらに1年がたつ。予期していたかのようにB'が登場する。

今度は、A’打消しを行う。でも大丈夫。

また1年が過ぎる。たまたまA''は遅れているようだ。

さらに1年が過ぎる。やっとA''が出てきた。

そこでB'打消しを行う。手馴れたものだ。

そしてまた1年が過ぎる……

選択肢を考えてみよう。

1. フリップフラップを続ける

2. Aを根本的に変えてBと同様にさせる

3. Bを根本的に変えてAと同様にさせる

4. コンポーネントを根本的に変えてAとBを両立可能にさせる

2,3,4は既存のコードベースをゼロに戻す必要がある。アーキテクチャの問題だからだ。どこで入力しどこで出力し、どのようにプロセス間で通信し、どのようにネットワークを利用するか。

1.は永遠に続く（かも知れない）。しかし安定している。

_ レイヤとティア

tear of fear。

ちがうもんじゃん。