人気サイト様 最新記事

博士ちゃんねる ヘッドライン

レスの強調ウゼェー!というドクターへ

レス内の強調表示をOFFにする コチラをクリックして切り替えてください。設定は30日間Cookieに保存されます。
現在のステータス:強調有効

プログラマーの生産性が100倍もの差がつくのはなぜか? @ [プログラマー板]


プログラマーの生産性が100倍もの差がつくのはなぜか? @ [プログラマー板]
1:仕様書無しさん2015/02/09(月) 01:32:20.61 .net
プログラマの生産性は人によって100倍も差が出ることがあるというのは、真実として知られています。
言い換えれば、人によって100倍も早く作れるということです。
これは1年かかる仕事が3日で、1ヶ月かかる仕事が半日で終わるということです。
人件費で言えば、1000万円かかる仕事が10万円で済むということです。

これは脅威です。この生産性を手に入れているのといないのとではコスト以前に仕事が成り立つかどうかのレベルです。
生産性が高い人が参加するしないがプロジェクトの成否に直結しています。
こんな仕事、他にはないです。


ではなぜ100倍も差が出るのか?
100倍の生産性を手に入れるにはどうすればいいのか?

そういう話をしていきましょう。
6:仕様書無しさん2015/02/09(月) 11:52:31.83 .net
モジュールとかオブジェクト指向は生産性を上げるための概念だからな
生産性を上げる気がないなら覚える必要は無い
生産性を上げたいなら今すぐ勉強しろ!
7:仕様書無しさん2015/02/09(月) 11:58:12.58 .net
あとまあ、ソースコードを綺麗に書くだけでも十倍の生産性の差が出るというしな
8:仕様書無しさん2015/02/09(月) 12:05:46.12 .net
オブジェクト指向を勉強したら次はデザインパターンだ!頑張れよ!!
管理人より:「モジュール」とか「オブジェクト指向」とかいうのは、プログラムを分割し再利用性を高めるために考案された手段、および言語レベルで実装されたプログラミング・パラダイム。
「デザインパターン」というのは開発に関わる手法をわかりやすくまとめたもの。
10:仕様書無しさん2015/02/09(月) 18:26:29.39 .net
比較は何だろ。初心者のペーペーとベテランやハカーなら100倍でも不思議は無い
12:仕様書無しさん2015/02/09(月) 20:41:19.90 .net
馬鹿に作らせるとコードが不可解な上に読みにくく、その割にはコード量だけが多く、コピペばかりで1つバグ出すと多数のコピペを修正する必要があり、依存関係が強固で癒着がひどく修正作業が困難を極める。
馬鹿が1匹るだけで生産性100倍低下なんて普通。
13:仕様書無しさん2015/02/09(月) 21:10:05.43 .net
「生産性が低い」んじゃなくて「生産性を下げる」なんだよね。

一人の生産性が低くて遅いんじゃない、一人の開発によって全体の生産性を下げる。
これが大問題
16:仕様書無しさん2015/02/11(水) 10:34:21.87 .net
生産性低い奴は正規表現一個に1日かけたりするからなぁ。
17:仕様書無しさん2015/02/11(水) 10:38:10.25 .net
色んな資料を読まないと正確に書けない正規表現でも書いてるのかそれ
18:仕様書無しさん2015/02/11(水) 11:25:01.15 .net
>>17
せいぜい1時間だろ
19:仕様書無しさん2015/02/11(水) 11:39:39.64 .net
正規表現をロクに理解しないまま、サンプルを加工して使おうとしてハマッてる。
テストでひっかからないミスとかしそうで危なっかしい。
20:仕様書無しさん2015/02/11(水) 13:05:45.79 .net
>>19
いるよねー。

コードを読まないで似たようなコードをコピペして、名前が違うところだけ書き換えて、動かしてみて動かない所を微妙に補正していく奴。


例えば難しいんだけどさ、
100 + 200 + 300
という処理をしたい時に、なんとなく似ているからという理由で
10 + 20 + 30
という処理をしている部分をコピペして、オリジナルを無理やり残しつつ
(10 * 10) + (20 + 180) + StrToInt(IntToStr(30) +'0')
みたいにしちゃう奴。

