アカウント名:
パスワード:
・「構文」とは言語の不可欠な一部分で、上位概念でも下位概念でも ないとします。・「型」も「構文」の一種とします。「型」がプログラムの一部を 肩代わりして、より見通しが良くなるという事は無いので、 妥当だと思います。・「概念」とは、現にある有形無形の何かに理屈を付けた(つまり 有形無形のなにかそのものではない)結果とします。・「制御」とは、切り捨てて、早く、安定させるプログラムです。 概念上の「関数」とは、単一の責務を負うものです。しかし構文上の「関数」は違います。Java言語など
・構文上の関数と概念上の関数は一致している事が 望ましい。・しかし何らかの理由で困難である。一つには、概念 上の関数が「見えにくい」為ではないか?・「おたくの考え過ぎ」と言われていたものだが、 紛れもなく必要なものだと思う。・「おたくの考え過ぎ」という意見を取り入れ、 それが浸透した開発拠点からは、開発能力が面白い 様に失われるからである。 ・この差異こそが技術的負債である。・テストは大変で必ず債務が生じるが、テストをして しまったことで、構文上の関数と概念上の関数の 不一致が、その債務の大きさにより固定化される 為である。・詳細設計とは、構文上の関数と
例えるなら、・テストや構文は整数に、・概念は実数やそれよりすごい数に、それぞれなぞらえる事が可能だとします。 テストは1つ1つ新たな気持ちでやります。自分らで作った、売り物のMS Accessのアプリの改修で、1日新旧50組のハードコピーをExcelに張り付ける事を10日した事があります。1組1組新たな気持ちで入力し、目的通り新旧が違っているか、変な動きは無いかとかを一々確認します。これは、整数になぞらえるのが良いと思います。#その時、外部からの手伝いの人は、DAO SQLの#Insert Selectの癖に引っかかって、#(標準SQLは位置で対応付けるが、DAO SQLは#名前で対応付ける)そのまま来なくなりま#したので自分でテストをしました。 対しまして、概念は実数やそれよりすごい数だと思います。ですので、初めからテストで概念を数え上げるのは非常に難易度の高い事だと思います。(というか不可能の代名詞だったり) プログラムを作っていくと、自然にいろいろな箇所で制限が加わり、ある程度以上行くと「制限の加わった実数」になると思います。それなら整数と対応付くと思います。 そしてそれは、世界のある部分以外を黙殺する事で、達成されます。何を黙殺するかを間違えると、後で「使えない」と言われるのでしょうけれど、何らかの黙殺は絶対条件です。 そうなるまで、テストは控えるべきです。「ユニットテスト」と言っても(言い得て妙で)確かにテストです。それにより構文の修正やリファクタリングが決定的に阻害されます。「ユニットテスト」をするとリファクタリングがやり易くなるというのは正反対です。#もちろんすべての修正に対して、極短い時間で正しい#「ユニットテスト」を永久に(後継者の育成も含めて)、#安価に、提供してくれるならそれは正しいですが、#無理の様に思えてなりません。自分はいやです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
関数に(少なくとも)2通り有る様な (スコア:1)
・「構文」とは言語の不可欠な一部分で、上位概念でも下位概念でも
ないとします。
・「型」も「構文」の一種とします。「型」がプログラムの一部を
肩代わりして、より見通しが良くなるという事は無いので、
妥当だと思います。
・「概念」とは、現にある有形無形の何かに理屈を付けた(つまり
有形無形のなにかそのものではない)結果とします。
・「制御」とは、切り捨てて、早く、安定させるプログラムです。
概念上の「関数」とは、単一の責務を負うものです。しかし構文上の
「関数」は違います。
Java言語など
Re: (スコア:1)
・構文上の関数と概念上の関数は一致している事が
望ましい。
・しかし何らかの理由で困難である。一つには、概念
上の関数が「見えにくい」為ではないか?
・「おたくの考え過ぎ」と言われていたものだが、
紛れもなく必要なものだと思う。
・「おたくの考え過ぎ」という意見を取り入れ、
それが浸透した開発拠点からは、開発能力が面白い
様に失われるからである。
・この差異こそが技術的負債である。
・テストは大変で必ず債務が生じるが、テストをして
しまったことで、構文上の関数と概念上の関数の
不一致が、その債務の大きさにより固定化される
為である。
・詳細設計とは、構文上の関数と
例えるなら、 (スコア:1)
例えるなら、
・テストや構文は整数に、
・概念は実数やそれよりすごい数に、
それぞれなぞらえる事が可能だとします。
テストは1つ1つ新たな気持ちでやります。
自分らで作った、売り物のMS Accessのアプリの
改修で、1日新旧50組のハードコピーをExcelに
張り付ける事を10日した事があります。
1組1組新たな気持ちで入力し、目的通り新旧が
違っているか、変な動きは無いかとかを一々
確認します。
これは、整数になぞらえるのが良いと思います。
#その時、外部からの手伝いの人は、DAO SQLの
#Insert Selectの癖に引っかかって、
#(標準SQLは位置で対応付けるが、DAO SQLは
#名前で対応付ける)そのまま来なくなりま
#したので自分でテストをしました。
対しまして、概念は実数やそれよりすごい数だと
思います。
ですので、初めからテストで概念を数え上げるのは
非常に難易度の高い事だと思います。
(というか不可能の代名詞だったり)
プログラムを作っていくと、自然にいろいろな箇所で
制限が加わり、ある程度以上行くと「制限の加わった
実数」になると思います。
それなら整数と対応付くと思います。
そしてそれは、世界のある部分以外を黙殺する事で、
達成されます。
何を黙殺するかを間違えると、後で「使えない」と
言われるのでしょうけれど、何らかの黙殺は絶対条件
です。
そうなるまで、テストは控えるべきです。
「ユニットテスト」と言っても(言い得て妙で)確かに
テストです。それにより構文の修正やリファクタリングが
決定的に阻害されます。
「ユニットテスト」をするとリファクタリングがやり易く
なるというのは正反対です。
#もちろんすべての修正に対して、極短い時間で正しい
#「ユニットテスト」を永久に(後継者の育成も含めて)、
#安価に、提供してくれるならそれは正しいですが、
#無理の様に思えてなりません。自分はいやです。