dotkuwaの日記： 下位は下位

自動テストは確かに確固としたものだと思う。
しかし、往々にして確固としたものは、それなりの
代償が必要です。
　
この場合、その代償は、
・自動テストに対応する自然言語が、（底辺と言って
　良い程の）下位概念となってしまう。
事です。
　
ひるがえって、（普通に言う）テストは、大抵、
ドメインの言葉で書いてあります。ドメインの
要求に答える為なので、当然です。
これは、より上位概念です。プログラムから見ると
最上位と言ってもいい位、上位です。
　
さて、
★より上位概念を一意に下位概念に分解する
　ことは可能でしょうか？
　否、一般には不可能です。
★誰が上位概念を下位概念に分解するのでしょうか？
　それも正しく！
　将軍様でしょうか一休さんでしょうか？蜷川様で
　しょうか？
★えいや！で分解した下位概念に対応した自動テストは
　正しいでしょうか。
★そもそも、一般に上位概念を分解した下位概念が
　実行可能だと保証されているのでしょうか？
　否、一般には不可能です。
＃要するに、プログラミング言語にはスケールモデルが
＃（完全に）無いのでは？
　
自動テストはトリビアな実例以外、実行可能なので
しょうか？
＃呼び戻さないで！

設計者とは？

[dotkuwa (9387)]

よく、プログラム開発と対比される建築の分野では、
★材料等、全部見えます。土の中もお金をかければ
　見えます。
★竹ひごで作ったモデルと高層ビルはかなり良く
　似ています。
というのは事実だと思います。
もちろん、お金を掛けられず見えずにやる事も有るの
かも知れませんが、後述するプログラム開発に比べ
ると見えやすいと思います。
　
プログラム開発は、
★最後に出来た出来栄え以外、見ようとしても中々
　見えません。離れたところにあるIF文等が連携して
　全く思いもつかない制約を実現している場合も
　沢山あります。
★プログラムのどの一部も全体を代表してはいません。
　ですのでWBSなどで、工程を洗い出しても、
　その題名だけで全体を表しません。かなりの段数ほど
　副工程が埋もれていて、それら一つ一つは主工程と
　比べてそん色ない困難さで、主工程と副工程はそれ程、
　関連性が無いのが普通です。
　（ですから、WBSの線は収拾困難になるのが通例です。）
だと思います。
　
その状況下で、設計者（上位概念から（正しい）下位概念を
導き出す）とはどの様な資質を持つ人でしょうか？
それは、
★見えない、（重力定数の様な）均一で大学で学ばないと
　分からない様な全体を代表した法則が無い
　事に通じている。
人だと思います。
それは、
★（建築家と作業員の様に分かれている訳では無く）
　単に経験を積んだプログラマー
なだけだと思います。
　
よく、職業女性に関する略語に対し、どう言い換えても
静的意味を持ってしまう事が有りますが、
（超上流で無い）プログラミングに関するどんな職業（職種）
も（いくら設計だ設計だ言っても）プログラミング的意味を
持ってしまうのが事実です。
「アーキテクト」など、今日では「フルスタックのデジどか」
以外の何の意味も持ちません。
　
それの意味する所、すなわち、
★ソフトウェア開発では、何処まで行っても
　プログラマーだけ
という根底の構造が有ると想定されます。
　
何が言いたいかというと、
●テストをまず書いてからプログラムを組みたいのなら、
　上記の様な技術者を常に張り付けておく必要が有る。
　（或いは当人が既にそういう技術者である。）
　そうで無いなら、すぐにテストなど書けなくなる。
という事です。
新規開発時はまだしもテストが書けても、保守になるとダメに
なるという事を聞きますが、これが原因だと思います。

Re:

[Anonymous Coward]

ソフトウェアに対する「見える」「見えない」って概念は良い観点だと思うよ。
残念ながらあんた自身は見えてない側に思えてならないけど。

Re:設計者とは？

[dotkuwa (9387)]

実は、建築分野とプログラミング分野の対比をもっと際立たせようとしたのですが、
そうしようとして、
・建築分野は設計者と作業員が分かれていて、作業員は単純だが、
　プログラミング分野では分かれていず、プログラミングは設計に近い
と書こうとしたら、
・建築分野もそれほど作業員は単純では無い！
とお叱りを受けるのでは無いかと斟酌し、
　
もっと浅い、
・「見える」「見えない」
としか言えなかった
というのが真相でした。

Re:

[Anonymous Coward]

★最後に出来た出来栄え以外、見ようとしても中々
　見えません。離れたところにあるIF文等が連携して
　全く思いもつかない制約を実現している場合も
　沢山あります。

プログラムが悪い。
入力と出力以外に副作用はあるべきでなく、一つの制約は必ずそれを定義するメソッドを用意すべき。その内部で部分制約となるのは構わない。

★プログラムのどの一部も全体を代表してはいません。
　ですのでWBSなどで、工程を洗い出しても、
　その題名だけで全体を表しません。かなりの段数ほど
　副工程が埋もれていて、それら一つ一つは主工程と
　比べてそん色ない困難さで、主工程と副工程はそれ程、
　関連性が無いのが普通です。

プログラムが悪い。
すべての機能はそれらを代表する部分から必ず呼び出せるようにするべき。でなければモックテストなんかもできない。

Re:設計者とは？

[dotkuwa (9387)]

1つ目ですが、
MSAccessとかでプログラムを書く時、イベントドリブンなので、
タイミング毎に、プログラムを書ける場所が分かれています。

「離れたところにあるIF文等が連携して」になってしまう原因は、
・あるIF文はあるタイミングで観測される値セットのみで判定可能、
　別のIF文は別のタイミングでのみ可能。
である為なのが大部分なので、

