パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

切り捨て」記事へのコメント

  • ・「構文」とは言語の不可欠な一部分で、上位概念でも下位概念でも
     ないとします。
    ・「型」も「構文」の一種とします。「型」がプログラムの一部を
     肩代わりして、より見通しが良くなるという事は無いので、
     妥当だと思います。
    ・「概念」とは、現にある有形無形の何かに理屈を付けた(つまり
     有形無形のなにかそのものではない)結果とします。
    ・「制御」とは、切り捨てて、早く、安定させるプログラムです。
     
    概念上の「関数」とは、単一の責務を負うものです。しかし構文上の
    「関数」は違います。
    Java言語など、プログラムを書ける場所はfunctionだけ(最近増えました
    が大した違いはないです)なので、概念上の制御もfunctionに書かない
    といけませんし、SubとFunctionがあるVisual Basicでも、絶対にSub
    でなければならない箇所以外はFunctionで書くのが普通なので、
    こちらも、概念上の制御を構文上の「関数」に書かないとなりません。
    (F5で即実行させるには、Public Functionでないとならない。)

    • ・構文上の関数と概念上の関数は一致している事が
       望ましい。
      ・しかし何らかの理由で困難である。一つには、概念
       上の関数が「見えにくい」為ではないか?
      ・「おたくの考え過ぎ」と言われていたものだが、
       紛れもなく必要なものだと思う。
      ・「おたくの考え過ぎ」という意見を取り入れ、
       それが浸透した開発拠点からは、開発能力が面白い
       様に失われるからである。
       
      ・この差異こそが技術的負債である。
      ・テストは大変で必ず債務が生じるが、テストをして
       しまったことで、構文上の関数と概念上の関数の
       不一致が、その債務の大きさにより固定化される
       為である。
      ・詳細設計とは、構文上の関数と概念上の関数の一致
       を導く設計ではないか?
       
      ・自動テストは構文上の関数に対して行われるが、
       プログラムを一から考える人がまず気にするのは、
       概念上の関数である。
      ・このずれが「テストを初めに書くこと」を困難に
       している。プログラムを一から考える人の最終目的で
       ある、構文上の関数と概念上の関数の一致を、
       はじめからやれと強要する形になるからである。
      ・それをやる分かりやすい手順を示してくれるなら
       自分も転ぶでしょうけれど、まったく示してくれない。
      ・少量の利点の為に、大量の失点を呼び込むさまは、
       まるで疑似科学の様である。

      親コメント
      • by dotkuwa (9387) on 2018年04月18日 19時31分 (#3395289) 日記

        例えるなら、
        ・テストや構文は整数に、
        ・概念は実数やそれよりすごい数に、
        それぞれなぞらえる事が可能だとします。
         
        テストは1つ1つ新たな気持ちでやります。
        自分らで作った、売り物のMS Accessのアプリの
        改修で、1日新旧50組のハードコピーをExcelに
        張り付ける事を10日した事があります。
        1組1組新たな気持ちで入力し、目的通り新旧が
        違っているか、変な動きは無いかとかを一々
        確認します。
        これは、整数になぞらえるのが良いと思います。
        #その時、外部からの手伝いの人は、DAO SQLの
        #Insert Selectの癖に引っかかって、
        #(標準SQLは位置で対応付けるが、DAO SQLは
        #名前で対応付ける)そのまま来なくなりま
        #したので自分でテストをしました。
         
        対しまして、概念は実数やそれよりすごい数だと
        思います。
        ですので、初めからテストで概念を数え上げるのは
        非常に難易度の高い事だと思います。
        (というか不可能の代名詞だったり)
         
        プログラムを作っていくと、自然にいろいろな箇所で
        制限が加わり、ある程度以上行くと「制限の加わった
        実数」になると思います。
        それなら整数と対応付くと思います。
         
        そしてそれは、世界のある部分以外を黙殺する事で、
        達成されます。
        何を黙殺するかを間違えると、後で「使えない」と
        言われるのでしょうけれど、何らかの黙殺は絶対条件
        です。
         
        そうなるまで、テストは控えるべきです。
        「ユニットテスト」と言っても(言い得て妙で)確かに
        テストです。それにより構文の修正やリファクタリングが
        決定的に阻害されます。
        「ユニットテスト」をするとリファクタリングがやり易く
        なるというのは正反対です。
        #もちろんすべての修正に対して、極短い時間で正しい
        #「ユニットテスト」を永久に(後継者の育成も含めて)、
        #安価に、提供してくれるならそれは正しいですが、
        #無理の様に思えてなりません。自分はいやです。

        親コメント

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

処理中...