アカウント名:
パスワード:
・技能・技術・権限配分はそれぞれ、・「出来るだけ余力が有るのか?」・「割り当てられて本当に出来る能力が有るのか?」・「そもそもして良いのか?」、「するに相応しい情報が与えられて居るか?」に対応すると思います。 例えば、「プログラマーがテストを書くべき」という命題に対して、一番問題なのは、「するに相応しい情報が与えられて居るか?」です。 プログラマーに与えられる情報は、正しさを担保したものでは有りません。ですので、・もっと曖昧な与えられた情報・規約・リーダーからの口頭指示を元に、それなりの動くものを作成します。 それをテストして、正しい誤っているを判断し、誤っ
「プログラマーがテストを書くべき」という命題が真だとすると、・名実ともに、プログラマーが「何が正しいかを決める」。・プログラマーはあまり他人とコミュニケーションは取らないのに、 名実ともに、「何が正しいかを決める」側で有るという権限配分に なったとしたら、プログラマーに非ざる人間の生存すら危ぶまれる。事になります。権限配分の軸としては、極北の位置になってしまいます。 いくらなんでもプログラマーがそんなに偉いはずが有りません。とすると、・権限配分の軸はそのままに、「するに相応しい情報が与えられて居」 無いプログラマーに無理やりやらせる。事以外無くなります。
特にオブジェクト指向言語とかで見られる、・public・private・finalなどの修飾は、・publicが付いているやつは、みんなで使うから譲れない・privateは、譲り合いの為に自由度を確保する・finalは、部品としてほかの人が使う場合も、譲り合い の対象にして欲しく無いという意思表明だと思います。 技術的負債という言葉が有りますが、これも、・譲り合いの為の自由度を内部留保しておかないと、 ちょっとした事で、破産する・負債と言っているのは、その内部留保を考え無しに 使い切ってしまう事で、事実上の倒産となって しまう事の様に思えます。 もちろんこの様な事は、ソフトウェア開発に限らず、「人間にフィットしていないフィールド」の一つである車の運転でも有り得ます。・車線をまたぐ際は、後ろを直接見て、側方を直接見て、 それからまたぐべきなどと言うのは、その「極端な譲り合い」の一つだと思います。(昔、80のスクーターで右側車線に移ろうとした時、直接 目視をしたおかげで、右側直後にいた車を避けられた (車線変更中止が出来た)事が有りました。 反対側歩道にいた白バイの人の顔が真っ白になっていて、 笑いかけてみようとしたら、自分の顔もピクリとも 動きませんでした。)(ただ、人間同士、人間と自転車の場合は、「車線」の というものの認識すら、「なにが正しいか終わってみる まで分からない」という厳しい前提条件が有る為、 その場合は、必ずしも有効では有りません。) 要するに「所作」が大げさになるのが特徴です。 ただ、ソフトウェア開発の場合、大げさな「所作」は、車の運転の様に決まっていません。もちろん、オブジェクト指向の先ほどの修飾の様に、決める努力をしていることはしているのだとは思います。(java9でpackegeにも公私を分ける様にするとか、書いて在りました。今のままでは全く足りないのでしょうww)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
具体的に言うと (スコア:1)
・技能
・技術
・権限配分
はそれぞれ、
・「出来るだけ余力が有るのか?」
・「割り当てられて本当に出来る能力が有るのか?」
・「そもそもして良いのか?」、「するに相応しい情報が与えられて居るか?」
に対応すると思います。
例えば、「プログラマーがテストを書くべき」という命題に対して、
一番問題なのは、「するに相応しい情報が与えられて居るか?」
です。
プログラマーに与えられる情報は、正しさを担保したものでは有りません。
ですので、
・もっと曖昧な与えられた情報
・規約
・リーダーからの口頭指示
を元に、それなりの動くものを作成します。
それをテストして、正しい誤っているを判断し、誤っ
なんで「道徳」になるか? (スコア:1)
「プログラマーがテストを書くべき」という命題が真だとすると、
・名実ともに、プログラマーが「何が正しいかを決める」。
・プログラマーはあまり他人とコミュニケーションは取らないのに、
名実ともに、「何が正しいかを決める」側で有るという権限配分に
なったとしたら、プログラマーに非ざる人間の生存すら危ぶまれる。
事になります。
権限配分の軸としては、極北の位置になってしまいます。
いくらなんでもプログラマーがそんなに偉いはずが有りません。
とすると、
・権限配分の軸はそのままに、「するに相応しい情報が与えられて居」
無いプログラマーに無理やりやらせる。
事以外無くなります。
「極端な譲り合い」の例 (スコア:1)
特にオブジェクト指向言語とかで見られる、
・public
・private
・final
などの修飾は、
・publicが付いているやつは、みんなで使うから譲れない
・privateは、譲り合いの為に自由度を確保する
・finalは、部品としてほかの人が使う場合も、譲り合い
の対象にして欲しく無い
という意思表明だと思います。
技術的負債という言葉が有りますが、これも、
・譲り合いの為の自由度を内部留保しておかないと、
ちょっとした事で、破産する
・負債と言っているのは、その内部留保を考え無しに
使い切ってしまう事で、事実上の倒産となって
しまう事
の様に思えます。
もちろんこの様な事は、ソフトウェア開発に限らず、
「人間にフィットしていないフィールド」の一つである
車の運転でも有り得ます。
・車線をまたぐ際は、後ろを直接見て、側方を直接見て、
それからまたぐべき
などと言うのは、その「極端な譲り合い」の一つだと
思います。
(昔、80のスクーターで右側車線に移ろうとした時、直接
目視をしたおかげで、右側直後にいた車を避けられた
(車線変更中止が出来た)事が有りました。
反対側歩道にいた白バイの人の顔が真っ白になっていて、
笑いかけてみようとしたら、自分の顔もピクリとも
動きませんでした。)
(ただ、人間同士、人間と自転車の場合は、「車線」の
というものの認識すら、「なにが正しいか終わってみる
まで分からない」という厳しい前提条件が有る為、
その場合は、必ずしも有効では有りません。)
要するに「所作」が大げさになるのが特徴です。
ただ、ソフトウェア開発の場合、大げさな「所作」は、
車の運転の様に決まっていません。もちろん、オブジェクト
指向の先ほどの修飾の様に、決める努力をしていることは
しているのだとは思います。
(java9でpackegeにも公私を分ける様にするとか、書いて
在りました。今のままでは全く足りないのでしょうww)