お前何がしたいの?って言ったら、このコードは○○のとき動かないのでその時だけ値を変更するように修正しました。みたいな。
でテストはしました。じゃあこの場合は? → 動きません。
じゃあ更に条件を分岐させてってどんどん複雑にして生産性を落とすやつ。
管理人より:例えがヒドイけど言わんとすることはまぁわかります。笑
23:仕様書無しさん2015/02/11(水) 16:53:06.94 .net
結局は自分が何をしているのか理解してるのかどうかだよ
27:仕様書無しさん2015/02/13(金) 07:37:44.92 .net
>>1
いいかた逆だろ
三日ですむものが一年たっても出来ないやつには出来ない
29:仕様書無しさん2015/02/17(火) 21:22:11.61 .net
10倍の速さで10倍の生産性のコードを書いたところで、100倍のカネが貰える訳でもないし誰かの穴埋めに良いように使われるだけ
30:仕様書無しさん2015/02/17(火) 22:36:27.19 .net
>>29
そういう後ろ向きの考えの奴には書けないコードだな。
31:仕様書無しさん2015/03/02(月) 19:31:22.99 .net
>>29
会社のために書いてやるわけじゃない
自分のために書くんだよ
32:仕様書無しさん2015/03/03(火) 21:54:37.42 .net
どんな無茶な依頼でもこなしてたら、ソフトの何でも屋にさせられた
ムチャだつって、わざと失敗しとくべきだったのかもしれん
34:仕様書無しさん2015/03/04(水) 00:02:35.47 .net
>>32
なんか弱みでも有ったの?
君なら簡単に出来るよね?」に対して、「それは今まで自分に投資してきたからです。いくらなら買ってくれますか?」くらいの気持ちでいいよ。


まあいきなりは言えないだろうけど、要はそういう方向に持って行きなよ、って事。
35:仕様書無しさん2015/03/04(水) 05:55:53.76 .net
>>34
・初っ端からソフトは規模に関わらず価値ゼロと考えている
・ソフト屋は価値のない奴隷と考えている
・職場では誰も仕事レベルでは使えない技術で作らされていたが、結局いつまで経っても誰も作れなくて全部俺に全て回ってくる


そんなところ
37:仕様書無しさん2015/03/04(水) 10:22:22.93 .net
>>35
価値ゼロとみなすって事は、世間的には「要らない」と同義だから、そんな甘ったれた考えの会社に義理を感じる必要はないな。
まともな対価払ってくれるところへの鞍替えを準備し始めた方がいいよ。
33:仕様書無しさん2015/03/03(火) 22:05:49.55 .net
今からでも遅くはないか
早く終わらせても楽な仕事をしてると思われ
毎回まったく不具合が出ないと簡単なものばかり作ってると思われ


それくらい評価できる人間がいないから、この際ペースをかなり落として、適度に不具合をわざと入れるくらいが丁度良いのかもしれん
36:仕様書無しさん2015/03/04(水) 06:01:29.03 .net
要するに奴隷が欲しいなら採用面接の時にでも言ってくれと
100%内定蹴るから
39:仕様書無しさん2015/03/06(金) 13:05:09.58 .net
量もそうだが特に質が違うんだから、100倍とか言われてもピンとこない
40:仕様書無しさん2015/03/07(土) 02:58:28.03 .net
量は完成までにかかる時間で多少は計れるな。
同僚が平均的に1ヶ月使ってやるような量の仕事を数日で終わらせられたらそれだけで十数倍~数十倍。
不具合が少なくメンテナンス性や再利用性に優れた質の高いコードなら次回以降の作業時間をゴッソリ削れるから更に再利用した回数分倍々。
質の低いコードを書いてる人と比較したら100倍どころの差ではなくなるかもしれない。つまり、ここが正確に計れないわけだ。
質が高く不具合が少なければそれだけ無駄なアフターフォローがいらないから、その会社の不具合率とクレーム対応に要してる時間平均から、どれだけのコスト減と信頼性による営業のしやすさ、引き合い、売上に繋がっているかも計測可能。

当然、給与差も倍率に導入可能。