イベントドリブンの際にはどうしようも無いです。今後Lambda記法
とかで、イベントドリブン的な書き方を、ユーザー定義で出来る
様になったら、この問題はさらに深刻化すると思います。

2つ目ですが、
「すべての機能はそれらを代表する部分から必ず呼び出せるようにするべき。」
は別に、
「プログラムのどの一部も全体を代表してはいません。」
というのと対立していないと思います。

自分が想定したのは、
・宇宙のどこを選んでも均一だから、どの一部でも全体を代表しているが、
　プログラムは、絶対に均一でない（同じものは1つあれば十分で、
　違う所に有るものは、必ず違わなければならない。）
というだけです。

モックテストの要件も全くその通りだと思います。今回、実際に出来ている
自動テストを非難する意図は全く無く、ただ、
・自動テストが実際に出来る為には、かなりの前準備が必要
・ユーザーの要件とプログラムが（粒度的に完全に）一致している様な
　場合を除き（学校の試験としてのプログラミングなら該当？）、
　その「前準備」とは非常に困難なのでは無いか？
というだけです。

「イベントドリブン症候群」

[dotkuwa (9387)]

関係が薄い話しですが、

長く使っている既存プログラムの保守性が悪くなる一因が、
・イベントドリブンとなんか、全く思っていないのにそうなる。
・それゆえロジックが散らばる。
です。

現行プログラムは、
・（怖いから）現行の制御の流れはいじらない
・必然的に、あるタイミングで書ける場所が散らばる
・（怖いから、あるいは副プログラムの段数の制限から）
　必要な箇所を切り出すのも不可。
為です。

結果、イベントドリブン症候群となってしまうのでした。

Re:

[Anonymous Coward]

イベントドリブンなプログラムはイベント部分に各種処理(ビジネスロジック)を書きたくなりますが、それは間違いなのです。
なぜなら再利用が難しくなるから。これには自動テストなども含まれます。
イベント部分はクラスデータの遷移(できればこれも分離)とビジネスロジックの呼び出しにとどめることで、
複合の制約を解消する(正確には別の場所に移す)ことができます。

・自動テストが実際に出来る為には、かなりの前準備が必要
・ユーザーの要件とプログラムが（粒度的に完全に）一致している様な
　場合を除き（学校の試験としてのプログラミングなら該当？）、
　その「前準備」とは非

「初めにテスト」で無いなら

[dotkuwa (9387)]

まじでイベントドリブンでやり切るのは確かに「ある」と思いますが、
大変です。
保守していると「イベントドリブン症候群」になってしまうなら、
「見えない（ロジックが散らばる）」のは初めからあきらめて、
必要な限りのタイミングを全て定義してもいいのかも知れません。
　
しかし、それは初心者むけでは無いと思いますし、単なるWeb読み書き
システム程度でも不要だと思います。
　
また、「前準備」を思いつくのすらも、初心者には無理だと思います。
　
プログラミングは、
次元がやたら多くて、正しいやり方が非常に少なくて、
考えても出来ない事が非常に多いです。
　
だから、少なくとも初心者には、テストや「前準備」をやる前の
トレーニングとして（実際に動いているものの）コピペや
写経は有効だという事だと思います。
★正しい事例が解る。
★（プログラミング絡みで）「正しいとは何か」が解る。
からです。
　
上位概念から下位概念を正しく分割出来るのが、経験を積んだ
プログラマーだけだという理由も、そこに有ります。
思弁的に下位概念を捻り出しても、正しいにほぼ100%ぶつから
無いからです。
（プログラミングの十分な経験が有り）「正しいとは何か」の例
を知っていればまだしもですのに。
　
ひるがえって、
☆仕様から、まずテストを作れ
とか
☆国語数学など（の上位概念）と、プログラミング（下位概念）
　を絡めて考える
というのは、逆に高等な勉強です。それを強いるのは虐待です。
（やるのなら）先生が残りの時間をかけて自分でやるべき事です。

Re:「初めにテスト」で無いなら

[dotkuwa (9387)]

自分が新人の頃（30年前）でも似たような事が有りました。

プログラムをするのに精一杯だった頃に、
・プログラムより、日本語（自然言語）で書いた設計の方が
　重要で、それを書け。
と言うのです。
日本語（自然言語）で書いた設計書を残すというのは、その頃の
最新知見で、本当にやるのは最優秀の人で、自分は本当に
やらなくても大丈夫では有ったのですが、
・日本語（自然言語）は代名詞が弱く、日本語（自然言語）で
　書いた内容が、どの（プログラミング言語の）場所を指している
　のか、すぐに分からなくなる。
・宣言的に（処理方法ではなく対象の性質などを宣言する）書けば
　良いのですが、それを思いつくのは、プログラミングし終わり、
　きちんと動くようになった後で、
　そういう時期に報告すると、「何で初めにそれを思いつかないんだ」
　と非難されるだけ。
という有様でした。
　
でもまだ、その頃はその様な、プログラミングに加えて、概念の上下
移動も含む、自然言語の記述は「最新知見で困難だ」という認識は
皆さん持っており、すべて紙に手書きだった事も有り、
・出来たらいいな
程度で済んでいました。
　
しかしながら、「初めにテストを」という立場の人は、
・単にテストを書けば良い
とは言いますが、
・元となる情報（上位概念寄りの宣言的な規則）から、テスト
　（プログラム）が書ける程度の下位概念より（場所、タイミング等
　を加味した、細かい情報。）に上下移動する困難さ
について、完全に無視しています。
無視された困難さは、やれと言われた人間に無報酬でのしかかるのです。
　
いくら何でも「改良」が過ぎます。リスクの移転が度を越えていて、
不公正です。これを本当にやらせる（自分がやるのでは無く）のは
文字通りの「虐待」だと思います。