dotkuwaの日記： 個人が学術的被害に遭わない為には 20
さすがに公的な恥の殿堂など、そうそう出来るものでも無いと
思います。
そうしますと、個人が学術的被害に遭わない為のムーブが必要だ
と思います。
それは、
・御説が上手く行くのはどことどことどこでしょうか？
と聞き、言い淀むと、
・では可能な全ての場合で御説は上手く行くのでしょうか？
と聞き、言い淀むと、
・上手く行く範囲が定まっていない様な最先端の説には
とても関与出来ません。
と断る事です。
そうしたら、新説など教えてくれなくなるでは無いか？ と
思われるかも知れませんが、
手続き型プログラミングなど、非常に上手く行く範囲が狭い
にも関わらず、多くの人にとって必要だった範囲がジャスト
ミートだった為、爆発的に知れ渡りました。
本当に役に立つ事なら、自然と耳に入るはずです。
もちろんリデュース型の計算であるなら、関数型と言われる
やり方でも、上手く行くと思います。
たとえば、
・契約内容沢山を入力とし、料金を出力とする
様な計算なら、知る限り30年前（40年前と言っても嘘になら
無いと確信しますが）から、自動テストはしていました。
しかし、たとえば、画面入力の分野では、
・入力する度、情報が増える
・入力する人は、いままでの経緯を加味した入力画面の
動きを好む傾向に有り、さらに情報が増える
ので、それを無理矢理リデュース型計算にすると、
おかしくなったり、セキュリティー的に脆弱になったり
します。
御説（関数型）で上手く行かない範囲だと思います。
これは言語が何で有っても、単一代入で有っても無くても
通底した話だと思います。
よく、ネットワークアプリの階層構造（レイヤー1から4までとか）
もそういう議論では俎上に上がりますが、あれは今までの
経緯をany型として捨てないで置いてあり、決して
リデュース型の計算では有りません。
とどのつまり、自分も、
・御説が上手く行くのはどことどことどこでしょうか？
と初めに聞かなかったのが馬鹿だったのかも知れませんが、
過去の自分がその様な事が出来た様には思えません。
初めにテストをしろという言説も、上手く行く範囲を特定出来て
いない以上、「初めにテストをしろ」はテストをされていません。
なんという事でしょう！
（初めにテストをしろが、上手く行く範囲はこことこことここ
であると既に公表されているのでしたら、是非お知らせ下さい。
可能な全ての場合で初めにテストをしろが、上手く行くとは
到底思えないので。。。）
始めにテストをするためには (スコア:0)
テストケースを列挙 ≒ テストを設計しなければなりません。
テストをきっちり設計してからテスト対象本体の開発に臨め、が
テストファーストの本質です。
テストを設計することで、「上手くいく範囲」も浮き彫りになります。
「上手くいく範囲」はテストの設計が決める、とも言えますね。
なぜ責任範囲は有限ではなく無限である、と捉えているのでしょうか。
屏風から出てこない虎を捕まえることはできません。
Re:始めにテストをするためには (スコア:1)
既にライオンさんが出てきて、どういう設計でも構わず、初めにテストをしろ
と言ってきているので、責任範囲が無限である様な印象を受けました。
屏風から出てこない虎を捕まえることは出来ないと、自分も思いますが、
「計算をすると情報量が減る」種類の計算では、必ず屏風から既に虎は出た後に
なります。
「計算をすると情報量が減る」種類の計算では、全ての計算に必要な情報が、
既に入力値として有り、それらの情報のみから出力値が得られるからです。
「計算をすると情報量が増える」種類の計算が必要な分野にも、
「計算をすると情報量が減る」種類の計算を押し付けるのが、
テストファーストの実務的な実態だと思います。
（本質は確かに綺麗なテストファーストですが、日常のほとんどは汚いです。）
テストを設計すると言いながら、解法（プログラミングの手法）を制限してる
のもテストファーストの実務的な実態だと思います。
（本質は確かに綺麗なテストファーストですが、日常のほとんどは汚いです。）
「計算をすると情報量が増える」種類の計算が必要な分野では、
テストファーストのやり方でテストを設計しようとすると手が止まるのです。
『「上手くいく範囲」はテストの設計が決める』と言いながら、
その設計のやり方は強制してくるので、始末が悪いのです。
屏風から虎を出す効果的なやり方は、分野ごとに違うと思います。
それから得られる唯一の光明は、
・分野によっては、テストファースト自体を無視する事が正しい
そうしないとテストの設計も出来なくなる
とすべきだという事です。
Re: (スコア:0)
「計算をすると情報量が増える」ってのは、具体的にどういうことなんでしょうか。
そのまま取るなら情報処理にしくじってプログラムの分割統治もマトモにできぬまま
カオスを放置しているということになり、まったく褒められたものではありません。
百歩譲って実際に「計算をすると情報量が増える」としても、遅かれ早かれ
テストケースは列挙しなければならず、それを先送りにすることの本質は
テストを後回しにすることではなく、仕様が固まってないけど頭使いたくないから
コードを書き始めた、ということではないでしょうか。
だとしたらそれはプロトタイピングであり、プログラミングの前工程だとも言えます。
工程としてはそれもアリだし、この段階でテストをしても意味はなさそうです。
とはいえ仕様が確立してプログラムを清書する際には
カオスを収束させテストケースを確立させておくことに変わりはないので、
そこでテストファーストを適用したらよいのではと考えます。
Re:始めにテストをするためには (スコア:1)
画面に入力するとその分情報が増えるでは無いですか。常考。
その観点が抜けているから、頓珍漢な事を言っているのですよ。
a=f(x,y,z,s,t,u,v,w,,,)みたいな計算ばかりでは無いという事ですよ。
テストファーストだとかは、計算すると情報量が減る場合には有用で
しょうけれど、それは40年前からやっている事で、新規性が無いの
ですよ。
昔の人の業績を無視して新規性が有る様に言う所が背乗りだと
言うのですよ。
情報量が増える計算の実務を知らないから「頭を使いたくない」だけ
とか頓珍漢な事をいうのですよ。
ただ、確かに情報量が減る計算がリデュース型なら、増える計算はカオス型
なのかも知れませんね。うまい！ カオスの定義から言ってもそれで良いと
思います。
そのカオスに挑んだのが手続き型言語で有り、皆が欲しかったストライクゾーン
もそこなのでしょう。あなた良い事を言いますよね？！
Re: (スコア:0)
画面に入力するとその分情報が増えるでは無いですか。常考。
単体テストの段階で結合テストレベルの結果を求める愚に陥っていませんか。
あるいは単体テストをスキップして結合テストレベルの結果を得ようとしていませんか。
そうなってしまうのはプログラムも単体レベル・結合レベルでの分割統治ができておらず
すべてをモノリシックなモジュールで解決するような実装になっているからではないですか。
計算をすると情報量が増える = 画面に入力するとその分情報が増える、というのは
要素の追加・仕様の変更・ディシジョンテーブルの拡張・テストケースの追加、という話であり
テストファーストを採用するか否かをそれで決める、というのは主客転倒した話です。設計と検証を混同しています。
テストファーストであろうとなかろうと、追加されたテストケースには追従する必要があるのですから。
その意味で「新規性が無い
Re:始めにテストをするためには (スコア:1)
設計はします。テストケースも作ります。
ただ、テストファーストはゴメンです。
というだけです。
どうしてゴメンなのかは、自分の仕事の詳細にかかわりますので言えません。
> こちらの認識と合致しているのか、からしてわかりません。
これは仕方ないと、思います。
ただ、実行時チェックは、テストファーストとしてはダメだと言われたのは
事実で、その点からだけでも、自分はテストファーストとは、相いれません。
Re:始めにテストをするためには (スコア:1)
> 単体テストの段階で結合テストレベルの結果を求める愚に陥っていませんか。
何を根拠にその様な考えに至ったのでしょうか?
情報量が減らない計算であっても、愚に陥るかも知れませんが、
それは、どんな手法でも変わらない話だと思います。
Re: (スコア:0)
何を根拠にと問われたら、与えられた状況からそのように解釈したという回答になります。
とはいえ否定をされないということは、妥当な見立てであったと考えてよいのですかね。
そもそもなぜリデュース型の計算か否かで区別を行い、後者にはテストファーストが
有用でないとしているのか。ここからして違和感を感じていました。
・入力が増えるならテストケースもそれに応じて増やす
・更新対象が多岐に及ぶなら影響範囲すべてを精査する
ただこれだけのことであり、リデュース型の計算の場合と
本質的に一体何が違うというのか、主張に説得力が全く伴っていません。
これで仕様の妥
Re:始めにテストをするためには (スコア:1)
#4157527 の発言があなただとするなら、
そこが焦点です。
計算をすると情報が増える方向のものは、どう増えるかを考えた後でないとテスト方針すら
定まらず、「初めにテストを書け」と言われても困るし、そうしないと不正解だと言われても、
それに従うわけには行きません。
＞第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。
でも構わないのでしたら、議論は不要です。
なぜ議論になったのかと言うと、
＞第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。
では駄目だという主張が主流だったからに過ぎません。
あなたを糾弾したいのではないのです。
ソフトウェアに関するどんな分野でも無条件に、
＞第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。
では駄目だと主張していた人間の名誉を下げたいだけなのです。
どうか理解してください！！
Re: (スコア:0)
・間違った主張をしている他者の名誉を下げるために
・別の間違った主張を以ってそれを行う
ということを「理解」することなど、これまでもこれからもすることはありません。
唾棄すべき現況は把握しましたが、その行動原理に同情や共感は一切湧いてきません。
あちらの書き込みでも触れましたが、客観的な資料に当たることをなぜしないのか。
それをせずに、他説を批判する資格がどうして得られるというのか。
やってることは歴史修正主義者と何ら相違ないではないか。
Re: (スコア:0)
やたらと抽象的な表現を好む割に抽象的な表現を理解できないのだな。
Re:始めにテストをするためには (スコア:1)
あなたの抽象を語るに足る、何も提示されていません。
ですので、あなたの抽象については、ここでは議論できません。
Re:始めにテストをするためには (スコア:1)
そもそも論なのですが、
事務計算の様な離散型の計算では、
・カオスはひどいカオス（取り扱い不能になる）にならない
・その代わり、収束させる事が出来ない
様に思いますが、いかがですか？
なにか別のモデルの類推かも知れませんが、失当なのでは
無いでしょうか？
Re:始めにテストをするためには (スコア:1)
＞テストケースは列挙しなければならず、それを先送りにすることの本質は
＞テストを後回しにすることではなく、仕様が固まってないけど頭使いたくないから
＞コードを書き始めた、ということではないでしょうか。
この点は、テストファーストではなく、実行時チェックで解決するしか無いと
思います。
テストファーストの方々は、実行時チェックは駄目だと言っている訳ですし、
相容れないと思います。
せんせーおしえてくださーい (スコア:0)
御説が上手く行くのはどことどことどこでしょうか？
可能な全ての場合で御説は上手く行くのでしょうか？
上手く行く範囲が定まっていない様な最先端の説にはとても関与出来ません。
Re:せんせーおしえてくださーい (スコア:1)
その様な言い方は「せんせい」に言うのは、ふさわしく無いと思います。
設計上のライバルに対して言うのが正当だと思います。
（もっとも、教員としての将来の研究のネタを先に言ってしまった生徒
の指を切る様な教員に対してはふさわしいのかも知れません。）
関数型が手続き型やオブジェクト指向より、必ず良い（無限の責任範囲に良い）
との主張はWikipediaでなされており、
その良さの源は、
・「計算をすると情報量が増える」種類の計算を、
・（よりタチの良い）「計算をすると情報量が減る」種類の計算に、
置き換える事で得られる、との目算からだったのでは無いか
と、1週間前辺りから、自分は思う様になりました。
しかし、その様な虫のよい目算は、100％ついえています。
たとえば、
・戻り値（復帰コード）は下らない。業務知識をうまく活用して、全ての
計算が正しい様にしよう！
とした人間が、自分が関数型で謂れの無い非難をあびていた頃に実際に
いました。
少々の仕様変更で発狂する、一時期居た設計者の存在理由がこれだと
思いました。
・「うまく」全ての場合に、計算が正しい様にしようと無理した結果、
所与の設定（仕様）が少しでも変更されると、致命的に困る様になる。
からです。
・「計算をすると情報量が増える」種類の計算を必要としている分野では
戻り値（復帰コード）は下らなく無い。
というのが歴史的帰着です。
NULLは下らないとか言う人間も、同様で、
「計算をすると情報量が減る」種類の計算を、そうで無いものが必要な
場面で押し付ける類の人間でした。
一時が万事です。
・「計算をすると情報量が増える」種類の計算を必要としている分野で、
・（よりタチの良い）「計算をすると情報量が減る」種類の計算を押し付ける
ことばかり。
・ネタはさまざまで、何らかの事実から情報量を減らしても
構わないと言い張り、その事実が変わった後（あるいは事実を曲げてくる
クラッカーの存在）で、脆弱さを披露するだけの
人間です。
たんなるせんせいに対していう言葉ではないと思います。
Re: (スコア:0)
単にあなたが挙げた個人が学術的被害に遭わない為のムーブに対する皮肉以上の意味のないコメントにズレた(無理筋の主張を回避する手法にいする指摘への回答ではなくソフトウェア開発に対する観点からのよくわからない主張)を長文でできるあたり暇人？
Re:せんせーおしえてくださーい (スコア:1)
次回の日記の内容を、タイミングが合ったので載せただけでした。
それほど暇では有りません。
Re: (スコア:0)
すべての問題を解決する手立てはありません。なぜなら根本的原因が人間は間違いを犯すというところにあるからです。
プログラミングやソフトウェア開発がうまく行かない原因として大きいものにビジネスや業務を的確に表現できる言語やフレームワークが存在しないってのもあるんだろうけど。
Re:せんせーおしえてくださーい (スコア:1)
でもその分野の素人は、ある解法を紹介されると、
明示的に「すべてでは無い」と言われない限り、「すべてだ」と思ってしまう
のは事実です。紛れもない事実です。
専門家が、何か「すべてでは無い」と言わない場合、それにも関わらず「すべて」では無い場合、
詐欺だとするべきだと思います。