まあ、そんなものいちいち無駄な時間を使って計算しなくても、見測れる力のある人間なら感覚的にどれだけの生産率かわかるし、圧倒的な生産率ならど素人が見ても違いがはっきりわかるよ。
41:仕様書無しさん2015/03/25(水) 07:31:51.74 .net
一人で作ってたら、できる人でも精々2倍とか3倍なんだろうけど、プログラミングの場合コードの品質が関わるプログラマーの生産性を大きく影響するから、開発規模でかければむしろ1000倍変わるなんてこともザラな気がする
42:仕様書無しさん2015/03/25(水) 08:22:03.03 .net
>>41
でかいのは失敗もあるから、無限倍。
43:仕様書無しさん2015/03/26(木) 02:09:23.21 .net
ソフトウェア最前線 情報サービス産業界に革新をもたらす真実』(PDF)
大本の論文は引っかからなかったが、↑のPDFの7~8ページ目にある、1968年に発表された論文の「プログラミング(デバッグ作業を含む)における個人の能力差は、最大で28対1」が元に尾ひれがついて100倍とかになってたりはする。
ただ継続的に色々なところが調査研究を続けていて、3桁倍まではいかなくても2桁倍は割りとよく出てくる数字だったりす。


まあ、これは頭脳労働が肉体労働に比べて差がでかくなりやすいという部分もあるので、現実的な数字として受け入れられやすい。
実際、100m走のタイムでトップアスリートと健康な成人で、2倍以上の差をつけるのはかなり困難なことを考えれば分かることだし。
47:仕様書無しさん2015/04/07(火) 11:42:14.44 .net
なんでプログラムに関してはこんなアホくさい言説がまかり通ってるのかねえ
手術だって翻訳だって工学だって、1やるためにまず100を事前に知ってる必要がある仕事なんて山ほどある
生産性を年俸ととらえるなら、芸能やスポーツなんてもっと大変な事になる

まあオレツエーごっこしながら仕事するのは楽しいけどな
48:仕様書無しさん2015/04/07(火) 11:47:57.34 .net
シロウトとプロひっぱってきて、現実にはない特殊な条件で仕事を与えて、ほら100倍違うでしょ?って言われても、んな測り方ならどんな職業だってできるだろって話だわな
49: 仕様書無しさん 2015/04/07(火) 13:05:47.19 .net
そんだけソフトは誰でもできるってことだy。たかが100倍だもの。

普通の専門なら素人は出来ないから無限大
50:仕様書無しさん2015/04/07(火) 21:04:47.31 .net
誰でもできる程度の仕事なら商売として成り立ってないはずなんだが
51:仕様書無しさん2015/04/08(水) 01:37:14.33 .net
>>50
やった事の無い事は何でも簡単に見える人ってのは、何時の時代でも居る。
単に想像力の問題。
57:仕様書無しさん2015/04/14(火) 22:50:11.91 .net
プログラミングをバカにしてる人間の大半が「プログラミング始めたばかりのド素人」と同程度
職場にそんなのがいたら1万倍どころの差ではないだろうな
60:仕様書無しさん2015/04/16(木) 10:51:45.18 .net
何倍というかマイナスを何倍してもプラスにならないから
63:仕様書無しさん2015/04/16(木) 21:07:26.85 .net
いくら頑張っても完成させられない奴もいるのだから、100倍とか1万倍ではなく、無限大の差と表現するのが正しい。
61:仕様書無しさん2015/04/16(木) 11:06:07.58 .net
お前らって、生産性の話になると必ず自分より下の奴の話をし始めるよね
62:仕様書無しさん2015/04/16(木) 12:31:47.44 .net
下だと思い込んでるだけだけど
66:仕様書無しさん2015/04/18(土) 09:18:37.39 .net
if (x != 0) {
	if (x != 1) {
		if (x != 2) {
			・・・
		}
	}
}
こういうのが10段くらいネストして、階段状のアートを形成しているのを見た時はカルチャーショックだった
69:仕様書無しさん2015/04/21(火) 01:48:59.97 .net
>>66
「芸術的字下げ」という読みにくいコードの事だな。以下参考までに。
第12章 芸術的字下げ
68:仕様書無しさん2015/04/18(土) 19:36:23.76 .net
おまえらどんだけナイーブやねん
74:仕様書無しさん2015/09/17(木) 08:49:52.88 .net
漫画描いてね→生産性100倍
ピアノ演奏してね→生産性100倍
進学校に受かってね→生産性100倍
この川に橋架けてね→生産性100倍
レクサス作ってね→生産性100倍
90:仕様書無しさん2015/12/11(金) 13:45:09.77 .net
自分1人ではアプリも作れない数合わせプログラマと、100倍の生産力ある人間の年収が2倍程度しか違わない恐ろしい職種w
こんな職種もそうそうないよな。
91:仕様書無しさん2015/12/11(金) 14:33:23.09 .net
技術力を評価する基準が難しいからなぁ。
比較的多く貰えりゃまだマシじゃないかな?


