パスワードを忘れた? アカウント作成
13868121 journal
日記

dotkuwaの日記: 奇妙な悪口を聞きました 7

日記 by dotkuwa

奇妙な悪口を聞きました。それは、
・プログラミングしか出来ない蒙昧な職人のおまえに、
 科学的なデータの作り方を教えてやる。
というものでした。
 
単なる1関数だけを扱うなら兎も角、複数の関数などが
共同して、結果を正しく得るには、
・それら関数などの間にプロトコルを設けて、全体で
 正しい様にしなければならない。
・それのテストは、1関数をテストする様な、きれいな
 形にならない。
ですが、
その「プロトコル」というのと、「科学的なデータ構造」
というのは、かなり同じです。グラフの双つい関係の様で
瓜二つです。ViewModelなどというデータ構造的存在が、
プロトコルの切り口領域に出来るのも、だからだと
思います。
#そしてそれらは、概してたちが悪いです。
 
さて、
プログラミングしか出来ない蒙昧な職人
 (科学的なデータの作り方を知らない)

ですが、
本当に職人として、たちの悪い部分も含めたプログラミングを
やり遂げている人間とは思えません。
 
では、どういう人間でしょうか?
それは、
・1関数のみで成果を得ている人間
です。そうならば、
・複数の関数など間のプロトコルが定まる前に
 手間をかけて、自動テストを初めに作る
事が最善です。
まさに藁職人です。そんなことで職人として報酬は得られません。
 
科学的なデータの作り方を啓蒙してやって、彼らも、
教える方もWinWinの関係になれる相手。
そういう相手と『成り得る人間の要件』こそが、
・1関数のみを始めにテストを書いて作業を進める
 『ことしか出来ない』
人間です。
 
