dotkuwaの日記： バグを解消する為には「非同期」が見えないといけない。なぜなら、 9
バグを解消する為には「非同期」が見えないといけないです。
なぜなら、
・非同期は世界にあまねく存在していて、
・非同期は早い世界ではバグそのもの
だからです。そういう種類のバグを解決するとは、
・非同期を同期にする、それに近づける
ことで、そもそものバグの原因で有る、非同期が見えないと
話になりません。
先日、電車から降り、他の人と階段に向かいましたが、階段の
向こうから3人ばかり来て、そのうちの1人が自分の真ん前を
急いで抜けて行きました。
他の2人も行くと思い、足を止めましたが、次の人はジッパー
方式を望んだ様で、少しの逡巡の後、自分が先に行きました。
こうしても何の問題もなかったのは、
・自動車より遅く、自動車より圧倒的な加速減速性能をもつ
人間同士だったからです。もっと早く、もっとアジャイルで無い
自動車だったら（自転車でも）事故って（バグって）いたかも
知れません。
特にプログラミングでは、バグといえば
・非同期をそのままにして、規約とかで少しでも同期にする
という手間を省いた（というより、非同期が見えずに、
バグとして露見した）
式のものが大部分です。
・a+b⇨c
を間違える人は少なく、しかもテストは容易です。
（なので、いくら基礎の基礎とは言ってもここでいきっても
大差有りません。）
しかし、
・aに必要な値が入る期間、bに必要な値が入る期間
より前か、より後かに+を実行してしまうバグ
はよく間違え、テストも困難です。
（aに前月のデータが入っている期間とか、来月のデータが
入っている期間とか有り、必要な当月のデータが入っている
期間は限られている、との想定です。）
さらに、これを（非同期を）バグだと見えていない人も
多数居ると思います。
ぶつかる間際に避ければ良いというのは、人間の論理で有って
プログラミングではそうも行きません。
案外 (スコア:1)
案外、フロントエンドなんかでモデルとかビューとかのおさまりが
どうやっても悪いのは、
・はやりすたり、好みなど、万人がゴールを動かすし、
それが良いとされる世界で、
・非同期がよい（実際は毒で、本当に条件の良い時のみ薬）と
いう勘違いが横行している
ためだとか！！
何らかの同期を取るのが必要なのは、当たり前では！！
非同期に関しての非同い話 (スコア:1)
前にVB6(VB4から移行)で出来た、多数の入力画面（基盤はora）の
システムで、
・.frmや.basで出来た各入力画面を全部で1つの.exeで無く、
1画面事に.exeにしろ
という指示を受けました。
その画面は、
・各部品（テキストボックスなど）のtag属性に連番を振り、
全ての部品で「Enterを押下したら次の連番の部品に
フォーカスを移す」
というハックがされている。（入力は全て半角文字）
・最後の連番として、次画面ボタンが有る。
ものでした。
実際にそういう種類の入力画面を触った方はお分かりと
思いますが、
・次画面ボタンの所で、ヒューマンエラーの「スリップ」に
相当するEnterキー複数回押し
（タン タン ターンという感じ）が起きてしまう。
・確かに「タン タン ターン」と打つのは気持ちよく、
テスト中の自分でも、それを抑える事は出来ない。
抑えようとすると手がつる。
という特徴が有ります。
ここで問題となったのは、
・全部で1つの.exeの時は、次画面ボタンを
「タン タン ターン」と打っても、全部同期処理として
Enterイベントが消費されましたが、
・1画面ごとの.exeとした場合、
●1：初めの「タン」で次画面処理が実行され、フォーカスが
次画面の.exeファイルに移る。ー（1）
●2：他の「タン ターン」によるイベントが消費されず
残る。
●3：次画面で前画面ボタンを押した際に、元の画面に戻るが
消費されず、かと言って再実行の手立てもないイベントの
ため、元の画面が固まる。
●4：再実行の何らかの手立てを考えたが、それを参照する
何の手掛かりも無いため全滅。
という事でした。これは本当に本当に致命的でした。
結局、上記（1）の所で、次画面処理の実行後、ディレイ付きの
ループで、単にイベントを10回消費するだけのロジックを、
元画面のEnterイベント処理に置き、
（つまり、次画面表示と、イベント消費処理が並行処理されている）
事なきを得ました。
（11回もタンをやる人間の事は無視します。）
こんなバグは非同期が見えていないと取れないと思います。そして、
非同期は全て良いなどとは、とても言えないと思います。
むしろ入力画面分野などでは、全て駆逐すべき巨人の位置付けかも
知れません。
不変性 (スコア:0)
最近の流行では一つの変数には一つの値しか入れない。
例でいうなら車の走行レーンや待避方向が決まっているようなものかな？
Re:不変性 (スコア:1)
「一つの値しか入れない」を実際にやってみると判りますが、
その一つの値しか入れない変数に必要な値を得るのに、やはり非同期的な
タイミングが必要です。
一つの値しか入れないことにしさえすれば、値は簡単に手に入るのでしょうか？
そんな事はないと思います。
実際にやったことがあるのでしょうか？
Re: (スコア:0)
有効期間中は値が確定しているし、それで非同期なタイミングのせいで誤動作起こすなら設計がクソ。
確定前にアクセスされたなら未定義の値ということでエラーや例外発生させるべきだよ。
正確には確定前の値にアクセスしようとしたならだけど。
もちろん必要な値を全て取得設定出来ていてもステータスは未定義状態のままな可能性もある。
でも不具合起こすよりマシでしょ。
Re:不変性 (スコア:1)
＞有効期間中は値が確定しているし、
そうなる、ユニバーサルな（大きな変更なくどんな呼ばれる側にも使える）
基盤ソフトが有ればいいですがね。
そんなのは無いから、そこもプログラミングをしなければならず、
そこの方が呼ばれる側の関数よりテストが大変だといっているのです。
入力リッチな場合と入力プアな場合 (スコア:1)
第一原理のみを使ったシミュレーションなんかの計算の
場合は入力リッチと言え、計算すべき値が次から次から
やってくると思います。
その場合に単一代入というのは役に立つのかも知れません。
しかし、普通の生活で役に立つプログラムでは入力プアな
場合ばかりです。計算をするのに必要な値を得るのが
もっとも大変な作業になる様な場合です。
その場合には、
・単一代入だろうと、複数回代入可能だろうと
大差なく、
また、
・複数回代入可能でnull有り
とする事で、
・計算をするのに必要な値がまだそろっていない
事を表現できます。
学術の分野では入力リッチで実績のあるやり方を、
入力プアな場合に拡張しようとするのは、それだけで
一つの業績になるのかも知れませんが、
商用の分野では、実績の全く無いやり方を無批判に
「より良いやり方だ」とするのは、業務妨害であり、
詐欺です。
Re: (スコア:0)
以前に言いましたけど理論や理想と実用は分けて考えてくれませんかね。
本文は理論や理想を言ってるからそれに対してコメントしてるのにいきなり実用分野ではおかしいと言われても困るんですよ。
実用分野で非同期の影響を排除したいなら完全シングルスレッドシングルアクセスにしてロックもがちがちにかければ良い。
今時のコンピュータなら待ち時間なんて微々たるものですよ。性能はでないでしょうけど。
特定の分野(それも充分に広い)で有効な解決方法が別の特定分野で効果が低いからといって
その手法を間違いとすることも業務妨害であり詐欺ではありませんか？
Re:入力リッチな場合と入力プアな場合 (スコア:1)
最近の流行では
というのがこまるんですは！
効果の高い分野を指定せず、良さげに言われるのは、本当に本当に詐欺なんですよ。
全称で言うのはやめて欲しいです。手法を間違いとはひとっ言も言っていないです。
説明の仕方が詐欺だと言っているのです。