日本企業は未だに年功序列で減給がないから、ITバブル期の無能なオッサン達より年収が低いという現実。
技術力で同じ役職までのし上がっても給与面で勝てない。
転職で年収増えても、転職先の会社内での序列は、やっぱり同じようなもの。
93:仕様書無しさん2015/12/11(金) 19:45:47.93 .net
知識の差も大きいのでは?
初心者にデバイスドライバ書けって言っても、
適切な知識無しには書けないでしょ。
その習得に半年かかったら、100倍くらい生産性に差がでるんでは。
94:仕様書無しさん2015/12/11(金) 20:04:03.58 .net
知識の差も当然あるだろうけど、同じ知識量でも大差が出るよね
95:仕様書無しさん2015/12/11(金) 20:07:17.53 .net
四則計算は誰でも知ってる基本中の基本だけど、人によって計算の速さは違うよね、暗算でも電卓でも算盤でもそれこそ桁違いの速度差が
96:仕様書無しさん2015/12/11(金) 20:13:28.79 .net
いや、数学的なセンスだろ。
97:仕様書無しさん2015/12/11(金) 20:15:07.92 .net
プログラミングとかものづくりもすべてセンスだろ
98:仕様書無しさん2015/12/11(金) 20:49:48.82 .net
センスも大事だが、無能は基本的に考えてない、考えようとしていない
よって、有用な知識や経験があっても活用されることはない
105:仕様書無しさん2015/12/13(日) 15:30:31.31 .net
例えば、YES, NOの選択肢が10 個あれば、1024 通りの選択になるわけだ。
正しい選択をほぼ選べる人間とほとんどランダムに答える人とでは、相当差がつくのはわかるでしょ。
106:仕様書無しさん2015/12/13(日) 18:58:10.79 .net
>>105
これは論理的で分かりやすいな
107:仕様書無しさん2015/12/17(木) 20:08:28.05 .net
123:仕様書無しさん2015/12/19(土) 18:51:24.89 .net

ハイ、そゆわけで、フラストレーションに満ちあふれる冥府マ道の阿鼻叫喚です。
»1さんは自信を持って「こんな仕事、他にはないです」と断言してますが、»1さんが知らないだけで、クリエイティブな仕事はみんなこうだろうとは思います。
まぁさすがに個人レベルで100倍つーと、いやしくもプロならそこまでいくことは滅多にないとは思いますが、トータルで見て10~20倍くらいならあり得ることです。
プログラムというのは「動けば良い」わけではないので、良いコードはメンテ性能とか、長期間の運用に耐えるか…みたいな部分にも関わってきます。書くのが速けりゃいいってもんでもない。

マ業界でですね、こういうものすごい差が出る理由っていうのは、過去に巻末欄に何回か書いてますが、

A) 言ってることがみんなバラバラで統一見解が皆無
B) ソースコードの品質・規模を評価する「客観的な」基準が皆無

↑上記2点に尽きるのではないかと思います。
Bはしょーがないかな、って感じですが、Aはかなり問題ですよ。一例を挙げましょうか。

スレでも出てますが、プログラミング手法のひとつに「オブジェクト指向型プログラミング(OOP)」と呼ばれる方法があります。
これが出た当初はハードのスペックが低すぎてモノにならなかったんですが、今ではハードの性能が段違いですから、ここ15年くらいですっかり浸透し、おおむねみんな「これがイイよね!」とは思っています。
しかしながら、「オブジェクト指向型」にある概念の何をもって「イイ」とするかは、みんなそれぞれバラバラなんですね。
ウソだと思ったらそのへんで右往左往してるマを捕まえて聞いてみたらいいです。「あなたの思うオブジェクト指向の最大の利点はなんですか?」ってね。みんなそれぞれ違った答えを返してくると思います。
「マルチインスタンスだ」「いやカプセル化だ」「継承による多態性(ポリモーフィズム)に決まってるだろ」「名前空間の自由度だよ」「インターフェースによる設計と実装の分離だ」…とまぁ、どっかで聞きかじったような意見もチラホラ。
一番多い答えは「再利用性が高まる」という答えだと思いますが、「では、OOPを使うことで、なぜ再利用性が高まるんですか?」と聞けば、やっぱりみんなバラバラの答えになります。要するにみんなが納得する統一見解などない、そんなフワァ~ッとした概念だということです。