もし、そういう人間(老害の職人)が多数いて、しかも、
職を得て金銭を得ているならば、彼ら彼女らに、
科学的なデータの作り方を教示する職業は成り立ちます。
すばらしい!
しかし、
そういう人間の居る世界を人為的に目指して、そのとば口として、
・初めにテストを書く
事を他人に勧めたのだとしたら、悲しい事です。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2019年03月23日 15時54分 (#3585971)

    単体テストはできるけど全体テストはできないということかな?
    文中の藁職人でも充分役に立つので報酬得てもいいと思いますけどね。
    プロトコル決めるのは上の人なので。
    必要な機能を洗い出してそこの部分は他の人に作ってもらう。
    綺麗に組み合わせるのはそれと並行して時間をかけて考える。
    それでこそ設計者というものです。
    例えば建築のモジュラー設計とかユニット工法とか。

    • by dotkuwa (9387) on 2019年03月24日 2時55分 (#3586132) 日記

      自分の疑問点は、
      >プロトコル決めるのは上の人なので。
      >必要な機能を洗い出してそこの部分は他の人に作ってもらう。
      >綺麗に組み合わせるのはそれと並行して時間をかけて考える。
      >それでこそ設計者というものです。
      >例えば建築のモジュラー設計とかユニット工法とか。
      を思いつくのはどうするのか?
      です。

      「建築のモジュラー設計とかユニット工法とか」が構成出来ない
      から困っているのです。

      実際にやってみないと思いつかない、のでは無いかと想像
      しています。思いつく手段が無いと、絵空事にしかなりません。
      設計者にとって、固まっていない時期の余計なテスト作成は、
      邪魔にしか過ぎないでしょう。

      ウルトラスーパーな「設計者」を持ち出せば済むのは、外野の
      人間だけです。
      現実には、ウルトラスーパーな「設計者」が不在で、実際に
      やりながらプログラマーが決めていると思います。

      親コメント
      • なんで、この様な事になるのか?
        それは、情報分野では公式に教師とされている人間が、
        疑似科学を教えているからでは無いか?
         
        (たとえば、本当に例えばですが)GMドライブという
        疑似科学が有ったとして、テレビの前のちびっこに、
        それを使って平和強制が可能か提示する事ならOKでしょう。
        しかし、電力会社に入ったちびっこが、実務をしている
        人の手を払いのけて、GMドライブこそ必要だと力説したら
        かなりの説得が入ると思います。
         
        とにかく、
        疑似科学を検証すべきは情報分野では無いかと思います。
        もし、公式に教師とされている人間が、それを教えていたら
        絶望的だし、新しい若い人が言う新しい事が、絶望を
        もたらすだけになります。
         
        >プロトコル決めるのは上の人なので。
        >必要な機能を洗い出してそこの部分は他の人に作ってもらう。
        >綺麗に組み合わせるのはそれと並行して時間をかけて考える。
        >それでこそ設計者というものです。
        も、いう事は出来でも、実際には出来ない疑似科学の可能性が
        有ります。

        親コメント
        • 個々の手段、要素が疑似科学かどうかは、ここでは
          差し控えますが、
           
          一つ、まぁ自信を持って言える事が有ります。
          情報分野は、理系か文系かという事とも絡みますが、
          ・理系の大学の先生は、有る課題で成果を上げて、
           学位を取る。その後、類似した分野に進む。
          と思いますが、
          ・情報で「設計者」として必要なのは、理系の大学の
           先生では無く、むしろ、小学校の先生(教える為に
           掛け算に順番を付けるのも厭わない)や、年取った
           経理のおっさん(そろそろ実用書でも書いてみるか)
           なのでは?
          という事です。
           
          そのこころは、
          ・情報で「設計者」として必要なのは、「類似した」分野
           での成果で無く、「今回必要としている」分野での
           精密でしつこい成果
          ・「類似した」分野の成果が役に立つことは、全くと言って
           いい程、無い。
          という点です。
          大学として「設計者」を何とか養成しようとして、専門学校
          に劣ったパフォーマンスしか得られず、実際の大学機能は
          SIerが保持し、個々の商用プロジェクトこそが1つ1つ学会で
          有るという現実は、この点から来ているのでは無いか?
          と言えると思います。
           
          なので、何が疑似科学かは、
          ・問題と合っているか合っていないか
          で決めるべきで、
          ・理系の物理とか化学とかのやり方と合っているかどうか
          で決めるべきでは無いと最小限言えるでしょう。

          親コメント
      • コボラーとしての経験では、
        ・設計書は提出文書として、開発の目鼻が付いた後に書き始める
        というのが普通でした。
        もちろん、ポンチ絵的な要求仕様と、顧客との話し合いはされていました。
        目鼻がついてから、テスト開始までに、文書化していると、
        ・あーーっ。不味い!!
        という事を(文書上で)見つけて、慌てて言いに行った事も有ります。
         
        しかし、
        その様なパラダイムから、
        ・設計書は先に書くパラダイム
        にシフトました。
        大規模開発をするには、それで無いとダメだ、という要件からです。
         
        しかし、設計書を先に書くパラダイムは、コボラーの(後に)書いていた
        設計書を流用しただけではなかったでしょうか?
        そのネタが尽き、
        本当に本当に本当に初めから「先に書く」をすると、間違いだらけだったり、
        つら過ぎて、間違いを苦に自死が多発したりして、こちらも廃れて、だれも
        設計書を書かなくなった、経緯が有るのでは無いでしょうか?
         
        本当に辛い時は、布団をかぶって寝るのが最善ですが、独り者だったから
        出来た話です。新婚のSEが自殺したなんていうのも、それが出来なかった
        せいかも知れません。
         
        設計書は提出文書として後から書くのが正解で、それではダメな大規模開発
        はよっぽどの巨額投資が無ければするなが正解かも知れません。
        その巨額投資をしてどうやって作り上げるかというと、作っては壊し、
        作っては壊しになると思います。

        親コメント
      • by Anonymous Coward

        設計者がいないので設計者になるには・育てるにはどうするかということでしたか。
        dotkuwaさんの話ではいろいろ分業されているのでてっきり。

        画面はUIデザイナーに投げるかユーザーに妥協してもらうとして。
        やはり要件を的確に定義すること、入出力をきちんと定義することに尽きると思います。
        それさえ出来れば逆に丸投げで済むので。それが難しいんですけどね。
        難しい計算は簡単な計算に分割する。分割が難しいなら補助線入れたり数を調節したり丸めたりする。
        システム設計も同じですし、それを思いつくのが設計者の腕です。
        上記のことができるかどうかが算数・数学に関する頭の良さである

        • by dotkuwa (9387) on 2019年03月25日 19時47分 (#3587111) 日記

          >設計は技術です。設計者がいないからといって、勉強せずに設計できると思うなんて
          >そりゃ設計者をバカにしすぎってものです。
           
          自分は、勉強して設計が出来る点に対して疑問を持っています。
          ・情報で「設計者」として必要なのは、「類似した」分野
           での成果で無く、「今回必要としている」分野での
           精密でしつこい成果
          ・「類似した」分野の成果が役に立つことは、全くと言って
           いい程、無い。
          と申しました通り、
          ★知識が有って、それを平易に述べられる能力が有れば
           出来る(設計者固有の知識ドメインは無い)
          という主張です。
           
          なぜなら、
          ・設計の文書を体系的に着実に構成する手順が無い。
          ・設計の文書を体系的に着実に検証する手順が無い。
          ・嘘を書くのは面白い。本当の事を書くのは心に錐をさす
           位苦しい。
          ・まだ、体系的に検証したり(欲を言えば構成したり)
           出来ればましだが、無い。(これは誰もが認める
           (好ましく無いが))真実。
          という性質が有る為、
          ★設計書は嘘が混じる。特に即テストが書ける位の
           細かさの設計書では、正しい部分が1割を切る。
           その様な細かさの設計書は(そんな打率なら)無い方が
           良い。
          ★ドメインの専門家が、ポンチ絵やポンチ文で散文的に
           書いたものの方がありがたい。
          からです。
           
          まとめると、
          「指導的な設計者」という存在を規定することは、疑似科学では
          無いか?
           となります。設計書には嘘が混じります。必ずです。
          それを振りかざす設計者もかなりの嘘を言います。それは仕方ない
          のかも知れませんが、仕方ないと規定する代わりに、そういう人間は
          「指導的」立場からは外すべきです。
          そして、その様な存在を輩出しようとしている教育も疑似科学では
          無いか?という事です。

          親コメント
typodupeerror

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

読み込み中...