こういった開発手法の究極目的は「プログラムを分割し、再利用性を高め、開発の利便性をはかる」ということなんですが、他のパラダイムを使って再利用性の低いコードしか書けないマが、オブジェクト指向を使ったら突然再利用性の高いコードが書けるのか?というと、もちろんそんなこともありません。
だから、「なぜこれ(OOP)がイイのか?」という点について、ハッキリ因果関係を示しつつ、他と比較しつつ、明確に理由を説明できるひとは、案外少ないのではないかと思います。そして理解の異なる相手に対してはこう思うわけです、「オマエはなーんもわかってないな…」と。

トップ絵は2010年のドラマの方の「スパルタカス」より。
カーク・ダグラス主演の60年の映画の方が有名ですが、スパルタカスというのは当時人気のあった剣闘奴隷。ローマに対して奴隷たちを結集して盛大な反乱を起こします。
我らがIT戦士たちは、このトップ絵のごとくに必死の形相で日々戦っているわけですが、ナニと戦ってるやら、誰が味方で誰が敵なのやら、もはや誰にもわからなくなっているという話。戦ってることだけは確かですけどもね。
皆様が普段何気なく使ってる便利なシステムの裏では、まさに死屍累々ですので、たまにはそんなIT戦士たちの冥福を祈ってやっていただきたいと思っております。
2.8追記:当記事を「提督の野望 海軍広報 Ver7.0」様でご紹介いただきました!いつもありがとうございます~
2.9追記:当記事を朝目新聞様にてご紹介いただきました!大量掲載いつも感謝であります!
スパルタカス シーズン1(SEASONSコンパクト・ボックス) [DVD]
20世紀フォックス・ホーム・エンターテイメント・ジャパン (2015-07-03)
売り上げランキング: 11,519


人気サイト様 最新記事

博士ちゃんねる ヘッドライン

    • ※1 : ドクター・ノオ・ネーム
    • 2016.2.7 22:23
    > 冥府マ道
    ワロタwwwワロタ……

    でも、やっぱりこんな職業は「そうそう」ないと思う
    確かにどんな職業でもペーペーと能力のある奴との差はあるもんだけど、
    マの特殊性は「延々ペーペーのままなのに仕事を続けられる奴」がいること
    他業界なら普通はついて行けなくて辞めるか、問題起こしてたたき出される
      • ※3 : ドクター・ノオ・ネーム
      • 2016.2.8 3:15
      歴史の浅い業界だとそんなもんだと思うがねぇ
    • ※2 : ドクター・ノオ・ネーム
    • 2016.2.7 22:57
    向かないやつはいくらやっても無駄
    あほなやつはいつまでたっても
    糞みたいなものしかつくれない
    • ※4 : ドクター・ノオ・ネーム
    • 2016.2.8 11:12
    単に生産性の定義の設定方法に不備があるからじゃないですかね
    お金や時間絡めるんなら、そりゃ平気で100倍くらいは差がつくものじゃないの
    • ※5 : ドクター・ノオ・ネーム
    • 2016.2.8 16:25
    コード書くの面倒→既存のライブラリをあさる
    エンバグしてないか確認が面倒→テストコードを書く
    いちいちテストするの面倒→ファイル更新を検出して自動的にテストを起動
    「リポジトリにバグ入れんなや」→コミット時にテストを走らせてパスしなければ処理中止
    コードの定型文書くの面倒→エディタに展開させる
    この前似たような処理書いたよな→共通部分をくくりだして関数化

    最近はこういうのが一般にも浸透してきたので差がつくのは頭の出来の差になってきてると感じる。
    • ※6 : ドクター・ノオ・ネーム
    • 2016.2.8 18:24
    まあ変数変えるだけって需要もあるからな
    • ※7 : ドクター・ノオ・ネーム
    • 2016.2.8 18:53
    新人なら100倍なんてざらだけど、たいていは、数本作れば劇的に縮まるよ。
    どんなにセンス皆無でも3年もやれば2倍もなくなるって。
    • ※8 : ドクター・ノオ・ネーム
    • 2016.2.8 21:19
    Debugの速さでかなり差が付くかな。
    瞬時にミスを発見できる人と、
    自分のコードのアルゴリズムすら頭の中で整理できていない人。
    あと、もともと頭のいい人にしか回ってこないけど、
    制御系みたいに新しいアルゴリズムの考案とか、
    数理的な知識を駆使しないと作れないアルゴリズムに基づいたプログラム。
    あと、何年もプログラム書いてると、こっそり作って持ってるモジールが増える。
    • ※9 : ドクター・ノオ・ネーム
    • 2016.2.9 1:02
    100倍というか出来るか出来ないか
    くらいの差が有ると思うな
    プログラムだけでは無く他の仕事に関しても
    出来る人と出来ない人では10倍~20倍の差が有る
    なんての前から報告が有ると良く聞く

    >だから、「なぜこれ(OOP)がイイのか?」という点について、ハッキリ因果関係を示しつつ、他と比較しつつ、明確に理由を説明できるひとは、案外少ないのではないかと思います。
    管理人さんがどう考えているかが書いていない気がするけど(見落としていたらごめんなさい)
    オブジェクト指向プログラミングは機能に関しては独習C++辺りに全て書いてある
    問題はその機能をどう使って活用するか?
    という点の理解や説明が余りされていないのが問題
    オブジェクト指向プログラミングでは処理機能における責任分担を最小限だけ保持したクラスを多種類作り
    各クラスから生成したオブジェクトがそれぞれに連携して処理機能を実現する
    という様に作成すると良い
    この為どういうクラスを作成するのか?
    という点で多数のクラスの作り方が有り
    又オブジェクト同士が連携する為その構造は組み合わせ数となり
    無数の組み合わせが存在する
    だから最適な方法というのを誰も知らない
    デザインパターンと言うのは所謂オブジェクト指向プログラミングの大家の人達が
    こういう風に作る事が良くあって効率よさそう
    というのを集めたもの
    管理人さんが上げているマの人達は解っていないだけの例だと思うけど
    以前のプログラミング言語とオブジェクト思考プログラミング言語の一番違うのは
    差分で機能を開発し易いという点が大きい
    以前のプログラミング言語では関数なんかが肥大化しやすいけど
    クラスを適切に分けるとメソッドの中に書かれるコードが短くなる傾向が有る
    元々コードが一画面を超えるとバグが出易いとは昔から言われていて
    結局1つのメソッド等のコード量が少ないからバグが出にくいという印象を持っている

    オブジェクト指向については1970年代位に開発されて
    処理能力の問題で1990年代頃になって漸く使い物になったけど
    問題はこれ以外に手法が全く開発されない事
    ソフトウェアの要求量が増えているにもかかわらず効率よく作成手法が出てこない
    これってかなり深刻だと思うんだけど
    誰か天才の人が何か開発しないかと思っているけど気配すらない・・・

    正規表現を処理に使う
    というのが未だに信じられない
    あんなどんな罠が隠れるか解らない様なもので処理するなんて
    基本をしっかり押さえていれば大丈夫とか言うんだろうけど
    デバックでも段階的に確認出来ないし
    事前にテストデータ用意するとか本処理以外で使うなら解るんだけど
    webシステムなんかでは当たり前なのかね?そっち界隈知らないのであれかもしれないけど
  1. >「延々ペーペーのままなのに仕事を続けられる奴」がいること

    ここでいうぺーぺーというのは、歯車的なマのことですよね?
    大規模開発はこういう歯車も必要ですけど、年取るとキツイと聞きます。
    -------------------------
    >単に生産性の定義の設定方法に不備があるから

    そのとおりですが、なかなか良い設定方法というのがないのも事実です。
    -------------------------
    >差がつくのは頭の出来の差になってきてる

    大規模開発ではそのへんだいぶんこなれてきてるんですかね?
    -------------------------
    >何年もプログラム書いてると、こっそり作って持ってるモジールが増える

    いわゆる資産ってやつですね。こういう場合にこう解決する…というノウハウも増えるので悩む時間も減りますなー。
    -------------------------
    >管理人さんがどう考えているかが書いていない気がする

    管理人なりの理解というのはあるけど、書けば書いたでクレームが殺到するだろうから書いてないんです。見落としじゃないですよぉ。

    >ソフトウェアの要求量が増えているにもかかわらず効率よく作成手法が出てこない

    そーですねぇ。IBMが昔推進してたなんちゃらアスペクト指向とかどーなったのかなぁ。

    >あんなどんな罠が隠れるか解らない様なもので処理するなんて

    おそらくハードウェアに近いところで仕事してるひとは使う機会ないんでしょうが、ユーザーに近いところで仕事してるマ(管理人含む)は、逆に使わないとなにもできませんのですよ。
    ユーザー入力のベリフィケーションで100パー使います。
  1. トラックバックはまだありません。

*