1 ：
仕様書無しさん：
さっぱりわからん
つーかオブジェクト指向の達人てなんだよｗ
わからんやつは芯で良いよ
オブスレ池
5 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/11/22(木) 20:24:44
呼んだ？
6 ：
仕様書無しさん：2007/11/22(木) 20:26:44
どんだけ～～～～～
オブジェクト指向が全くわからん人に一瞬で理解させるぐらい凄い
×理解
○誤解
日常会話でオブジェクト指向用語が出てくるぐらいすごい。
この間、俺とワイフの多重継承したチルドのインスタンスがニューされたよ。
目元は俺を継承して、口元はワイフを継承している。
きっと多彩なクラスをインプリメンツしたクレバーなチルドになるぞ。
フューチャーが楽しみだ
ルー語じゃねぇかｗｗｗ
12 ：
仕様書無しさん：2007/12/03(月) 20:27:04
昨日彼女と一緒にメメント観てたらいつのまにかチムポがブリッジしちまってさー
そしたら彼女が俺の上にビジターしてきてアダプタしちゃったよ
まあ全部俺の妄想で本当はシングルトンな毎日なんだけどさ
オブジェクト指向全然関係ねー
俺の先輩は仕事を俺にデリゲートしてばっかりでこまる。
15 ：
仕様書無しさん：2007/12/10(月) 11:02:27
N○○のPMは基本クラスというより抽象クラスで、
メソッドの中身が入っていない上に、全メソッドがオーバーライド必須ときている。。。
16 ：
仕様書無しさん：2007/12/10(月) 21:34:00
リアルのすべてのものの継承関係を考え続ける
17 ：
仕様書無しさん：2007/12/17(月) 22:02:51
俺そうかも
俺にとってのオブジェクト指向とは：プログラミングとは一種の道だ。
その道が出来ていなかったら終わりまでたどり着かない。オブジェクト指向とは
その道を通るときの橋やらフェリーやらそういう物だと考えている。
カプセル化とかは入っていないが割愛する。
19 ：
仕様書無しさん：2007/12/18(火) 22:59:41
俺にとっては全ての物事を論理的にとらえるための考え方だな。
たまたまその考え方がプログラミングにも使えるだけだ。
20 ：
仕様書無しさん：2007/12/18(火) 23:41:11
お前らの想像以上に達人はすごいよ。
まず達人の作るクラスなんかは階層構造が深すぎて
実装可能なコンピュータが地球上には存在しない。
メソッドの数の総計は宇宙に存在する原子の数よりも多いのではないかと
言われている。
存在しないと思われていたjava.lang.Objectのスーパークラスを発見したのも達人の功績
22 ：
仕様書無しさん：2007/12/19(水) 00:41:17
ルー語ｗ
達人は 保護されているッッ！
... General Protection Fault.
ぬるぽもOOの達人に発見された
あ。。。
>>9 「直交する概念」「ひも付けられる」
とかも使って欲しい
28 ：
仕様書無しさん：2008/02/09(土) 00:01:58
女もオブジェクト。
欲しいときにインスタンス化。そしてインジェクション
金という引数が必須
29 ：
仕様書無しさん：2008/02/10(日) 07:56:55
女はファイナライザにとんでもないバグが入ってることがあるからなあ
30 ：
仕様書無しさん：2008/02/10(日) 23:46:23
太鼓の達人並みに凄い
目からビームが出る
32 ：
仕様書無しさん：2008/02/11(月) 01:33:18 BE:156092663-2BP(2)
オブジェクト指向の達人といえば誰だ？
JavaだけでなくSmalltalkを使いこなせる者？
デザインパターンを駆使できる者？
使うのがたまたまオブジェクト指向
たまたま使うのがオブジェクト指向なだけで、そういう縛りがなければもっと自由にすごい事をやっちゃう人。
オブジェクト指向の達人になるには
ロバートＣマーチンのアジャイルソフトウェア開発の奥義
に載っているオブジェクト指向設計原則も理解しないとだめかねえ。
多分古参が言う「オブジェクト指向の達人」っていうと青木淳さんだろうな。
この人の書く文章は仏教思想も入っていて面白い。
つーか、Matzといい結城といい青木さんといい、日本でのその道の大家はなぜか宗教的なものを備えているのが気になる。
まあ、東大卒でオウム真理教に入ったやつと似たようなもんだな。
>>36 A氏の言ってることは耳にタコができた古くさいMVCとうさん臭い仏教話だけと思われ
宗教はいってる時点で俺はパスだな
宗教人はたいてい表の顔と裏の顔のギャップが激しいから。
宗教人なのではなくて、宗教を信仰しているだけだろ。
日本人はそこら辺の感覚が無いから信仰を持っている人間が奇異に映るのは確かだが。
まぁ、確かに青木さんの言ってるオブジェクト指向話は
あくまでスタンドアロンの仮想世界上で閉じたMVCであって、
当世風のネットワークを意識した設計と相容れない部分があるのも確か。
>>41 日本で信仰を持ちながら生活すると
どうしても表と裏ができるんじゃないかな
宗教について鈍感なだけなのに、日本人は宗教について寛容とか、
ボケてる奴がほとんどだから、どうしてもそういう対応をせざるをえない。
>>40 そうそう。表面はよくても利害が絡むととたんに豹変とかね。
46 ：
仕様書無しさん：2008/02/18(月) 08:34:23
36の唐突さは社員だな
47 ：
36：2008/02/19(火) 00:33:53
社員じゃねーよ。青木さんとも面識は無い。
どちらかと言うと SRE はそこの製品でえらい目にあったからあんまり好きじゃない。
49 ：
仕様書無しさん：2008/02/21(木) 13:05:04
39 正直内容が古くさすぎ
誰とは言わないが、日本のソフト業界にOOが導入されようとしていた時、
OOの達人と言われていた人達が変に宗教的概念を混ぜ込んでしまったために
OOが純粋にプログラミング技術として素直に紹介されなかったことが
日本でOOの導入が遅れた要因だと思う。
>>50 それはあるな。キリスト教(Java, ruby)とか仏教(Smalltalk）とか、胡散臭さを醸し出していた。
結城、松本、青木か。
N村S3郎は密教がどーたら、とか言ってたな
鵺だTAOだ言ってる奴等も電電公社方面にいたし
共通しているのは自画自賛にすごく熱心な人達ということだな
そういう人達の実装技術はどんなもんかね。
matzは処理系実装しているからいいとして、
他の人達が自分自身でつくったものは
どの程度のものなんだろう。
聞いた話だけどじゅんはopengl周りとかquicktime関連は別の人が書いたらしいよ。
matzのコードは糞コードと言われてるらしいけどな(どの観点で言われてるのかは知らないけど)。
まぁ、美しい文法を作るのが仕事で、実行効率は二の次とか言ってるみたいだしさもありなん。
美しい文法？あのperlくずれみたいな文法が？
美しいは確かに間違いだ。すまん。
それなりに力があって読みやすくて痒いところに手が届く文法。
まぁ、俺はそんなもの慣れの問題だと思ってるが。
matzってANSIスタイル徹底的に嫌ってなかったか
人とちょっと違うぜ感に浸ってるイメージ
(1) 書き始めたのが昔
(2) 一旦どちらかで書いたら混在させないほうが良い
63 ：
仕様書無しさん：2008/08/08(金) 07:11:29
教訓
この手の人達は我が強すぎるため協調作業に向いていない。
>>62 書き直せばいいだけ。コードレビューにもなるし。
それが面倒なら、フィルタを書けばいいじゃん。Rubyで。
>>57 1人の有名プログラマーの影には10人の踏み台プログラマーが使い捨てられているものだよ
>>65 10人程度なのが日本人の限界なんだろうな。
Linusなら1桁上をいくからな。
OOの真価は他人（特に格下）に使わせるものを作るときに発揮されるから
達人はすさまじいです。
boost使ってんのすげーという人がいる。
そこでboostを作っている人はドンだけ凄いかってこと。
69 ：
仕様書無しさん：2008/11/08(土) 14:28:41
しかし思うんですが、オブジェクト指向設計や同プログラミングでチームで開発する
という場合、横割りでクラス分担するとかするという方法では、基本的にメソッドなど
のインターフェースを最初に決めておいて一斉に作成作業に取り掛かるとなったとき、
後から後から次々にここはこうでないとダメだった、こうしよう、あれはああ
でなかったらできない、こうしよう、どうしよう・・・というインターフェースの変更が
とめどもなく現れてくる予感がして、収集が付かなくなる感じがするのですが、
実際にやっておられる方々はそうした点をどうやって乗り越えておられるのですか？
よろしかったら教えてください。
>>28 女にオーバーライドしたことがないクセに・・・
>>69 多人数の時には、設計時に十分レビューをすることで対処。
比較的少人数の時には、設計と実装を毎日のように往復することで対処。
オブジェクト指向とは、楽するために苦労する為のものである。
本当に大事なのは、オブジェクト指向の達人になることではなく、プログラミングの達人になること。
オブジェクト指向の達人なんて、みんなインチキコンサルやセミナー屋ばかり。
オブジェクト指向はそもそも量産のための技術だからな
オブだけでジムやボールを作れても、オブだけを極めてもガンダムは作れない
アルゴ君に続く新人「オブ君」の誕生を見た！
オブジェクト指向って言いながらできる人って少ないんだよね。
メソッドの引数に応じて、オブジェクトの振る舞いが変わるとか死ねばいい
引数の値によって関数の結果が変わらなかったら関数の意味がないだろ。
実はオブジェクト指向以前の人って多いんだよね。
78 ：
76：2010/07/13(火) 12:34:54
結果と振る舞いを同義だと思ってる人は死ねばいい
メソッドと関数が同義だと思っている人は死ねばいい
C言語の関数とC++のメソッドはクラスに属するかの違いだけで、大した違いはないから
たかがクラスが理解できているからといって調子に乗るなよ、ガキ
どうやら概念が全くできていないらしい。
>>72は
>>81のような人間に作られたコーディングで苦戦を強いられてるんだよ
83 ：
81：2010/07/13(火) 14:02:19
>>82 だから1KStep/DayのPG/SE/Corderだから苦戦なんて全くの別世界
84 ：
81：2010/07/13(火) 17:30:27
>>82 全く理解できているので、もう一言。
>>81で大した違いはないといったのは、大雑把に言えば
メソッドはそのクラスの変数に対して操作を行うことができて
他のクラスや、どのクラスにも属さない関数からの直接の
アクセスを禁止して、変数の操作を限定している。
これによって、不正な変数操作ができないようにしているが、
私の考えとしては、メソッドはクラスに属する関数で
あり、なんらそれを異なるものと認識するのは違っていて
関数という範疇におさまるものと考えられるが。
85 ：
81：2010/07/13(火) 17:36:52
関数の機能
・変数の値を操作する
・他の関数を呼び出す
この機能をメソッドも同じくもっているため
上記のように考えられるが。
86 ：
仕様書無しさん：2010/07/13(火) 20:19:52
まず理解しやすく分解してみるか。
> 大雑把に言えばメソッドはそのクラスの変数に対して操作を行うことができて
> 他のクラスや、どのクラスにも属さない関数からの直接のアクセスを禁止して、変数の操作を限定している。
メソッドはprivate protected 属性へのアクセスのために存在する。
private protected 属性によりデータをカプセル化し、他のインスタンスからの直接のアクセスを禁止する。
> これによって、不正な変数操作ができないようにしているが、
> 私の考えとしては、メソッドはクラスに属する関数で
> あり、なんらそれを異なるものと認識するのは違っていて
> 関数という範疇におさまるものと考えられるが。
これによって、インスタンスの持つデータに対する外部からの不正なアクセスを禁止し、
外部からデータの変更を防止する。
よって関数と言う事になる。
> 関数の機能
> ・変数の値を操作する
> ・他の関数を呼び出す
> この機能をメソッドも同じくもっているため
> 上記のように考えられるが。
読解不能
俺、お前部下にいたらイラン
お前が偉そうに書いた事は全て分かっている。
＞メソッドはクラスに属する関数で
に関してはメソッドはクラスに属している関数ということができ
と修正する。
後段は関数とメソッドの機能の類似点を上げているだけで、
C言語の関数をC++ではクラスごとにその関数をクラスの変数を
操作するように新しく定義したまでの事であり、関数が進化した
だけのものだと考える。
オブジェクト指向を学んでから、16年経っている俺に偉そうな
講釈を有難う。
お前の部下になぞ、何でならなくてはならないのか分からないが、
>> 大雑把に言えばメソッドはそのクラスの変数に対して操作を行うことができて
>> 他のクラスや、どのクラスにも属さない関数からの直接のアクセスを禁止して、変数の操作を限定している。
>メソッドはprivate protected 属性へのアクセスのために存在する。
>private protected 属性によりデータをカプセル化し、他のインスタンスからの直接のアクセスを禁止する。
ここの部分はお前が勝手に上記の部分の説明をしただけで
なんら言っている事に相違はないだろ。
あるんだったら、指摘しろ。
C言語の関数の機能、特徴をC++のメソッドも持っているということで、メソッドは関数の
SubSetということがいえるのではないかと言っている訳だが、通じないの？
俺のチンポクラス、ずっとラッピングされたままなんだけど。
長年オブジェクト指向に携わっていながら
その本質を３行でまとめられないとか才能無いから
はやく業界から立ち去ってくださいね
92 ：
81：2010/07/14(水) 06:29:36
どこが間違っているのか指摘してくれ、自分の覚えている内容と
違うからといって間違いとは限らないんじゃないの？
>>91 立ち去るとか言ってもねリストラされてから、就職活動中。
13KStepの新規タスクの開発をしたから、自分でいうのも
何だけど、かなり優秀なPG/SEといえると思う。
年収査定も430万円～680万円だからね。
俺に業界から去れなんて言う人間は、自分の年収査定を
晒してみろよ。
お前鬱病だろ
プライドが高いくせに仕事ができんからってこんなとこで鬱憤晴らしていても仕方ありませんよ。
すぐにテレビ局がかみついてきて、自分の説を世の中に
公開するのがおかしいというような発想は官僚的であり、
そのような思考がこの国を凋落させている原因だと思う。
「メソッドは関数のサブセットである。」
という事に対してね。
何か真面な反論がある方はどうぞ。ご教授いただきたい。
>>96 仕事ができないんじゃなくて、俺の能力を活かせるような真面なプロジェクトが
ないっていう事が問題なの。
4/15プロジェクトだった、真面なプロジェクトは。
>>96 過去にそのようになった事はある
・せまい
・うるさい
・仕事がない
・ネットがつながっていない
・椅子が固い
という信じらねない現場があって。
>>97 設計上では、関数が一連の処理をまとめた手続きであるのに対し、
メソッドはオブジェクトへの操作である。
これをOOPLの構文だけを見て何の前提条件も無しに、
一緒くたに「同じ」としたのでは、概念が分かってない、
と言われてもしょうがないな。
あんたは実装の話しかしてない。
>>100 同じとは全くいっていない、ちゃんと読んで欲しいね。
>>85に書いてある特性をどちらも持っているから
メソッドが関数を汎化したサブセット(サブクラス)
と考えられると言っているのだが。
>>100 >一緒くたに「同じ」としたのでは、概念が分かってない、
概念はわかっている。ならどこが違ってたのか説明してくれないと
分からない。
概念と実装をごっちゃにして説明するけど、要は仮想呼び出しされるのがメソッドで、
関数はそれができない、でいいんじゃないのか？
>>102 関数がどうとかどうでもいいけど、
汎化したらスーパーセットじゃねーの？
>>102 クラスの中にある関数がメソッド
グローバルな領域にある関数との違いはクラスの中にあるかないかの違い
と言いたいの？ｗｗｗｗｗｗ
107 ：
仕様書無しさん：2010/07/14(水) 13:41:32
age
>>104 仮想的に呼び出されるなんて言い回しは初めて聞いたけど。
>>105 Super Class(既定クラス)の継承したものがSub Class(派生クラス)であり
汎化は基底クラスから派生クラスを継承を表すもので。派生クラスは基底クラスを
汎化したものでサブセットではないのだろうか？
これは認識が誤っているかもしれないので、その場合は訂正していただきたい。
>>106 メソッドはC言語の関数と
>>85の点で同じ機能・特性があるため
関数を汎化した概念だと言っている。
クラスの中にあるかないかの違いとは言っていない。
それでは、メソッドが関数と比べてクラスに属するという事以外の違いを説明してくれ。
×クラスの中にあるかないかの違いとは言っていない。
○クラスの中にあるかないかの違いとは言っていなく、
クラスに属するかの違いと言っている。
スーパークラスのメンバがサブセットで、派生クラスのメンバがスパーセット？？？
全ての訂正
×派生クラスは基底クラスを汎化したもの
○派生クラスは基底クラスを特化したもの
×スーパークラスのメンバがサブセットで、派生クラスのメンバがスパーセット
○スーパークラスのメンバがスパーセットで、派生クラスのメンバがサブセット
>>108 >ソッドが関数と比べてクラスに属するという事以外の違いを説明してくれ。
class hogehoge
{
private $_name;
function __construct($name)
{
$this->_name = $name;
}
public function zikosyoukai()
{
echo "私の名前は " . $this->_name . " です";
}
}
class hogehoge2
{
public function zikosyoukai($name)
{
echo "私の名前は " . $name . " です";
}
}
全然違うよね？？
113 ：
仕様書無しさん：2010/07/14(水) 15:20:44
>>112 何が言いたいのかよく分からん。
クラスhogehogeではメンバ変数があり、hogehoge2ではメンバ変数がなく
hogehoge2クラスのインスタンスを生成してから、変数を引数で指定しなければ
ならない、程度の違いしか見い出せない。
もしかして、hogehoge2クラスのメソッドは、メンバ変数を操作しないとでも
いいたいの、それで、私の2つの条件が満たされないとか。
重箱の隅をつつきすぎのような…
自己紹介してもらうのになんで名前を指定してあげないといけないんだよ！！！！！！！！！！！！
116 ：
仕様書無しさん：2010/07/14(水) 19:27:43
逃げたのか
>>114 ちょっとその君が分かってるところの
関数とメソッドのそれぞれの概念を書いてみてよ。
>>117 概念ということになるとどちらも、データの操作を行う事と
他の関数、メソッド、ライブラリを利用する事と考えれば
差はないのではないかと。
はじめてオブジェクト指向でプログラム作ったときは
まさにアンチパターンのオンパレード
こんなことなら手続き型で作ったほうがよっぽどすっきりしてシンプルだった
でも上手く使いこなせるようになると生産性・保守性・拡張性が高く
かつ美しいプログラムを作れるようになる
>>120 ならないよ
オブジェクト指向の何の要素でそんなことになるって言ってるの？
>>121 リファレンスをプロパティで持つか
サブクラスとするか
多重継承するか
すっごく迷う私に助けをください
>>121 え？ならないの？
だったらオブジェクト指向でプログラム開発する理由はなに？
どんな利点があるの？
>>74 >オブだけでジムやボールを作れても、オブだけを極めてもガンダムは作れない
一年以上前の発言にレスするね。
ガンダムを一つ作ったなら、オブでガンダムがいくらでも作れるだろ。
>>123 ないよ
この業界、腐りまくってるからセミナーで儲けたいクズどもが
とにかく出てくるもの出てくるものなんでも大絶賛して
まったく無価値なものをやたらと高価そうに魅せるから注意な
オブジェクト指向で開発する意味？
俺が聞きたいよｗ
クズどもに騙されてるような奴は自分が騙されたことにすら気がつかないマヌケだから救いようがない
頭のいい奴はオブジェクト指向で書いたソースと
そうでないものとで比べてさっさと結論付けてオブジェクト指向なんてゴミ箱に捨ててるｗ
>>125 自分はjavaから入ったから
cのようなソースを読んでると見難くてだめなんだが
javaをそこそこ長く使っているが、オブジェクト指向のメリットは、コピペじゃなく、
継承による差分コーディングと、継承による実装範囲の制限くらいじゃないかな。
ある程度機能をメソッド単位で分割してあると、適当なメソッドだけ書き換えてとか
できる。 まあ、privateのプロパティでgetterがなくて結局コピペコードになる場合も
多々あるけど。 アスペクト志向ってのはこの差分コーディングを推し進めた
感じかなぁと。
後者はweb系でよくある、フレームワークの部分に普通の人は触らせずに、
ビジネスロジックだけ書かして、ダメコードの被害を最低限そのビジネスロジック
一つに押さえ込むっていう方法。
拡張性やら保守性なんてものは方法論云々じゃなくて、結局のところ適度な
リファレンス、適度なコメント、そして何より必要なのはその手法に習熟してる
って事だと思うな。 ダメなコードはオブジェクト指向だろうが、手続き型だろうが
何をしようとしてもダメ。
>>127 >継承による差分コーディングと、継承による実装範囲の制限くらいじゃないかな
出だしからレベルが低すぎて話にならない
こんなのそんなに時間とるか？と聞きたい
そもそもソフト開発において実装という作業工程にそんなに時間がかかるか？と
全体をよく見てからもう一度発言したらいいと思う
>>128 レベル低くてすいません＾＾ レベルが高い貴方はどういう所で時間を使ってるか
教えていただけませんか？ ＾＾
＞そもそもソフト開発において実装という作業工程にそんなに時間がかかるか？と
テストとその不具合の修正、機能追加による修正が私の場合は多いですね。
いかに他に影響なくデグレを起こすことなく、なるべく早くということが求められます。
あとは実際にコードを書くより、どう書くか考えている時間の方が多いですけどね。
>>127 > 継承による差分コーディングと、継承による実装範囲の制限くらいじゃないかな。
こんなのOOPのメリットに上げたら、アンチOOP厨の的だろｗ
ネットのないころに既存のソースとか限られた本見て自己流でOOPしているとこんな感じになったな
アンチOOPはOOPの出始めからいるので、OOPのFAQ的な弱点を知り尽くしていると思われたし。
アンチすることが趣味なのはおいておいて、
こんなスレで下手に「OOPはこんなもんだ、こんなメリットが」と言われると、
闇金が債務者をカタにハメるかのごとく、テンプレ通りの反論が返ってくるのだよ？
それじゃそのカタにはまったテンプレ通りの反論を見せてみ？
>>129 >テストとその不具合の修正、機能追加による修正が私の場合は多いですね
（仕事したことあるのかな？この人・・・）
またもや自作自演が始まったか
そもそもオブジェクト指向の達人は
オブジェクト指向の思考をして設計してます。
そしてコーディングをプログラマーに指示
１．プログラマー何こいつ言ってるの？？わけわからん設計と思いながら
２．書かれた通りにコーディングを進める
３．わけわからん設計と思っていた自分が恥ずかしくなる
４．そういう事かぁ～ってつぶやく
５．ネ申 の存在に気が付く
以上
オブジェクト指向が分かると世界が面白くなるけどすぐにつまらなくなる
楽しいのは本当に一瞬
137 ：
仕様書無しさん：2010/07/17(土) 22:08:48
それは分かったつもりになっただけの馬鹿
そんなに顔を赤くするなよ
無能を受け入れるのも勇気だ
規模の小さなシステムではオブジェクト指向なんぞ
何の意味もない
オブジェクトって、システム自体じゃなくて、テスト用のツールを作るためにある。
コードがオブジェクトだからメンテナンス性がいいというのは実はあまり関係なくて、
典型的な例が、機械を動かすシーケンサで、これはアナログ／デジタル回路のキ
メラなので、構造化すらできなくてスパゲッティ化しやすい。これをデバッグするた
めに機械をつないで動かしていたら破産してしまうので、機械そのものをシミュレー
トするオブジェクトシステムを代わりにつないでやれればそれに越したことはなく、
機械そのものの値段と比較すれば、ある程度の予算をかけてオブジェクトデバッ
グシステムを組むことができる。コード自体がスパゲッティでも既に運用されてい
る場合、書き直すよりはデバッグシステムを作ってしまった方がおそらく早い。
大丈夫。このスレの大半は彼がオブジェクトシステムって口走ってるとこで
オブジェクト指向を理解して無いんだなってことぐらい把握できてるよ。
143 ：
仕様書無しさん：2010/07/19(月) 04:26:21
オブジェクト指向もわからない人がプログラマーになれるの？ｗｗｗ ぷぷぷ
デザインパターンとUMLを解さない奴にオブジェクト指向は無用の長物
むしろそんな輩は邪魔になるから手を出さないでくれ
>>144 オブジェクト指向を理解していたらデザインパターンなんて使うタイミングないはず
オブジェクト指向は現実モデルを設計に当てはめる設計手法で
デザパタは金型プログラミングなので手法同士がぶつかり合って互いに邪魔になる
なんのつもりでオブジェクト指向語ってるのか知らないけど
お前みたいなにわかが一番邪魔なんじゃないだろか？
146 ：
仕様書無しさん：2010/07/19(月) 17:45:18
デザインパターンって、早い話が普通の仕事で言うルーチンワークの業務手順
みたいなもんだろ？
何でもいいけど、UMLで書けば漏れなく仕様が決まるとか勘違いしている
馬鹿大杉。
> オブジェクト指向を理解していたらデザインパターンなんて使うタイミングないはず
普通に使っているだろｗ
いや、お前もだよ。
148 ：
仕様書無しさん：2010/07/19(月) 18:09:49
「デザインパターン」とか「MISRAC」とか、昔からごく普通にあるコーディング
手法にもっともらしい名前を付けることで、あたかも自分が考えたとか、新しい
技術であるかのように錯覚させているものって多いよなぁ。
竹島に、独島と名前を付けて領有権を主張するようなものか？
149 ：
仕様書無しさん：2010/07/19(月) 18:13:20
デザパタ理解してテンプレート理解してＣ＋＋使うと最強
>>148 そうそう。そもそもがオブジェクト指向なんてマルチメソッドの特殊例でしかない。
>>148 それ、デザインパターンの本の冒頭に、
自分で考えたものではなく、名前をつけたものであるって
ちゃんと書いてあるからｗ
お前はデザパタ本の冒頭レベルに過ぎない・・・
152 ：
仕様書無しさん：2010/07/19(月) 19:07:52
>>151 だから、とにかく新しい技術というネタや切り口を持ち出すことで、本を買わ
せたい出版社やライターの思惑があるだけで、立ち読みで冒頭を確認すれば
十分、わざわざ本にして出すような有意義な中身なんてもももとないってことだ。
デザパタ本を読むぐらいなら、Smalltalk-80のソースを読め、と言いたい。
>>152 じゃあ、お前はどんな本なら有意義だと思うんだ？
誰も知らないことを書いている本なら有意義かな。
誰も知らない＝俺も知らないだからね。
誰かが知っていることは、俺も知っていることなので
価値はない。
誰も知らない = 著者も書いてあることを知らない。そんな本は著者がいないのでありえない。証明終
157 ：
仕様書無しさん：2010/07/19(月) 19:22:36
>>154 最近は、買うに値するような本はないね。昔は買っていたリファレンス本みたい
なものさえネットで無料で手に入るし、本は内容がアップデートされないから、
古くなると使えない。
電子書籍で流通したとしても、いまさらソフトウェア関係で買いたいと思う
ような本なんて思い当たらないなぁ。
英文の文書だってGoogle翻訳で必要な箇所だけ訳して必要ならワードなりの
文書に貼り付けてPDF化。わざわざインプレスあたりの本を買うまでもない。
>>157 誰もお前個人の感想なんて聞いてねーんだよ
159 ：
仕様書無しさん：2010/07/19(月) 19:27:18
>>158 の書き込みみたいな、内容がない本ばかりだから、買う価値がない。
なのに、出版社は
>>158 の書き込みのように、毎月決まった冊数の新刊本を
出してくるのだな。
ふぅｗ
内容が無いと
自分にとっては必要が無い本の
区別がつけられないんだね。
こういう人は・・・ちょっとうちには要らないｗ
161 ：
仕様書無しさん：2010/07/19(月) 19:41:03
うちってどこの特定派遣業の方？(w
内容がない本 ∪ 自分にとっては必要が無い本
内容がない本 ∩ 自分にとっては必要が無い本
内容がない本 ⊆ 自分にとっては必要が無い本
内容がない本 ⊂ 自分にとっては必要が無い本
内容がない本 ⊇ 自分にとっては必要が無い本
内容がない本 ⊃ 自分にとっては必要が無い本
という集合がいずれも成立しうることさえ理解できんのかな？
まぁ、全角英数字使ってる時点でお里が知れるけど。
オナニー本を自費出版するのは勝手だが、頼むから、間違っても設計とか
実務には関わらんでくれ。
>誰かが知っていることは、俺も知っていること
実際云々以前に、この姿勢が技術者として終わっとる
163 ：
仕様書無しさん：2010/07/19(月) 19:52:55
売る側が買わせたい本と、買う側が欲しいと思う本との乖離かな。
IT業界のブラックぶりが広く知れ渡るようになり、わざわざ高い金払って
ITドカタを目指す若者も少なくなって道理。
>>153 Smalltalk-80のソースでどんなことが学べるの？
>>164 読破して、それをまとめると
本に書いてあることが理解できる。
ま、時間がかかるだけさｗ
デザインパターンは暗黙知を形式知にしたことに意味があるんでしょ。
ノウハウに名前が付くことによって、そのノウハウを共有し易くなった。
想像知を形式知にしたという側面もあるな。
これは考えなくてもいいというメリットの反面、
考える力を失わせるデメリットともなった。
>>165 上の人の言い方で言わせれば、
オナニー本の内容が理解できて何が楽しいの？
目的と手段が逆になってない？
上の人の例えで翻訳してみればいい
>>153＝オナニー解説本を読むぐらいなら、オナニーを楽しめ、と言いたい。
>>154＝オナニーでどんなことが学べるの？
>>165＝出し尽くすまでオナニーして、それをまとめると
オナニー解説本に書いてあることが理解できる。
ま、時間がかかるだけさｗ
>>164＝オナニーでどんなことが学べるの？
だったわ
>>147 ないって
デザパタみたら書いてる奴がオブジェクト指向理解してないのまるわかりだろ？
なんだよシングルトン（笑）ってｗ
シングルトンて、デザインパターンなのか？
オナニー本で学べることは何も無いよ。
ただ、オナニー本かどうかを
見抜くことは馬鹿にはできないよｗ
意味の分からない発言をして、一人で笑ってる人ほど、不気味なものはないよな
>>171 デザパタってOOPL向けプログラム詳細設計クックブックじゃねーの？
設計から実装へのシームレスさにとらわれ過ぎてないか？
まぁ俺解釈だけど、クラス設計の終わり辺りで小細工入れとくと、
後々機能追加とか、変更入った時に助かるかもよ、
っつーレベルのモンだろ。
で、変更が入ったとき、変更が想定外だったらしく、
小細工自体を考え直さなくなるってのを良く見るんだけどな。
まあ、そのお陰で高いギャラ貰えたけど。
あり難い話ですわｗ
日本語が変なのも日本人なら分かるかなって思ったけど、
違う意味に読めるので一応訂正するか
×小細工自体を考え直さなくなる
○小細工自体を考え直さなきゃならなくなる
>>175 いや、明らかに意味ないし
オブジェクト指向の設計思想とあまりにもかけ離れすぎてるだろ
カタログでいいならなんのためにシミュレーションからそんな大層なもんもってきたんだよ
それにカタログならわざわざオブジェクト指向じゃなくても
Ｃ言語の成功パターンかき集めたほうがよっぽどいいと思うんだけどな
あれ、なにかオブジェクト指向でやらなきゃいけない何かがあったんだろか？
どの辺がかけはなれてんだ？
Ｃ言語の成功パターンって？
必死に探した成功例がシングルトンの人間の集まりに無茶言うな
実装の都合で構築したクラス構造を、第三者に説明するときに、
パターンの名称を使えば説明が楽な場合があるので、
使うことはあるっちゃあるが、
設計段階でパターンに嵌めてデザインするなんてことは、
まずないな。
>>182 あんなおかしな構造にすることがあるなんてそれだけで意味不明だけどな
単純に仕様どおりにクラス作れよって思うわ
実装都合の余計な中間クラスなんて入れるだけ素人まるだしって気がついたら中級者
>>183 機能設計に縛られて過ぎてプログラム設計に
幅を持たせられないお前が三流なだけ。
>>184 余計なクラスを作ることを「技」だと勘違いしちゃってるなお前
中途半端な奴って
自分が理解できないことを、無駄なものって思うよなｗ
で成長してやっと、あの設計はこういうことだったのか！って
理解できるようになる。
生暖かく見てようぜｗ
業務よりのロジックにパターンを使ってるようなところは、たまに見かけるな。
ああいうのは確かに余計なクラスとは言えるだろう。
大体に於いて、業務変更に対応できずに、パターンごと再設計を強いられる。
実装の、より業務から離れた部分で使用するなら問題ない。
フレームワークなどは、パターンを上手く駆使すれば、
業務ロジックの負担を減らすことが出来、パターンが有効な最たる例だろう。
といっても、上手く作れば作るほど、内部で使われているパターンは、
外部作業者からどんどん見えなくなっていくだろうけど。
そして、外部作業者が作成するクラスは、全部業務よりのクラスだから、
パターンレス。
あと、設計の段階で意識してるところも、たまに見かけるな。
それこそ余計な設計だろう。
日本人の気質なのか、より細かに指示してる方が親切だろうと考えガチだが、
これも、業務よりのクラスをパターン化してしまう、デメリットの多い例。
というか、それ以前に、設計は実装とは切り離して考えるべきだという、
基本中の基本を理解出来ていないレベル。
余計な設計というより、有難迷惑設計というべきか。
>>186 じゃあ、具体的に何がいいのか説明してみせろよ
これがあるかないかで俺は判断してるけどこれがまったくないから役に立たないって俺は言ってるの
189 ：
仕様書無しさん：2010/07/22(木) 20:26:18
>>188 んじゃ分かりやすいところでState。
利点は状態の追加が楽。
例えば顧客要望による仕様変更とか。
>>192 そんなの頼んでないじゃん
しかも、それって想定内の変更しかキャパないよね？
>>188 > じゃあ、具体的に何がいいのか説明してみせろよ
フレームワーク使ってない？
フレームワークではかなりの部分で
デザインパターン使われてるよ。
>>194 関係ないよね？
いま、話してる内容は作り方の話であってできたもんがどうのこうのって話じゃないよね？
理解できてる？
つまり、この板には、フレームワークの設計に関れるレベルに達してる人は居ないってことかなｗ
デザインパターンの話が流行らない訳だわ。
>>195 フレームワークはできたものじゃなくて
使うものだよ。
なにいってるの？
へー…フレームワークって、設計しないんだね…
>>193 さっぱり分からん。
誰が何を頼んでないの？
何がどう「キャパない」の？
アイデア特許って白人が考えたんだぜ
アイデア特許ってなんだ？
ビジネスモデル特許のことを言おうとしてる？
>>199 は？そしたらフレームワークに使われてるってのはお前の自作の話かよ
くっだらねーｗ
さすが三流。
ケチは付けるが反論は出来ないその一貫した姿に感動を覚えた。
>>204 そもそもこんな話になる前にはじめに明確なメリットが出てこないのはどういうことだろうね？
Stateがそれ？
でもStateがいいかどうかなんてぶっちゃけ説明できないし
これが開発にとっていいのか悪いのかなんて説明できないんでしょ？
仮に今後全く追加や拡張がおこなわれないとしたときに
この記述は無駄に長くてわかりにくいだけなんでしょ？
さらにこんな頑張ったところでやはり実装箇所の予算なんて開発全体からしたら
あまりにも安すぎて力を入れるべき部分ではない
ＰＧなんて派遣しかいないのにこんな保守コストなんて重要にならねーよｗ
そういっても自分のコードを動かすために使っている
フレームワークのソース見ればたくさん使ってあるしな。
ソフト作るのにすべてが自分の力で作ったとか思ってないよね？
自分が作ったソフトはデザインパターンのお世話になってるんだよ。
>>206 言うだけムダ。
205はコード書けないＳ∃だろ。
実装しない奴に「実装の役に立つ」っても、
理解出来る訳がない。
おいらフレームワークと汎用コンポーネントばっかり
作ってたのでデザパタはよく使うよ
で、業務でもOOの人はいないの？
単なるオナニーだが
ドメイン駆動で全部設計した事ある。業務を抽象化、汎化しまくった
結論的にすごく綺麗だけど、誰もメンテできないと思う
諸事情で抜けたので、保守はどうしてるのだろうか・・・・
難しい技術を使ってメンテできないシステムにはうちにもあるわ。
構造体とか使うなって言ってるのに。
業務の構造に対して、設計の構造が理に適っているなら、
業務が分かる人間には理解できるものになっていなければならないはず。
そうでないというのなら、設計ミスだ。
>>208 えとな、スキル足りなくてメンテできないのは
技術の否定にはなってないからな。
俺なんて車運転できないから誰もメンテも保守もしていない。
構造体が難しい・・・？
いいから、Smalltalk-80のソースを一通り読め。話はそれからだ。
214 ：
仕様書無しさん：2010/07/24(土) 06:53:03
構造体難しいよな
あとポインタの使われると何が何だかさっぱりになる
うちはいつも変数だけまとめたCファイルつくってexternでアクセスしているからメンテが楽ちんだ
変数のスコープとか、アクセス制御とかもう完全に無視だなｗ
まぁそれで業務が回ってるなら、それはそれでいいんだろう。
しかし、構造体の難しさってパディングくらいなもんだろ。
それも一旦理解したら、別にどうってことないだろうし、
そもそも構造体が難しいって言ってる人が、パディングを意識しなきゃいけないコードは書かないと思うけどな。。。
>>206 その説明が役に立つ説明として適切なの？
とりあえずそれ使って組んだものがある＝役に立つとしか君はいってないけど？
こんな脳みそでよくプログラム組めるよね君
>>215 たぶん、
>>214が難しいと思っているのは構造体そのものじゃなくて
構造体とポインタの組み合わせだ。
218 ：
仕様書無しさん：2010/07/24(土) 10:28:00
構造体もオブジェクト指向もいっしょだろ。簡単すぎてあくびが出るぜｗ
構造体どころが、構造化プログラミングがかなり難しいと思う
初心者のころ、初学は構造化言語からはいったけど、
行指向プログラミング言語ソースの方が当時はかなりわかりやすかった。
関数のように上から読みにくい概念が特に難しい
「構造化プログラミングの達人ってどんだけすごいの？」スレがほしい
今でこそメタプログラミングで動的なメソッド定義とその呼び出しとか追えるけど
GUIのデバッガーがあっても、よそうできない場所にポンポンとんだりするからきつい
構文解析とか意味解析の時点で定義されていないメソッドのデバッグとかとても面倒
ポリモーフィズムもインスタンスで呼ばれるメソッド変わるし、
メタプログラミングで外部のデータからオブジェクトのメソッドを動的に定義されていたり、
挙句のあてメソッド呼び出しに失敗した時にフックして
メソッド名で振り分けて別のメソッド読んでたり、
意図しないメソッド呼び出しに面食らうし、
既存のオブジェクトのメソッドが、別のメソッドにいつのまにか置き換えられていたり、
大変じゃないか？
こういう最近の流れである抽象化的な手法はどんどん書きやすくはなるが、
コードが読みにくくなるし、デバッグがしんどくなる
抽象化することでコード量も減らせるが、
テストももりもり書かなくちゃならない
オブジェクト指向言語とそれにプラスアルファな言語はかなりしんどい
>>219-220 で何がいいたいかというと、
このスレみたいなのっていつの時代も需要あるんだなと
常に新しい概念が生まれて、それが当たり前に身についていない技術者がグダグダいう
言語使い始めから当たり前に使っている技術者にはすごさもわからないし、
当たり前じゃない技術者の気持ちもわからないものだ
「メタプログラミングの達人ってどんだけ凄いの？」スレ
とかもっと汎用的に
「抽象化の達人ってどんだけ凄いの？」スレ
とか欲しい
>>220 激しく同意
デバッグが難しい
汎用性とかいらない
っていうか追加の仕方も追加の仕組みのせいでさらに困難になってるときのが多い
悪いけど追加要素お前の想定はるかに超えてっからこの仕組み邪魔なだけだわ的な
223 ：
仕様書無しさん：2010/07/24(土) 13:39:20
抽象化とメタプログラミングで作ると
上から読んでも追えないな、
メソッド飛びまくり、しかも全部インターフェース
実装を決定してるのは遙か上のメソッド、またはメタ定義
実装見つけてもメソッドのコードは数行ときて・・・以下繰り返し
最近は関数型でのメソッドチェーンも流行だし、
1行で何個の呼び出し発生してんだよ的にｗｗｗ
まぁ～作っている時は、蜘蛛の巣のようにメソッド呼びまくりなので爽快
「インターフェースの達人ってどんだけ凄いの？」スレ
「メタプログラミングの達人ってどんだけ凄いの？」スレ
「メソッドチェーンの達人ってどんだけ凄いの？」スレ
も必要なオカン
とりあえず「抽象化プログラミングのスレ」がほしいわ
あと「ジェネリックスの達人ってどんだけ凄いの？」とか
抽象化と言うより汎化かな・・・
まぁ～動的言語は関係無いけど
動的限度といえばインターフェースと言うよりダッグタイピングなので
さらに抽象度がカオスｗｗｗｗ
プラグインを作ろうとか
プラグインの仕組みを取り入れようとかすると
デザインパターン使うよね。
デザインパターン嫌いな人に、
じゃあお前がこの部分の設計書かけよな。
って言って仕事やらせたら、
「ファクトリメソッドパターン」の一言ですむところを
ポインタがどーのこーの継承がのーどのこーのって長ったらしい説明を書いてた。
でできたあと、これ要するにファクトリメソッドパターンですよね？って
言ったら理解できない顔をしていたのが笑えたｗ
それはデザパタスレ向きｗ
悪いここであってたわ
ココはデザパタスレじゃないですｗ
>>223 それは設計書書いてないのが悪いんじゃ？
実装が複雑になるのは否定しないけど。
それ以前に、クラス構造は関係なく、ソースを追わなければ
何をやっているところか？
何がどうなることを目的としているところか？
が分からない状態になってるところが駄目なんだよ。
追わなきゃどうなってるのか分からない状態を
まず何とかすることを目標にすべき。、
平べったく広げてソースを読みやすくしようなどと考えるのは、
スパゲッティー屋さんの発想でしかない。
>>232 追ってどうにかなった昔のが質がいいと思うけどな
そもそも仕様書があてになんねーところは今も昔も変わらねーし
234 ：
仕様書無しさん：2010/07/24(土) 17:41:37
読みやすいソースは
スパゲティとは言わないのでは
俺もどうにかしようとする昔のほうがいいと思う
関数ないからできませんとか言う人今は多いけど
なんとかするのが仕事だろって言いたくなる
>>235 規模なんてちっともでかくなってないよ
単に流行りの組み方が糞なだけ
別にオブジェクト指向が仕様を減らしてくれるわけじゃない
>>232 > それ以前に、クラス構造は関係なく、ソースを追わなければ
> 何をやっているところか？
> 何がどうなることを目的としているところか？
> が分からない状態になってるところが駄目なんだよ。
でも、どうしても複雑なところってのは出てくる。
そういうところを「○○パターン」といえば
それだけで、何をやっているか、何が目的かってのが
一瞬でわかるのがデザインパターンというもの。
238 ：
仕様書無しさん：2010/07/24(土) 18:07:22
>>232 バグ探し＋修正は追わないと
どうしようもなくね？？？
設計書に単体バグは書いてないでしょ普通
○○パターンでバグまでとれて修正変更追加までやってくれるわけじゃないしなｗ
当たり前だｗ
少しでも体にいい物を薦めると
不老不死になれるのかよって言う奴どうにかしてくれ。
不老不死になれなくても、体にいいことは確かだろ。
>>240 いや、それすらわからない
本当に体にいいのかどうなのかそれすら説明できない
>>241 酒みたいなもんだ。
適量なら体に良い。
ダメな人も居る。
飲めない人に美味しさは分からない。
不老不死にならないのなら
薬は要らないといっていた奴が
風邪で死んだ。
245 ：
仕様書無しさん：2010/07/24(土) 22:58:11
やばこもな
好きなだけ疑いたまえ。
効果には個人差があります。
よくある話だ。
デジドカにXP教えてみた。
子供にライターを渡しちゃダメだとわかった。
この話題だすと結局こんな流れになって毎回ちゃんとしたメリットを出せないよね？ｗ
数字でいくらお金になるのかいってごらんなさいなｗ
まず先にお前が言えよｗ
>>249 具体的な案件の提示もなしで金額出せとか、どこの専門学校生よ？
バグなんて、コードがちゃんと機能単位になっていれば、
単体テスト通すだけで終わる話。
というか、バグの原因に関らず、本来テストすべきケースから
抜けていただけということになるはず。
で、UTが自動化されていれば、改修など一瞬で終わる話。
ソースを追っかけるとか、化石のようなことやってりゃ、
そりゃ徹夜スパイラルは止まらねえよ。
テスト万能信者が来ましたか。
理論上あり得る全ての実行パスをテストで検証することが可能だと思っていますか？
たかがC0テストで全てのバグを検出できるなんていう楽観的な妄想はどこから湧いてきましたか？
誰がすべてのバグの検出が可能とかいったんだ？
「テストすべきケースから抜けていただけ」という言葉から
そういう事態、つまりバグが検出できてない事例がありえる
ということは明らかじゃないか。
問題はその後だろ。見つかったとそれを直すのが
すごく簡単な話になるというのがユニットテストの効用だ。
>ソースを追っかけるとか
DDDとかで設計した場合、細かい大量のクラスができ
機能単位ではなく業務エンティティ単位で設計されるわけで
ドメイン貧血を回避するとUnitだけじゃバグは見つける事できないわけ
あとさ、この業界と言うか日本の場合
SI企業が牛耳っているから、終わったらチーム離散して誰も残らないのよ
XPの場合ソースとテストケースが資料の一部なんだよね
と言うか、全く役に立たないSﾖが書いた
日本語が変な納品物資料を
読むよりテストケースとソース追っかける方が楽
だから、誰もユニットテストだけで
全部のバグを見つけることが可能って
言ってないってばｗ
なんでユニットテストを理解できないんだ？
仕様が変わらなければな。
>>254 馬鹿だなあ。
その「テストすべきケース」を列挙すること自体が不可能だって言ってんの。
実行不可能なことを前提にしてテスト万能論かよ。ある意味、テスト屋にとって最大の障害だ。
> その「テストすべきケース」を列挙すること自体が不可能だって言ってんの。
可能だよ。
お前が言っているのは、「”全部の”テストすべきケースを列挙することが不可能」だろ。
それとも一つもテストすべきケースを列挙できないと
言うつもりか？
>>256 単機能のバグですら、ユニットテストだけじゃ検出できねえ場合があるんだよ。
そんなことも弁えないでユニットテストやってるんじゃ、逆効果だな。
>>260 ユニットテストだけじゃ検出できないから
なんだっていうんだろうか？
じゃあ何を使えば、それだけで全部検出できる？
そんなもの無いだろうが。
>>259 ヴァーカ、「列挙」って言葉の意味もわからんのかよ。
おまえ、テストについてちゃんと系統的な教育受けてるか？
適当にブログ読み漁って、勝手にユニットテスト万能論とか受信しちゃったんじゃね？
ほんと、ユニットテストの限界も知らずにユニットテスト推進されることこそ
ユニットテスト普及の最大の障害だということに気付いてくれないかなあ。
>>261 ユニットテストという道具は万能じゃないことを承知した上で使えって言ってんの。
>>252みたいな幼稚な考えでユニットテスト使ってると怪我するぞ！？
>>263 万能じゃないから、
「本来テストすべきケースから抜けていた」ことが
発生したと書いてあるじゃないか。
お前だけだよ。ユニットテストが万能と思っちゃったのは。
>>264 列べて挙げること。そんなことも知らずにレスしてたの？馬鹿？キチガイ？死ぬの？
>>265 本来テストすべきケースが無限にあるって言ってんだよカス人間
>>267 だから、無限にあって全部を列挙することは不可能だってわかってる。
それでお前はこの結論から何が言いたいんだよ。
すべてのテストは完璧じゃないってか。
当たり前だよ。そんなの知ってるよ。
なんでお前は知らないと思っちゃったの？
>252が極論出したからじゃないのか。
（見つかった）バグは単体テスト通すだけで終わるというのは間違いじゃない。
見つかったバグの話なのに、単体テストでバグがすべて見つかるわけじゃないという話をしだした馬鹿が悪い。
順番を間違っている。
ユニットがちゃんと整理された機能ならば、
テストケースも少なくて済むんだよ。
複雑な機能がゴチャゴチャに入ってるから、
全部のケースを網羅できなくて、テストに漏れが出てくる。
言い過ぎ。
設計からバグってたら単体テストじゃ分からんよ。
あと、ソースがゴチャゴチャだと、インテグレーションテストで矛盾が生じた場合に、
論理的に間違っている部分を特定できないという問題がある。
（というか、そもそも論理的構造になっていないからだがｗ）
結局、さらに他の部分のソースを読み進めながら、どう直したら他の部分のやってることと
整合性が取れるのか？ということを探しながら直すという作業になる（解があればいいけどね）
それだけならまだ救いがあるが、直した結果がさらに論理的な矛盾を抱える可能性すらある。
（なんせ構造が論理に従っていないのだから当然だ）
まあ、そういったパッチワークの積み重ねでしかソースを完成させられないからこそ、
そのようなソースが出来上がったとも言えるけどな。
>>272 なんで順番を間違える？
単体テストをしてバグを見つけるのではなく、
今話しているのは、バグが見つかってから後の話だろ。
結局、話は脱線してメリットは出てこない、と
ということにしたいのですね
いや、実際そうだから
>>270 単体テストで必要なケースを完全に列挙できない。
したがって、単体テストをすり抜けて、別の原因で発見されるバグは無くならない。
したがって、バグは単体テスト通すだけで終わる、という主張は間違っている。Q.E.D.
>>275 バグが見つかった後の解析の話なんだけど。
それでも順番が違うなら、バグ発見から
修正確認までの工程を全部書いてくれない？
単体テストは、多くのバグを発見して潰せるし、
後で発見されたバグを追跡する時のいい参考材料になるが、
単体テストさえやれば終わるということではない。
そんな考えで単体テストやっているのなら、
それはキチガイに刃物とでも言うべき状況だ。
だから誰が単体テストをやれば
すべてのバグが見つかるといっているんだろうか？
何度も指摘されているはずだが、頭悪いのかな？
どんなテストやったってすべてのバグは見つかるわけが無いのだから
特に単体テストに限って言うことでもないだろ。
この人。
>>252 > バグなんて、コードがちゃんと機能単位になっていれば、
> 単体テスト通すだけで終わる話。
> というか、バグの原因に関らず、本来テストすべきケースから
> 抜けていただけということになるはず。
> で、UTが自動化されていれば、改修など一瞬で終わる話。
見事に言ってるね、「単体テスト通すだけで終わる話」
さらに言ってるね、「バグの原因に関らず、本来テストすべきケースから抜けていただけ」
>>283 > で、UTが自動化されていれば、改修など一瞬で終わる話。
最後の行にコメントは無いのか？ｗ
その人はどう見ても、「単体テストをやればバグがすべて見つかる」
などとは言ってないが。
>>285 283じゃないけど、
> 最後の行にコメントは無いのか？ｗ
ないなぁ。
前提になっている前行が間違えてるからなぁ。
> バグの原因に関らず、本来テストすべきケースから
> 抜けていただけということになるはず。
現実に完璧なテストケースなどないけど、仮に出来たとしたら、
全てのバグが単体テストで見つかるんだろ？
例え完璧な単体テストが出来たとしても全てのバグは見つからない。
>>252にとってITやSTは、単体テストの項目漏れを
発見するためだけに行うものらしいようだ。
UT自動化すれば、ソース見なくて良いの？徹夜しなくて良いの？馬鹿なの？死ぬの？
>>285 > その人はどう見ても、「単体テストをやればバグがすべて見つかる」
> などとは言ってないが。
ふーん・・・
>>252 > バグなんて、コードがちゃんと機能単位になっていれば、
> 単体テスト通すだけで終わる話。
エラーが出ていて、バグが見つからないのに、終わるのか？
どこまで馬鹿なんだよw
>>286 > 現実に完璧なテストケースなどないけど、仮に出来たとしたら、
> 全てのバグが単体テストで見つかるんだろ？
だから、誰がすべてのバグが単体テストで見つかるなんていってるんだよｗ
頭悪いのか？ｗｗｗ
>>288 > エラーが出ていて、バグが見つからないのに、終わるのか？
あ、おまえさ。
「終わる」の意味をすべてのバグを無くせるという意味だって
勘違いしてるだろ？
あー、それは馬鹿すぎだｗ
>>283 同意
言ってるよね
いまさら違う意味でしたとかシケタいいわけしないでって感じ
>>290 では、「終わる」ってのはどういう意味なのか、ちゃんと説明してもらおう。
エラーが出ていて、バグが発見されなくても、「単体テストで終わる」んだろ？ww
>292
普通に、見つかったバグの改修の話だろ・・・
そういう言い方をするってのは、
やっぱり「終わる」をバグがまったく無くなるという意味だと
勘違いしていたわけね。納得。話にならんわｗ
>>294 で、見つかったバグを単体テストにかけると、「終わる」のか？
ソフトウェア工学での常識では、
単体テストの目的はまず第一にエラーの検出であり、
次にエラーからバグを特定するための判断材料であり、
さらに、修正されたコードが他の機能項目について劣化していないかの確認なのだが。
バグが特定されれば単体テストで「終わる」なんてことはナンセンス以外の何物でもない。
>>294 え、「終わる」って言葉の意味は「改修」なのか？
あまりにも馬鹿。馬鹿すぎる。馬鹿すぎて面白い。面白すぎる。
ぜひ次回作も頑張ってくれたまえ。期待しているよ。
>>295 さすがにそれは頭が悪いとしか・・・。
テストにかければ（バグを修正しなくても）バグが直る。
さすがにそんなつもりで言っているわけが無いだろう。
常識で考えろや。
>>289 >>252は「あらゆる原因のバグは、単体テストで検出出来る」
という旨、発言してるけども。
>>298 検出って言葉は一つも入ってないのに？ｗ
>>299 だったら、さっさと「終わる」という言葉の意味を提示しろって。
馬鹿は馬鹿なりに、「私の認識が馬鹿でした」と認めろ馬鹿。
>>299 じゃあ、テストケースが抜けていただけ、とは
どう解釈すれば良いんだ？
俺は、テストケースが抜けていなければ検出出来ていた、
と解釈した。
>>299の解釈では、テストケースが抜けていなければ、
何がどうなるんだ？
>>297 このスレでは、おまえが一人だけ非常識なんだが。
はやく、
>>252の言う「終わる」の意味を示せよ。
馬鹿があがくのは、本当にみっともないぞ。
今のうちに自分の馬鹿さを認めろ。
>>301 テストケースが抜けていないって事はまず無いから。
>>303 テストケースが抜けているという前提で考えるとして、
バグが出たら単体テストで終わる、ってのはどういう意味ですか？
ソースコード全体をくまなく探して他に影響が出ているところが
無いか長時間調べまくる必要がなくて、作業がすぐに終わるということです。
↓このように書いてあるじゃないですか？
> ソースを追っかけるとか、化石のようなことやってりゃ、
> そりゃ徹夜スパイラルは止まらねえよ。
設計が完璧ならUTしっかりこなすだけで
バグ無しのもんが出来るけど
設計バグ無しって中々作れないからな
>>305 > ソースコード全体をくまなく探して他に影響が出ているところが
> 無いか長時間調べまくる必要がなくて、作業がすぐに終わるということです。
へー、リグレッション検査を単体テストで済ませちゃってるの？
それってかなり地雷だらけだと思うけど。
>>303 国語やりなおせ。
わざわざ「仮に」とまで書いてあるのに。
お前のために
>>286を言い直すと、
「バグの原因に関らず、本来テストすべきケースから
抜けていただけということ」にはならない、
と言っている。
>>305 バグフィクスで一番時間がかかるバグ解析についての
アプローチが全く含まれて無かったことにビックリだ。
影響範囲の調査で徹夜って、どんなマヌケの仕事だよ。
良い子の諸君！
バグステータスで
・バグ発見
・バグ確認
・バグ解析
・バグ修正
・バグ修正確認
などがあるが、テストドライバがあれば
1行たりとも、ソース追わなくて良いんだよ
オブジェクト指向の達人ってそれだけ凄いのだよ
僕のＩＣＥ返してください
オブジェクト指向で作って
自動テストできるようになれば
その通りだな
どっちが掛けてもそこに至れないが！
>>310 別に。
252の表現を仮定を交えて分かりやすく変えたつもりが
お前の理解力が存外低くて、かえって分かりづらくなってただけ。
だから308でわさわざ書き直したろ。
316 ：
仕様書無しさん：2010/07/25(日) 16:29:38
いろんなスレッドと同期取りながら動く処理のテストって大変だよね
要はそんな景気のいいこと言ってる奴は信用できねぇ、ってだけだわな。
ソース追わないでもソース直せちゃうんだ。
いっそテストドライバがあればバイナリをパッチできんじゃね？
コンパイラいらないかもｗ
>>313 ICEの数が足りないから、しばらく我慢汁
結論
>>252は自分の間違いを認めようともしない専門学校生。
いつまでやってんだよ。なんか必死すぎてワロタｗ
>>242 > 適量なら体に良い。
酒飲みの言い分だろｗ
若いうちは身をこにして働けとか、
苦労は金を出してでも買え
みたいな類だなｗ
>>246 客観的に納得出来る材料ないと、
「個人差があります」なんていっちゃたらおわるだろうが
萎えるんだが
ぐぐったらタバコ（ニコチン）も少量なら体にいいとか出てきたｗ
少量じゃわからん。どれくらいだ？
タバコ1本に含まれる量の100分の1ぐらいか？
少量っつったら３合だって書いてあった
327 ：
仕様書無しさん：2010/07/25(日) 22:15:06
弱電・強電・制御もわかる俺様に死角なし
>>323 > > 適量なら体に良い。
> 酒飲みの言い分だろｗ
そうでもないらしい。
ググったらいくらか出て来る。
でも疑わしいんだろうさ。
デザパタの効能だってググりゃいくらか出て来る。
それも疑わしいんだろ？
それ以上、何を求めてんのさ。
実体験を話してもどうせ、疑わしい、で終わるだけ。
>>328 誰も数値で表せないからな＞デザパタ
工数がいくつ削れて～って話になるとどうしても弱い
また、そんなにいいなら全体の工数（保守も含めて）を２分の１ぐらいにしてみせろよ
ってもんだけどそれもやっぱりやらないしなｗ
開発全てがデザパタだけで賄える訳じゃないからなぁ
どちらかと言うと初級者を中級者に引き上げるための
手引的に思った方がいい
あんまりデザパタだけで計測しないからねぇ。
リファクタリング時に適用して、循環複雑度のピークが
半分ぐらいになったのを1回見たぐらいで、
それでもデザパタだけのおかげかってと分からない。
コードの品質は上がったんだろうけど(複雑度は下がった)
工数的にどうかと言われると、どうなんだろうな。
まぁ客観的に結果だけ捉えると、デザパタの適用は、
「アホが作っても、コードの複雑度を下げる効果がある(かも知れない)」
か？
サンプル数1だけどな。
計測するも何も、同じものを作ることはほとんどないから計測しづらいんだよな。
>>332 だったら何を基準にしていいとか言ってるんだろうね？ｗ
>>333 ・現場がどれだけ楽になったか
・デスマにならないで終われたか
>>334 それはない
効率上げたら上げた分だけ納期も短くなるから
デスマになる現場はオブジェクト指向云々以前に
全てがぐちゃぐちゃ
設計×PG×PM×
納期より品質を優先しないと後々困ることになるから
見積もりから懸け離れた納期は設定しないよう交渉してるな
これからは、上手い設計で作業人数を減らしつつ納期を減らしてくる会社がどんどん出てくる(主に海外だろうけど）。
そういったところは、技術力を背景に、どんどんコスト勝負、納期勝負を挑んでくるよ。
従来通りの古い設計ノウハウなとこは、単に人を減らして稼働率を上げるしか、
どうしょうもなくなっているという背景があるんだ。
オブジェクト指向も上手い設計の手法の一つ。
逆に、見積もりやら納期以前にまず、オブジェクト指向など上手い設計が出来るかどうか次第なんだよ。
そうだな
オブジェクト思考・テスト駆動開発は大前提として
新しい設計ノウハウってのは何なんだ？
俺んなかでは
プロトタイプ開発が割と要望との擦り合わせで役にたったかな
日本の場合は、技術よりまず人だな。
古い設計ノウハウを抱きしめたまま、ガンとして譲ろうとしない奴ばかりだからだ。
こういうのを排除していけば、徐々にマシになっていくだろう。
んで？
従来の方法と比べてオブジェクト指向だとどのくらい工数減らせるの？
工数差は、要は再利用性の差だろう。
コボル方式は、機能の規模と工数が完全に比例するからな。
オブジェクト指向設計は、１業務機能に掛かる工数は逆に掛かっても、
２機能目で差を縮められ、３機能目はほぼ工数は掛からないものとなり、
４機能目以降はどんどん差が開いていくといった感じになるだろう。
２件目のプロジェクトとなると、実装部分は再利用可能だし、
（まあコレはコボル方式でも可能な部分は多いだろうが）
業務設計部分も同種業務なら理論的には再利用できるはず。
いや必ず出来る。出来なければ設計のセンスが無いだけの話。
>>340 別に減らないよ。銀の弾丸が無いの周知の事実
OOじゃ無いと設計ができない人間もいると言うだけ
手続き型で上から順に設計する事が難し過ぎて出来ないんだよ。
抽象化して整理しないと、巨大になって頭の中がまとまらないし、
作っていてバグだらけになる
うわ、こんなとこにもデスマラーが居たｗ
>>341 じゃあ、改修３回目には予算も人員も割り当てなくていいってことね？ｗ
＞OOじゃ無いと設計ができない人間もいる
ああ居るな。
設計能力的な話じゃなくて、毎日徹夜では体が持たないからとか、
体力的な話だけどな。
結局、見積もり時に工数が減らせねぇならそりゃ経営者にとってなんのメリットにもならねぇじゃん
>>毎日徹夜では体が持たない
MPとHPは別のステータスだから、
とりあえず宿屋に泊めれば良いと思うよ
>>メリット
考え方次第だけど、別にデメリットも無いよ
システム動けば同じだし
>>348 デメリットはあるじゃん
メタ臭いからデバッガで追えないし
手続き型で上から順に設計するのが好きな人は、
毎日徹夜でお祭り騒ぎが大好きな人たちだから、
単に、わざとそうやって作ってるんだよ。
誰だってそういうのあるだろ。学園祭が終わった時に感じる脱力感から、
暫く経つと準備期間とかのかテンション高い状態を体が求めてしまうとか。
ちがうよ
やっぱ、上から追えるって大事だよ
昔ながらのでもウィンドウズのメッセージとかわかんねーバグだとやっぱりとりずれーだろ？
>>メタ臭いからデバッガで追えないし
確かに追うの大変だね。メソッド飛びまくるし
実装が静的に確定してないし・・・
メソッドは小さいし、ソーズ全体の見通しが悪い
これじゃ、基本設計レベルを把握してないと
メンテできないよねたぶん
>>352 静的に確定してるもんまでわざわざ動的に組むとか汎用性のためとはいえイライラするよね？
仕様変更で想定してた汎用性がまったく役に立たなくなったときなんて
なんのために苦労してたのかとうんざりするな
設計が糞だから、毎日ソースを追うハメになっていることに気付かない訳ですな。
あ、わざと祭りにしてんだったっけ。すまんすまん。
そういえば、構造化設計でも以下の事は同じだったね
>メソッド飛びまくるし
>メソッドは小さいし、
>ソーズ全体の見通しが悪い
すんません
オブジェクト指向で工数が減るというよりか
技術力の差で工数が減るという感じだよな。
当たり前だけど、技術力が高いほうが工数は減る。
それでどうやって技術力を高めるかというと
それはいろんなプログラミング技法を知っているか
ということにつながる。
オブジェクト指向を知らなくても技術力が高い人はいるのかもしれないが、
まあそういうのは天才だ。普通はまずいない。
オブジェクト指向で工数が直接減るというよりも
技術力を高めた結果オブジェクト指向は当たり前に使える
オブジェクト指向使えない人は、技術力も低くて無駄なことばかりしてる。
というのが現実だろう。
＞オブジェクト指向を知らなくても技術力が高い人はいるのかも
技術力が高い人が何も考えずにスパゲティーにしちゃったソースほど、
後で読んでもどうしょうもなく分からないソースはないだろうなｗ
ある程度技術力を付けたＰＧを暴走させないため
そして業務理解者が分かる形での設計をさせるため、
のテクニックとして、オブジェクト指向は有効なのだと思えてきたｗ
>>357 モデル駆動型アーキテクチャだね
概念クラスを設計して、実装に落とすと・・・
自分は言語解るから、ボトムアップで設計の方が好み
>>355 同じだけど
オブジェクト指向だと汎用化のために静的で済むものを動的に作るでしょ？
これが糞
んで汎用化なんていったって大抵仕様変更きたら役に立たないでただ捨てるだけ
>>357 スパゲティにする時点で
それ技術力高くないからｗ
かわいそうだな・・・
そういう奴が技術力高いといわれている
会社に就職してるんだな。
> 適量なら体に良い。
酒売りたい側の理論に決まっとろうが・・・
>>359 静的、動的が何を指しているかわからない・・・
静的言語が動的言語の話ではないよなあ
最近は、動的言語は確かに流行ってるけど
>静的で済むものを動的
まぁ～オブジェクト指向に限らず、世間の流れが動的方向だからねぇ・・・
LL言語流行ってるし、世間的に生産性は動的の方が良いしね
でも静的言語はインターフェースの型があるだけ追いやすいと思うよ
AOPとかバイトコード変換とかバイナリ書き換えとか、解らない方式も出来るけどね
>役に立たない
そういう時はバッサリ捨てて書き直すに限ります
XPでも言われてるし
>>362 たぶんインターフェースに対して実装が
複数在る事を指してるのだと思われ
OOに関係なく、単なる汎用化に対するアプローチの一つ
関数ポインタとか構造体とか共用体を駆使すれば
昔から有る名も無きパターン
>>360 オブジェクト指向的にモデルを構築できない時点でも、やはり技術力は足りてないな。
結局駄目な製造物しか作れない同じ穴の狢さ。
５０歩１００歩なんだよ。
Eclipse + Java + checkstyle + findbugsとかで開発したことないの？
C2Dの4G位メモリ積んだマシンでもたまにマシンを窓から投げ捨てたくなるくらい
イライラすることもあるけど、コード補完やコードテンプレート、静的解析なんかで
テキストエディタとコマンドラインでちまちまやってたときより遥かに作るのは楽に
なってるよ。 javadocをきちんと書いていればコード補完中に見れるからいちいち
リファレンス開かなくてやかったりするし。
作ってるものの構造をきちんと理解していればデバッガで追うなんて簡単だし。
でもたまにレスポンス悪すぎて窓からPC投げ捨てたくなったり、ディスプレイを
グーパンしたくなるときがある、、、
>>364 > たぶんインターフェースに対して実装が
> 複数在る事を指してるのだと思われ
そんなのC言語の時代からでもやってたような。
もちろん「OOPをオブジェクト指向サポートない言語でやっていた」以前のレベルでの話だよ
そう。C言語でも技術力がある人はやっていた話。
そして逆に技術力のある人はやっていない。
今ではインターフェースなどという言葉で簡単に説明ができるが
昔はそういう言葉が無かった。名前が無いものを教えるのは難しい。
もしデザインパターンのような考え方（パターンに名前をつける）
の有用性が広く認知されていたら、C言語で実装したソレに
インターフェースパターンという名前をつけていただろう。
さて、今技術が無い人。そういう人がインターフェースパターンを知るにはどうするか。
インターフェースパターンを知っている人は昔で言えば技術力のある人だ。
オブジェクト指向を勉強すれば自然とインターフェースパターンを知ることができる。
このようにオブジェクト指向を勉強することは、技術力をつけることにもなっている。
もちろん、これがすべてじゃないよ。
技術力がある人は結局やってたのかやってないのか
なんにせよ、そういった技術についていけない技術者が、
上流や管理に逃げるというコースが出来上がってて、
設計は駄目駄目で、納期やコスト的にもガタガタだろうが、
下に責任を押し付けて保身しようってのがプロジェクトの定番になっている限り、
日本のIT業界の未来はないよな。
海外じゃSI企業なんか無くて
自社でプログラマ、アーキテクト、マネージャ辺りを雇って
要件から製造まで全てやるって聞くな
出来なければ切られるだけだろうしな
>>368 （こいつこんな支離滅裂な文章書いてて実力ある気なんだろか？）
>>372 夜中に酒飲んで気が大きくなるとこんなふうになる奴いるよね。
つか現代においては、インターフェイスなんて、デザパタに入っているのか？
昔はんな簡単な仕組みは無かったはずだな。
関係が複雑だとか、あまり使う人が居ないとかいうパターンを
説明し易いように名前付けしようってのが、元々だろ。
今じゃ、馬鹿に教えるためのパターンと化してきたのかな。
酔っぱらいか？
インターフェースは大昔から有るだろ・・・
Application Programming Interface略してAPI
デザインパターンの話をしているんだが
酔っ払ってるんだろう
いいご身分だな
APIで使うInterfaceという言葉は、一般的な意味で使ってるだけだから、
>>368が言うような設計上の構造を示す用語としてのInterfaceとは別モノだな。
ツッコミを期待してたら
マジレスされたって構図なんかね
おじゃば臭がする
＞例えとしてOSとアプリの境界線が無い時代もあったんだよ
＞OS機能を抽象化させた、太古のパターンと言っても過言無い
だからそれは
>>368が言ってるような構造かもしれんが、
APIのIは、そういう意味でのInterfaceじゃない。
もっと簡単なシステムでの例で言うと、
APIという言葉はシステム側が用意した単なるライブラリーの意味としてすら使われるが、
Interfaceの定義上間違いだから詐欺だという話にはならんだろ？
学生とバカリーマンしか居ないな
2chじゃまともに確定した答えも出せないいい例だな
>>382 よく解らないが、がんばって解読するに
APIと言う言葉は一般化しすぎて、
意味が明確でないと言いたいの？？？
・Webサイト と ホームページ
・wiki と wikipedia
みたいな感じで？？？？
酔っ払いが１人紛れ込んで暴れている
という答えは確定しているけどなｗ
自分のことだからわかるのですね。
時折高度な話になったかと思えば低俗な揚げ足取りをはじめるお前ら
俺の肛門を継承してくれ
知らない単語が沢山出る度合いの多い程、高度な話だと思い込むのは、日本人の悪い癖だな。
そういった思考の指向性が、本質を見る力を失わせていると感じている。
また、そういった人物がプロジェクトを任されることになった場合、
えてして悪質なシステム屋に騙されてしまうだろう。
そもそも、この業界での話知らない単語が
たくさん出ることが無いのだが・・・？
へー。すごいすごい。
はぁ。
学生が混じってるな
それもとことん偏差値の低い
この場合、偏差値の母集合は何だろう？？
知らない単語というか、バズワードみたいに曖昧であやふやな単語、と言われたら納得するな
だから知らない単語の話と何の関係があるの？
402 ：
仕様書無しさん：2010/07/31(土) 15:08:35
なんかシュールな展開だなｗｗ
頭悪いから会議とか呼んでも全然関係ない話しはじめちゃう人なんだろ
突然おもしろくなった
地球の運命は
オブジェクト指向とかけまして
地球の運命と解きます
その心は
信心で整いました
410 ：
仕様書無しさん：2010/08/01(日) 02:57:41
まあ俺くらいの高スキルを持つ人間にとっちゃ、システムの全体像を頭の中で詳細までイメージできているから
シンプルでわかりやすく、汎用性があるものなんて朝飯前なんだがな
手順がソース上で全部並んでないと、何やってんのか分からん奴は、
飛ばれると困るだろうなｗ
>>412 なにいってるの？
動的にしたんだからドキュメント無しなら実行してみるまで誰もわからないに決まってるじゃない
わからないなら発言するなよ
>>413 なにいってるの？
それが分からなきゃ仕事が出来ないという発想の奴には向かないって話だろ
自分の頭の中にあるものを文書化できない奴ってようはハッタリなんだろ？
それか現実と妄想が乖離してたとばれた時に責任問われないための方便か？
どちらにしても言うだけならタダだから楽だよな
わからないなら発言するなよ
>>415 じゃあ、君の「ハッタリじゃない技術」を3歳児に説明してごらん。
OOの達人の気持ちが少しはわかるかもしれないから。
418 ：
仕様書無しさん：2010/08/01(日) 09:59:54
自分の意見は言わないけど人には出せだせってうるさい奴いるよね
>>418 「おまえら、その辺のOO言語でオブジェクト指向がどうこうなんて語ってんじゃねえよ。
純粋OO言語のSmalltalkですら本来のオブジェクト指向のほんの初歩的な部分実装の出来損ないだ。
本来のオブジェクト指向ってのは、先進的すぎておまえらにゃ到底理解できないんだよ、カス共。」
そう見えるとしたら早く病院へ行ったほうがいいよ
私は420ではないが―
>>421 そう読めないとしたら、わかった気になる前に、もうちょっとアラン・ケイが彼の「オブジェクト指向」や
暫定実装の Smalltalk で本来やりたかったことがなんだったかを知っておくのもよいかもよ。
「ソフトウェア工学」は矛盾語法か？ - アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html 表現に問題があるとはいえ、
自分より理解できている420をあまつさえ池沼よばわりするのはやめておいたほうがいい。
424 ：
仕様書無しさん：2010/08/01(日) 15:28:37
たしかにC++ はひどい言語だ。だが、選ばれし優秀なプログラマーが使うことにより
この言語は最強のものに変わる。
425 ：
仕様書無しさん：2010/08/01(日) 15:45:01
えらそうに！役立たずが！クビだ！！
会社転々としやがれ、北斗かぶれが！
聖地を求めて辞めて行け！バカが。
426 ：
仕様書無しさん：2010/08/01(日) 16:10:14
聖地は俺の周りにできるものだ
それは聖地ではなく、整地だろ。
くわ持ってがんばれ、お前の周りが整地になる。
428 ：
仕様書無しさん：2010/08/01(日) 16:28:10
そう、そこから始まるんだよ
良い事言うねえ
整地が終わったら、ヒャッハー！に消毒される訳ですね。わかります。
北斗かぶれっての初めて聞く単語なんだが
おっさん達の間では共通認識あるのか？
聖帝十字陵を早く完成させるのだ～！！ とムチ打ち食らうんですね
あと、病を治すという触れ込みで、「ココかなぁ？？」とか言いながら秘孔を突いてみる度に、
客が悲鳴を浴びて、また違う秘孔を突いて回るというやつですな。
またの名を、障害改修ｗ
発狂した
>>421が恥ずかしいログを流そうとしている！？
スレが急に止まったので、みんな手持ち無沙汰になってんだよ。
やっぱC++はネタとして鬼門だな。
北斗ネタについていけないオコチャマが寂しそう
北斗ネタなんかで喜ぶオコチャマってほんと精神年齢が幼ないね。
恥しくないのかな。
おっさんなのに精神年齢が幼いって最悪ケースだな
北斗ネタについていけないっていうより
ついていく気が無いだけだと思うんだが
ク・ソ・バ・カ・ヤ・ロ・ウ・・・
今度は何のネタ？
ググるとそのまま出てくる
北斗ネタっぽい
うぜーな
こんな詰まんねえ流れですら、ググってまでレスしてくる粘着君ほどウザくねえけどな。
釣られてるやつが一番幼いな。
446 ：
仕様書無しさん：2010/08/06(金) 09:19:48
パターン厨の御用達
・Analysis pattern
・GoF
・Domain-Driven Design
・POSA POSA-2
・J2EE pattern
・PofEAA
知ってる限りでは以上だが、まだあるの？
あとは、何でもパターン化しないとモノを考えられない奴のことかな。
>>446パターンと命名した。
頭のいい人たちが一生懸命考えてパターン化したものを無視できるほど賢かったら自分で考えてもいいんじゃない？
将棋だと定石完全無視して打ってもプロに勝てるくらいの実力。
既存のウェルノウンなパターンと同じ目的のために新たなパターンを考えれば、
似たような構造（または全く同じ構造）になるだろう。
既存のウェルノウンなパターンを知っていれば、それを名乗れば済むと分かるし、
知らなければ、パターンと称して、同等（または全く同じ）機能に全く別の名前を付けて、
話してくるという、既存パターンを知っている人にとって相手しにくい奴になるだけ。
既存のウェルノウンなパターンとは別の目的のための何かパターンを考えたたなら、
別にそれでいい。
普及してウェルノウンになれば、新しいパターンとして加わるだけの話。
>>448 でも別にそれって実際数字が出して検証したようなもんじゃないし
しかも、シングルトンなんて
「おめーら、マジでオブジェクト指向っていうか、そもそも設計とはなんぞや？ってところからわかってんのかよ？」的
致命的な糞クラス入れておいて「頭のいい人たち」も俺としては「？」な感じだ
シングルトン以外は？
シングルトンパターンは別に頭悪くないぞ。
Smalltalk-80の時代からある、由緒正しいパターンだ。
>>453 こんなの使うんだったら設計なんて止めて
全部グローバルに格納しろといいたい
>>454 Danにそう言ってみれば？
っていうか、別にシングルトンをグローバルにしたっていいわけだが。
単にそのクラスのインスタンスが唯一そのオブジェクトであることを保証するためのパターンなんだから。
実際、Smalltalk-80ではSystemDictionaryのシングルトンをSmalltalkというグローバル変数にしていたし。
>>456 残念ながら、Danはお前よりもずっと思慮深く、ずっと経験豊かで、ずっと高品質なプログラムを書く。
460 ：
仕様書無しさん：2010/08/07(土) 15:43:10
まあシングルトンだけ知っていればなんとでもなる
>>458 まずはSmalltalk-80のソースに目を通すことを勧める。
デザインパターンをたたく人は
シングルトンパターンしか知らないから、
シングルトンに固執してるんだね。
しかも、唯一知っていると自称しているシングルトンパターンすら
理解が間違っているというwww
デザインパターン嫌いな人に、
こういうときはどういう設計するの？ってきいて
あれこれ説明させたあとに
「ようするにデコレーターバターン？」って
聞いてやったｗ 聞いてやったｗ
>>464 よくいる生兵法で知った気になってる初心者か。
先輩の仕事の邪魔にならないようにね。
>>465 だから、Smalltalk-80のソースに書いてあるって。
さっさと読んでみろよ。
>>467 答えられないなら俺の勝ちだけど？ﾆﾔﾆﾔ
>>468 もうとっくに何度も答えているのに、理解できないなんて脳がかわいそうな人ですね。
はいはい、ボクちゃんの勝ちでいいでちゅよ～www
>>459 これは正しいな
この業界はいつからこんな糞まみれになってしまったんだろうか
472 ：
仕様書無しさん：2010/08/07(土) 18:40:05
漏れデザパタ覚えたい お勧めサイトプリーズ
ぐぐりたくないの
まさか、マジでダン・インガルス知らずにデザパタ騙っちゃうカスがいるの？
474 ：
仕様書無しさん：2010/08/07(土) 19:29:20
お前ら、どこまでカスの底辺PGなんだ？？
GoFのデザパタ議論とか、所詮詳細レベルだし
はっきり言ってどうでも良いのだが
システムアーキテクトとかの試験要綱を読んでみると良いよ
オブジェクト指向抜きで方式設計書辺りを書くの相当つらいと思うぞ
資格試験のお勉強レベルが来たかw
476 ：
仕様書無しさん：2010/08/07(土) 19:57:25
でも実際仕事でCしか使わんからなー
しかもライブラリ使わずに総ステップ数３０００くらいだし
いまだにステップ数（笑）
478 ：
仕様書無しさん：2010/08/07(土) 22:17:04
じゃあ３０００行
>>457 どんなに技術力あってもあの人間性はチーム開発には向かない
そういう人ほど実は賢いという事実
奴は開発したことないと思うけどなｗ
馬鹿を集めれば集めるほど、足を引っ張り合うルートを増やすだけで、
トータル開発能力は逆に下がる、というのは有名な話だが、
優秀な技術者を集めれば、集めた人数分の能力を必ず発揮できるかどうかも、また正しくないんだな。
ただし、後者はお互いの得意分野同士での鬩ぎ合いが良く起こる等のマイナス方向か、
逆に相乗効果によって人数以上の能力を発揮する等のプラス方向か、
結果が未知数であるという意味で正しくないってこと。
>>483 開発やったことなさそうだね君
ある程度経験積んだらどんなに優秀な奴でも平均の２倍の作業量すらこなせない
ってことに気がつくだろ
これ冷静にスケジュールしたら期間が２分の１だぜ
実装して、テストやって、バグ直して、向こうから仕様変更きたり、
設計時はよくわかってなかった仕様が決まってきたり・・・
現実に起こるこういう問題をスキルが高い程度では解決できないことにいい加減気がついてもいいだろ
ソフト開発は間違いなく人月計算が妥当
＞実装して、テストやって、バグ直して、向こうから仕様変更きたり、
＞設計時はよくわかってなかった仕様が決まってきたり・・・
まさにそれが、設計段階で既に優秀な技術者を集められず、、
無能設計者を集めれば集めるほど、足を引っ張り合うルートを増やすだけに終わるパターンの典型例だ。
そこって、人足りないからってどんどん追加するけど、
トータル開発能力逆にどんどん下がってるだろ。
つまり、現実にそんなことが起こってる現場は、設計スキルが足りなかったってだけの話。
>>484 とりあえず、「人月の神話」とか「銀の弾丸はない」とかぐらいの論文には目を通しておいてくれよ。
>>486 俺はそれただの釣りにしか見えないって話してるんだけど？
>>486 「人月の神話」とか「銀の弾丸はない」とかぐらいの論文とか、
自分のやり方に反する説には聞く耳持たない人って多いよ、この業界。
こういうのには、何を言っても無駄ってことでしょ。
なぜこのプロジェクトはデスマるのか？
冷静に分析する能力に欠けるプロジェクトが、かくも多い理由が見て取れるよな。
489 ：
仕様書無しさん：2010/08/08(日) 11:50:35
>>484 WBS上の末端タスクで断言されても・・・ｗ
それ以前に、WBS上で管理できてるような作り方では、デスマ確実ｗ
>>484 えっと、優秀な技術者は平均的技術者の生産性に比べて20倍高いということを
きちんとデータを取って検証した学術論文があるが、これは無視か？
いや、WBS管理しか能のない連中が上に上がるから、
プロジェクトがどんどんデスマ設計化して行くという方が正しいか。
ウォーターフォール型の縦割りタスク分業になって、
スレテーマであるオブジェクト指向設計の方向からどんどん外れていく
姿が目に見えるようだ。
学術論文ｗじゃなくて現場を見ろよ。20倍なんてありえない。
>>484はほぼ正論で優秀なやつが生産性高められるのは実装部分だけ。
むしろ自分のこと優秀だと思ってるやつほどテストまともにやらないし。
逆も有る、上流でOO設計し
下流で能無し会社PMレベルでOOから外れていく
要は管理出来ないとか、責任が曖昧とか・・・
末端PGでは理解してくれる人も多数いる
>>493 優秀な設計者がちゃんと設計すれば、テストの工数を飛躍的に短縮できるぞ。
例えばフェリカカードの事例を見てみろ。20倍どころじゃないから。
おまえこそ、実装でしか生産性を高められないなんて、どこまで視野が狭いんだw
>>496 え、設計は開発に含まれないの？
君、どんな職場で仕事しているのかな？
>>496 提案も議論の場にも呼ばれない、偽装請負の3次受け底辺派遣PGの結論だと解ってるよ
じゃあ、実際にお前等２０分の１の期間しかもらえなくてもできんのか？
って言ったら確実に無理なんだからそんな糞本信じてんじゃねぇよｗ
501 ：
仕様書無しさん：2010/08/08(日) 14:21:08
設計で出来る奴って滅多に居ないが、
製造だけの話なら、なおさら出来る奴と出来ない奴の違いは、
どんな現場でも見ることができるだろ？
全部同じに見えるなら、そら自分が出来ない奴サイドに居るからだなｗ
0に何をかけても0以上にはならないのでこの議論には意味がないです。
冗談はおいといて、妊婦10人集めれば1ヶ月で子供は出産できるのか？って
いうのが人月の考え方の基本ですが、全ての工程に当てはまるわけでもない
というのは仕事をする人なら分かっているかと思います。 工程の一部でも
20倍の生産性を出してくれるなら、その余った分を他に回せますから。
まあ、優秀な管理者が必要なんですけどね。
それと戦うプログラマーの時だったかで、単純に大量に人を入れてもパフォー
マンスを得られないけど、優秀な人間を大量に入れてオーバーヘッドの部分を
減らして何とかするしか無いという結論になったとか。
破綻しかけたプロジェクトに単純に人を入れても効果がないどころか悪化する
だけだが、人を入れないとどうしようもないのは事実で、少数or大量の優秀な
人間を入れるしかないという。
>>502 20倍はありえないって否定しただけで
なんで全部同じに見えるってことになるんですか？
出来の悪い奴は、存在自体がマイナスなんだよ。
こいつの作ったモノは、作り直した方がいいというレベルのが
ゴロゴロ存在してるだろ。
２０倍どころか、居ない方がマシ。
つまりマイナスだ。
マイナスに２０を掛けてどうする。
>>506 酷い言い訳してないで糞本さっさと投げ捨てろ
>>505 入れるなら社内の余っている新人や出来ないのじゃなく、可能な限り優秀なのを
入れないと赤字が増えますよってことです。
>>506 数学的にマイナスにマイナスをかけるとプラスになるので乗算で考えると
まずいのです。 掛け合わさってという考えを捨てて、加算的にいかに積み
上げるのかというように考えないとダメかも知れん。
ソフトウェアの成果の本質は、量でなく質である。
そもそも算数的に量で測ろうってのに無理がある。
つまり、システムの製造を算数で考えるのに無理があるって分かったよな。
これで、馬鹿でも足し算として分かるようにWBSで管理しようという発想に無理があるのも、分かるよな。
>>499 馬鹿だなあ、そこに書いてある「開発実施」というのは、インプリの意味だ。
その程度の基本的なタームぐらいちゃんと理解してから爆笑ネタを流してくれ。
>>500 俺のチームはデヂドカでは永遠に実装不可能な案件をいくつもこなしてるから、
生産性の比は20倍どころじゃないぞw
ことITに関しては、上手いやり方と下手なやり方で、効率が１０００倍違うとか、
平気であり得るよなｗ
>>511 モジュール仕様、コーディング、単体、結合まで含めて開発実施ってなってるじゃん
インプリってのはコーディングか、行っても単体まででしょ。結合テストをインプリなんていうやついないよ
>>514 結合まではインプリだろ。 客の受け入れはインプリじゃないけど。
>>503 > 0に何をかけても0以上にはならないのでこの議論には意味がないです。
それなら0に何かを加えれば良いんじゃね？
0に10を加えれば、10になるよ。
足すとか掛けるとか、そんな比喩に意味はない。
効果があるかどうかはっきりさせたかったら、実際にやってみて効果測定すれば一目瞭然だ。
生産性20倍の話、
やっぱり土方暮らしの人には信じられないのかな。
まあ土方みたいな、単に上流からのドキュメントを
ブレークダウンしていくだけの単純肉体労働では、
20倍の生産性の違いは出ないだろうね。
ほんとに20倍の生産性があったら相手してねぇだろ。バカが。
x倍の考え方
1) 内部設計から請負契約
2) 力業での見積もりを出す（全部力業の見積もり)
3) 請負なので、好き勝手に分析し冗長化無しで設計する
4) 設計書・コードジェネレータとかも作る
5) ドカタ・大陸に簡単で力業の箇所のみ発注する
6) 納品する (見積もりのx倍達成)
ドカタは5だけなのでx倍は無理デスッ！
>>518 すげーな期間２０分の１で請け負うって言ったのか？お前ｗ
昔俺がいた中小の糞会社の社長より脳みそシケてんなお前ｗ
10倍でもなく30倍でもなくなぜ20倍なんだよ。根拠に乏しすぎ。
>>522 さぁ？
なんでも過去に実績があるらしいよｗ
先進的な人の考え方は土方には理解できないから説明するだけ無駄ですよ
だんだん土方(ひじかた)さんがかわいそうになってきた。
そーいえば土方(ひじかた)さんという優秀なヒトと仕事したことある。
彼の生産性は2倍は確実にあった。
チームの女のコに手を付ける早さは20倍以上だったけど、
これは比べる相手がほぼゼロに近い速度なんでしかたないな。
1の技能に対して20倍っていうのと10の技能に対して20倍っていうのでは
雲泥の差があるよね。
結局のところ、「何に対して」っていうのが曖昧だから、よく分らんって事に
なるんだと思うよ。
>>521 うちの会社は実績値から内部見積りの工数を産出するが、
うちのチームは内部見積りは普通に1/20で処理している。
客には相場の半分ぐらいの工数で見積りを出すけどな。
つうか、どこの会社でもエース部隊はそんなもんじゃね？
価格破壊だな
業界も破壊されるな
その学生バイトサークルのりのエースどもがバカやってるせいで
入社二年目のクズでもそのくらいの生産性が上げられると思い込む客が出てくるんだが
どうみても優秀で1/20で仕事仕上げられるのに、何で半分の工数見積もって仕事うけてんだよｗ
そういや、楽天のwebページ作成のアライアンスサイトも酷かったな。
お仕事お願い、募集系サイトはかなりひどい
「iPhoneのソフトをできるだけ安く作ってくれ」とかざら
楽天ビジネスか。探してみたがおもしろいなｗ
楽天ビジネスが本当に恐ろしい - My Life Between Kyoto and Shiga
http://d.hatena.ne.jp/hikoneko/20090903/p1 えげつないビジネスで天下に名をとどろかせている楽天のサービスで「楽天ビジネス」というのがあって、
端的に言えば案件ベースのマッチングサイトなんですが、わからん人は適当に「楽天ビジネス」でググって調べてください。
で、会社でも契約して僕も毎日見ているんだけど、これがすごい。
ページ数10ページのサイト制作とかで、平気で予算3万から7万とかで仕事出している人がいる。
「桁間違ってるんちゃうの？」とか思うんだけど、本気でこの値段でやって欲しいと思っているみたいなのです。
そして、それに応札している人が10件とか平気で出ている。
あのね、最高額7万で仕事できたとして、それってメール何通かやり取りして、
2、3回会って打ち合わせしたら人件費だけで消えてしまう額でしょう。
とてもウェブ制作なんてレベルの値段ではない。それでもやる人がいる。
とにかく実績が欲しいのか、それともメンテナンスとか何か別のところで設けようとしているのか。
詳細はわからないけど、7万のウェブ制作なんて仕事が当たり前になったら、
平成の女工哀史というかそんなんで会社がまわってゆくはずがない。なんだか背筋が寒くなってきた。
(続く)
10万でA8ネットと同様のシステム開発なんてのもあった。できるわけねぇだろ。でも応札している人が何人もいた。
これは富士通だのNECだのが公共のシステムに1円入札なんてのとはわけが違う。
あれは保守費をたんまり取れるから成り立つんであって、
楽天ビジネスの案件は今もこれからもどう考えたって儲かりっこない話でしかない。
それなのにやる人がいる。なぜなんだ。
そして、こんなひどいマーケットに参加するのに、楽天には月々2万円以上の参加費を払わなければならない。
楽天儲け過ぎだろ。楽天ビジネスなんてシステム、それこそ楽天ビジネスで募集したら10万くらいで作る人がいそうだ。
どうしてこんなことになってしまったのか。月に2万円も払って出てくる仕事なんて全く割に合わないものばかりだ。
それでも出せば大勢の人が応札してくる。
ここの価格がベースになって仕事がまわるようになったら、事務所経費も人件費も通信費も交通費も払えっこない。
会社なんて絶対にまわらない。給料なんて出せるわけがない。
それでも仕事は流れてゆく。私にはその理由がわからない。
楽天ビジネスが本当に恐ろしい - My Life Between Kyoto and Shiga
http://d.hatena.ne.jp/hikoneko/20090903/p1
>>532 > どうみても優秀で1/20で仕事仕上げられるのに、何で半分の工数見積もって仕事うけてんだよｗ
利益ってそうやって出すもんじゃないの？
>>535 まったくその通りだね。半分の工数では取りすぎと思っているとしたら、その人は一生貧乏なままだろう。
2000万のものを1/20の100万で仕上げて、1000万で受注して900万儲け
きわめて正しい儲け方だな。
>>532はビジネスを知らない
他人が作ったの泥棒してりゃそりゃ20分の1で仕上げられるわな
539 ：
532：2010/08/11(水) 13:23:44
>>535-537 納得ｗ 俺が間違ってたわ。確かにそうだ
数倍の速さで仕上がられる社員がいてインセンティブは払うかもしれないが、
数倍の給料払う分けはない。
その分で得た利益でさらに、人雇って仕事受けるなり、
設備投資するなり、広告打つなり、儲けに繋がることにまわせばいいわけだ
540 ：
仕様書無しさん：2010/08/14(土) 05:28:01
設計、コーディング、UNITテストだけなら２０倍は変わるかもな。
要求分析、要件定義、機能仕様まで含めたら２０倍は無理だろ。
ついでにウォータフォールやVモデルを強要されたら不可能。
ただ問題は生成物の質と、できない奴ができないことに気づいてないこと。
>>540 > 要求分析、要件定義、機能仕様まで含めたら２０倍は無理だろ。
そのあたりこそ、20倍どころじゃ済まないだろ。
> ついでにウォータフォールやVモデルを強要されたら不可能。
意味不明。自分の能力が足りないことを、開発プロセスのせいにしたい？
ダメなプロセスの責任を個人の能力のせいにしたいんですね、わかります。
ダメなプロセスを認識できているのに自分の職掌じゃないから無視するみたいな縦割りが一番ダメ
ウォーターフォールがダメといわれるのもウォーターフォール自体がダメというより
ウォーターフォール型のプロジェクトは縦割りな事が多くて縦割りがダメなんだと思う
じゃあ横一線ならおｋ？
横方向のやりとりが増えると、有能な人が低能のフォローのために忙殺される。
結局のところ、プロセスがどうこう言う前に、
無能な馬鹿を外して有能な人だけのチームをつくるのが先決。
有能な人もピンきりだからなあ・・・
結局チームがうまく回ってれば有能無能かんけいなし
総合力で有能無能を判断するのは難しいし
結局は結果なんだよね
547 ：
仕様書無しさん：2010/08/14(土) 20:51:28
機能が不足しているために発生したバグを修正させてみる。
単一責任原則や可変性分析を理解しており、必要なクラスを新規追加したり、
再利用できるものとしないものをしっかり分離してくれる人なら安心。
周辺のリファクタリングやテストドライバの実装をしっかりやってくれたら
任せたい人だな、と思う。
スプラウトメソッドを追加して、周辺のコードには手をつけないならば
まあ普通かな、と思ったりする。（開発フェーズにもよるが。）
今あるメソッドにべったり書いたら、あちゃ～っとなる。
自分の感覚では、
できる人ほどコンパクトで一度作ったら扱わなくて良いコードを
たくさん積み上げていくけど、できない人ほどクラスを膨らませる。
できる人ほどシンプルで当たり前で一見全然凄くないコードを書くけど
できない人ほど複雑で抽象の度合いがまちまちなコードを書く。
（ロジックとメソッド呼び出しが入り乱れたような）
548 ：
仕様書無しさん：2010/08/14(土) 21:33:08
>そのあたりこそ、20倍どころじゃ済まないだろ。
ステークホルダとの協議や試行を重ねなければならない。
相手に依存する部分が大きいので個人のスキルが高くても
たぶん20倍の差はでない。
>意味不明。自分の能力が足りないことを、開発プロセスのせいにしたい？
決めた通りに作っても使ってもらったときに後戻りが発生するプロセスだから。
相手の要求の強さとコスト（純粋なスキルではない）を天秤にかけるので
たぶん20倍も差がつかない。
説明がめんどい、、、
能力差は設計力差。
横割りは機能の分析が命だ。だから機能単位での再利用性が高まる。
横割り機能単位設計を正しく評価できる会社は、自ずとウォーターフォール型では
管理できないことに気付いているはず。
ウォーターフォール＝縦割り≒毎回最初から作り直しが定石
だから効率が悪い。
再利用ってことは、する・しないの差は、部分的には２０倍では済まないだろう。
なんせ最善の場合、しない場合の分母がゼロだからな。
再利用性は、何もプロジェクトに閉じた話ではない。
全く違う業種のプロジェクトだろうが、論理的に同じ機能は、同じに出来るはずなのだから。
こういったことを突き詰めると、会社はプロジェクトをこなせばこなすほど
利益率が上がっていく。
これができない会社は、年々利益を落していく。
で、デスマ度を上げるぐらいしか対策が無い。
できるできないで明暗が分かれるのは至極当然。
>>549 言ってることは立派だけど、現実にそんなにうまく汎用機能を持つ機能ライブラリが作れるんだろうか。
たとえば100人単位で10個の部署があって、それぞれが別のプロジェクトをこなしていた場合、
要求によって様々な機能を実装しなければならないが、汎用に作ってある機能ライブラリを無理矢理使って
実装するのか、それともそれをベースに独自に拡張するのかによって、出来上がるものが違ってくる。
プロジェクトは日々変化するから、それに合わせて今できている機能ライブラリをうまく調整し、
全社員にわかる形にまとめ上げて、次のプロジェクトで使ってもらうように周知させる作業は並大抵じゃない。
>>549 > 再利用性は、何もプロジェクトに閉じた話ではない。
> 全く違う業種のプロジェクトだろうが、論理的に同じ機能は、同じに出来るはずなのだから。
うん。だから、そういうものは標準ライブラリとして
一般に提供されているんだよ。
ようするに作る必要はない。使うだけ。
自分の会社でだけ再利用できるライブラリなんてのはめったにない。
できない奴ほどぐだぐだバズワードちりばめた長文を書くのはたしかだな。
553 ：
仕様書無しさん：2010/08/15(日) 02:03:08
どちらかというとプロセスより
１．SOAでいくか、２．リッチドメインでいくか、
３．その中間のサービスレイヤを設けたドメインモデルでいくか、
ここら辺が大きいだろうね。
再利用の方法も変わってくる。
１はサービス単位での追加、修正、再利用が劇的に簡単。
２はクラス単位で再利用できて、再利用したときにそのクラスが最も良く振舞う。
３は再利用が一番難しい。アーキテクチャごと再利用しなければうまくいかない。
っていうか、うちの会社のレベルで再利用できるコードがあったら奇跡だな。
>>548 > ステークホルダとの協議や試行を重ねなければならない。
協議時間など、たかが知れているだろ。
工期は一定数かかるが、工数は分析者の能力次第で大きく変わる。
20倍程度の差は普通につく。
それとも、おまえんとこの分析屋は仕事時間のほとんどを会議だけで
分析してんのか？だとしたら下流工程の連中がかわいそうだな。
> 決めた通りに作っても使ってもらったときに後戻りが発生するプロセスだから。
マトモな分析屋なら、今後出てくる追加要求や変更を予見できるレベルまで
しっかり分析するものだが、そこを中途半端にするから余計に工数がかかる。
議論が噛み合わない理由がわかったよ。
想定している分析屋の能力が違いすぎる。
君が言う分析屋ってのは、せいぜい5年か10年ぐらいの経験しかない初級者レベル。
ごく一部のベテラン設計者がいないと効率よく進まない会社はその人がいなくなると身動き取れなくなる。
普通の能力で普通にできる人がたくさんいたほうがトータルで見れば効率がいいと思う。
縦割り設計は、縦割り設計派閥が居て、幾ら理想論を言ったところで
努めて組織的に聞く耳持たぬようされるから、どうしょうもない面があるね。
そりゃそうだ。連中ソレでしか設計能力ないのだから、他の方法が
流行ったら食う術を失うので抵抗も必死だし、縦割り設計は縦割り設計で、
その効率の悪さから仕事量が多いゆえ、派閥の構成員が多く、
抵抗勢力の力も絶大である。つまり無理なんだよ日本では。
>>556 縦割り式なら、顧客はカネさえ払えば何もすることない。
下手にアジャイルとかやられると、
顧客も成果物に責任を持たなきゃならない。
結局、アメリカにはその責任を負う勇気のある野心家がいて、
日本ではそんな責任を取りたくない顧客が新しい手法を拒否する。
>>557 同意、アジャイルは本来の意味では日本には絶対根付かない。
だが、コスト削減という部分だけを都合よく利用する大手が、下請けに対して要求してくるだろう。
いつものこと。
これ思い出した
> ヨーロッパにとってソフトウェアは「科学」
> 日本のソフトウェアは「製造業」
> インドのソフトウェア産業は「（プロフェッショナル）サービス」
> アメリカのソフトウェア産業は「ビジネス」
560 ：
仕様書無しさん：2010/08/15(日) 12:07:33
>今後出てくる追加要求や変更を予見できるレベルまでしっかり分析するものだが
やっちゃいけないパターンだ。
ウォーターフォールでそれをやると設計麻痺を起こす。
歴史的に見て多くのプロジェクトが失敗した一番の原因として叩かれてる理由だろ。
561 ：
仕様書無しさん：2010/08/15(日) 12:30:23
>> 554
協議が同じ時間で全体の10%とすると差は最大10倍いかないが、、、
>>554 真逆じゃないの？
まわりにまともに仕事できるやつしかいない場合は
顧客折衝含めたらどうがんばっても20倍の差なんてつかない。
あなたのまわりみたいにまともに仕事できるやつがいない場合は
ちょっとまともなやつが入ってくるだけで20倍の差がついてしまう。
>協議時間など、たかが知れているだろ。
それなりの規模のプロジェクトで
顧客折衝やったことないやつに言われてもね。
>>561 そりゃ、単に要求仕様なる文書を書きさえすればいいのなら、20倍はいかない。
しかし、下流工程に与える影響を考えれば、20倍程度じゃすまない。
>>562 自分の無様な「成果物」がいかに下流工程に迷惑をかけているか自覚していない人ですね。
565 ：
仕様書無しさん：2010/08/17(火) 20:35:51
>>563 554は上流（設計は含まず）のみで
> 20倍程度の差は普通につく。
らしいよ。
566 ：
仕様書無しさん：2010/08/18(水) 11:26:17
書くスレ間違ってるぞｗ
568 ：
仕様書無しさん：2010/08/18(水) 14:16:06
>>566 OOPのスレだろ
ソフトウェア工学までは許せるけど
そこまで行くと脱線しすぎだな。
また、マは別にSI関連だけではない
とりあえず情報システム板に帰れ
>>565 暗黙の前提として、アウトプットに一定のクオリティを求めるなら、20倍ぐらいは普通だと思うが。
つーか、カスSEが何人月かけたところで、本物のSEと同等のクオリティのアウトプットは出せないからな。
そう。
効率が○○倍とかは、無能管理者にありがちな発言。
無能管理者は、自分が見える範囲の結果が同じモノを同じ時間で作成できれば、
それは同じ能力であると決め付けるからな。
まさに人月なんて考え方がその典型。
だが実際には、馬鹿が作った馬鹿コードと、本物のSEが作った優れたコードでは、
クオリティーが違い過ぎて比較すらできん。
モノが違うんだよ。
何倍とかいう尺度で測れるような違いではない。
ｵﾌﾞｼﾞｪｸﾄ指向、無駄だ。
管理者に見る目が無いと、真面目にクオリティー考えて設計するのが馬鹿馬鹿しくなるからね。
動作さえすりゃ後はどれだけ早く作ったか？ってだけの評価なら、
単純に手順を列挙していくだけの素人仕事で十分さ。
で、客先から要求仕様変更が入ったり、将来的な増改築を加えていけば逝くほど、
手順全体への影響が追いきれなくなり、改変による歪が加速度的に歪を生み出していく、
メンテナンス性の低い設計。
手順で設計するというのはそういうことだ。
だが、そういう管理者の場合は、そういう設計をしてやることにしている。
そっちの方が俺への評価高いし、向こうはダメな設計だと気付かないからな。
寧ろ、真面目に設計して評価下げるのは、非合理的選択であると考えている。
メンテナンスしなきゃならないような時期には俺は居ないから、俺的にも問題ない。
573 ：
仕様書無しさん：2010/08/20(金) 21:01:19
１０日作業が４時間が普通、はすごい。
身の回りでピンとキリ比べたら
設計だけでもそんぐらいの差はあるね。
ただ、極端な例だろうし、OOとは関係ねーな。
でもクオリティ重視の仕事ばっかじゃないし
っていうか早く安くのほうが多いし。
IT仕事の8割は土方仕事
577 ：
仕様書無しさん：2010/08/21(土) 03:17:02
設計やコーディングならありうるね。
要求分析・要件定義・機能仕様で２０倍が普通は無い。
ここならピアレビューして１、２回の指摘修正で済む。
>>577 典型的なドカタ思考だね。
要件定義こそ一番クオリティの差がつきやすいところなのに。
まさか、客が言ったことを箇条書きにすることが要件定義だと思ってる？
要件定義で交渉して機能を1/20に削れば20倍になるわな。
同じ機能を実装して20倍なんて絶対無理です。
580 ：
仕様書無しさん：2010/08/21(土) 23:17:30
そいえばステイクホルダーとの交渉10%なら10倍も差がつかないとかじゃなかった？
581 ：
仕様書無しさん：2010/08/21(土) 23:31:36
>>578 いや、ひょっとして要求と要件を勘違いしてないか？
で、用件を聞こうか？
お客の要求を聞いてから要件をまとめて設計完了までのどこで20倍縮めるのか簡単に教えてほしいんだが。
>>583 君は典型的なITドカタだね。
お客の言う事を箇条書きにしたものを「要件定義」と呼ぶのなら、
20倍なんて差はつかないだろうね。
でも、本当の「要件定義」ってのは、そういうものじゃないんだよ。
君がやっていることは右に置いてある書類を左のワードに書き写すだけ。
やっていて虚しくならないか？
もうやめたほうがいいよ。君にこの業界は向かない。
さっさとIT業界から足を洗って、便所掃除のアルバイトでも始めたらどうだ？
585 ：
仕様書無しさん：2010/08/22(日) 13:05:15
>>577 ドメインモデルやユースケース記述の作成で
ピアレビュー1、2回って、ちょっと信じられないんだが。
うちのレベルが低すぎるのか？
>>585 そいつ、設計書の枚数さえこなせばいいって会社なんじゃね？
2-3回のピアレビューだって、本気でレビューしてるわけじゃなくて、
単にレビューのハンコ欄が3つあるから、ハンコを2-3個押したいだけだろ。
この部分、ボレーレか何か使って実際に測ってみようか？
お互い知らないトランプゲームか何かで。
ダメ～な俺は2日（16時間）使ってみっちり考えるから、
できるお前は普通どおり48分でやってくれ。
交渉の時間はルールを理解する時間に置き換えるとして、、、
1時間は可哀想なので30分程度で理解できるものをチョイスしよう。
時間余ったら設計までやってOK。付き合うので。
ひょっとしてピアレビューと審査・承認のレビューを勘違いしてないか？
ピアレビューは1回のレビューで指摘のほとんどが洗い出される。
5回10回開催することにしてやっても良いが、
できればもっと説得力あるところを見つけて時間差を主張してほしい。
589 ：
仕様書無しさん：2010/08/22(日) 21:10:22
クオリティの差については特に否定していない。
この部分は修正コストが低いから20倍の差はつかないと言っている。
製造者スキルの低さ起因の製造クオリティーの低さは、実は大した悪ではない。
ぶっちゃけホワイトテストが完璧なら糞コードでも構わんだろう。
問題なのは、設計者スキルの低さ起因の設計（および製造）クオリティーの低さだ。
これはどうしょうもない。どんな優秀な製造者を集めても、論理的に噛み合うモノが
作れない限りは、どう上手く組んでも設計変更が嵐のように襲い掛かってくる。
製造者は、せいぜい見掛け上の製造クオリティーを上げて誤魔化すのが精一杯。
無論、終局はデスマに突入。
だからこそオブジェクト指向を重視したいのだ。
591 ：
仕様書無しさん：2010/08/23(月) 01:31:28
>>588 ハンコと言っているので知らないのだろう。
勘違いじゃなく知らないのだろう。
>>584 ごたくはいいからさっさと解説しろよ。できないなら人の批判なんかするな。
>>591 え？
承認とは別に、レビューしたら作業日報に記録した上で、レビュー記録を提出するだろ。
でないと、そのレビューにかけた時間はノーアサイン扱いになるぞ。
594 ：
仕様書無しさん：2010/08/23(月) 20:36:45
スレタイにちなんでまとめる。
えせオブジェクト指向の達人の特徴
・要求と要件の違いがわからない
・ピアレビューを知らない
・返事にこまったらスルー
・立場が悪くなったら汚い言葉で相手を非難
・知らない事を適当に返すので自分の立場をどんどん悪くする
・他人は自分より馬鹿だと思っている
えせオブジェクト指向の達人 ≠ オブジェクト指向の達人
596 ：
仕様書無しさん：2010/08/23(月) 23:37:59
オブジェクト指向については、Ｊａｖａをいくらかでもやればすぐわかる。
問題となるのはオブジェクト指向の達人がどうのこうのというより、
オブジェクト指向の何たるかを知らない教えないという業界レベルの低さ。
>>595 いや、それ＝だったら’えせ’つかないから。何言ってんだよ。
598 ：
仕様書無しさん：2010/08/24(火) 00:31:07
俺もスレタイにちなんでまとめる。
えせオブジェクト指向の達人の特徴
・オブジェクト指向がわかると顧客の要求に対して20倍速く設計できると思い込んでいる
(現場を知らない)
・少しでも自分より知らないと思った相手に対して不遜な態度で接する
(こういう性格なので人間関係作りがヘタ。社内でも便利屋としてしか見られていない)
・自分がわかっていて相手がわからないことはわざと説明しない
(自分の優位を保とうと姑息な手段を取る)
・図星を突かれると相手の欠点をあげつらって自分が優れていることをアピールしようとする
(しかしそれは相手にすぐ見破られていることには気づかない)
>>599 さすがに今までそんな人みたことないなぁ
このスレはおもしろいね。
似非ウォーターフォールでJavaしか使ったことない人が
オールラウンドな仕事をするOOハッカーの力量を否定するのが
とても微笑ましくて好きだ。
603 ：
仕様書無しさん：2010/08/24(火) 08:02:13
つまり602がえせかな？
604 ：
仕様書無しさん：2010/08/24(火) 08:18:36
おれもまとめる
えせオブジェクト指向の達人の課題（未解決）
・どこで20倍の差をつけるのか説明すること。
・要求分析と要件定義でステイクホルダーとの交渉が全体の10%とすると、
物理的に10倍以上の差がつかないことを論理的に否定すること。
・おれが２日で仕上げる作業を48分で仕上げること。
>>607 いやいや、さっさと説明しない奴が悪い。
>>604 > ・どこで20倍の差をつけるのか説明すること。
ログ嫁
> ・要求分析と要件定義でステイクホルダーとの交渉が全体の10%とすると、
> 物理的に10倍以上の差がつかないことを論理的に否定すること。
ログ嫁
> ・おれが２日で仕上げる作業を48分で仕上げること。
たぶん簡単だな。
まあ、仕事の早さに自信がある奴って、大概は単純作業の速さを自慢するからな。
そういう奴は一般事務では重宝されてきたかもしれんが、
システム屋としては非効率的やり方を人海戦術でこなすデスマ案件に向いてるだけ。
本当に能力のある奴は、モノはやり方次第だということを知っている。
仕事の速さなんて状況次第だから、単純に仕事が何倍速いなどという発想にはならない。
誰にも理解されない最初のヒト工夫のために、余計に時間が掛かったりすることや、
やり方次第で効率が１０００倍違ってくることがザラにあることを知っているからだ。
611 ：
仕様書無しさん：2010/08/26(木) 22:18:31
613 ：
仕様書無しさん：2010/08/30(月) 01:22:08
自分が目標とするやつの特徴
「技術は読んで身につける」ことを知っている。
洋書を中心にとにかく読む量が半端ではない。
だから20倍男のように設計用語が通じないというのはまずない。
自分ができないことを知っている。
学ばなければならないことが山ほどあることを知っている。
（だから読む）
開発時に多くの選択肢とトレードオフの落とし込みに
自分の溜め込んだ知識を生かせる。
（できないやつは発見的に１つ選択するしかない）
自分は社員である前に技術者だと思っている。
だから周りのやつとの比較のような視野の狭いものは無意味で
世界の中で自分の技術者としてのスキルについて興味がある。
例えば分厚い技術書を3冊読むとするじゃん。
で、その3冊めを読み終わる頃には1冊目で覚えたことの半分以上
は忘れちゃってるわけ。俺の場合は。
つか、俺は1冊の本を最低3回は読まないと身につかない。
1回目は雰囲気つかみながら、流し読み。2回目は、例題もこなし
ながら熟読。で、3回目は、やったことを確認しつつ確実に脳みそ
に刷り込みながら読む。
で、その後はひたすら実践。読んだだけで身につく技術などない。
実際にに自分で実装してみて、疑問点を調べて、応用してみて、
で、やっとまぁ、身につけたかな。って感じ。
本を読んだだけで技術をマスターなんて技、俺には無理っ！
615 ：
仕様書無しさん：2010/08/30(月) 06:14:31
それはあるね。
自分は１冊読んだところで既に最初の部分は忘れてる。
理解できればOKな本は読み返さない。
質のよくない本は本を代えて読み返す。
価値のある本は２回読む。
２回読んで１回使う。
勉強は何でもそうだが、読んで自分に足りない部分を吸収してその場で終わるモノ。
理解できない部分はまた後日。そうやって繰り返していくうちに、
読んだモノの内、吸収できる部分の割合を増やしていくもんだ。
読んで自分に足りないモノは無いと判断したら本ごと読み飛ばす。
そうしていけば、読める本の数は飛躍的に増えていく。
学習＝単純に記憶することだと考える奴は、毎回丸覚えすることばかりに必死になるだけで、
この場合、学習できることはゼロだろうな。
>>613 > 自分が目標とするやつの特徴
>
> 「技術は読んで身につける」ことを知っている。
> 洋書を中心にとにかく読む量が半端ではない。
だから613のように内輪用語が通じずに恥をかくというのはまずない。
>
> 自分ができないことを知っている。
> 学ばなければならないことが山ほどあることを知っている。
> （だから読む）
>
> 開発時に多くの選択肢とトレードオフの落とし込みに
> 自分の溜め込んだ知識を生かせる。
> （できないやつは発見的に１つ選択するしかない）
>
> 自分は社員である前に技術者だと思っている。
> だから周りのやつとの比較のような視野の狭いものは無意味で
> 世界の中で自分の技術者としてのスキルについて興味がある。
しかし、結果として同じ時間でも作業のクオリテイに数十倍の差がつく。
俺妹を3回目の読み込み開始した
一行レスするために全文引用とかアホか
>>617 差なんていつでも途中経過でしかない。そんなものにこだわるのは無意味。
そんなことより、自分が興味ある分野とか技術を一生懸命やってればいいんだよ。
比較したいなら昨日の自分と比較することだよ。
>>615-616 >>613 の目標とする奴の真意は本人に聞かないとわからんわからんのだけど、
頭に知識のindexを作っておく感じなんだと思う。
実際にやってなくても、引き出しを増やしておくというか。
そうしておくと、この場合はアレでいけるんじゃね？という当たりをつけやすい
俺も読んだだけじゃダメな方で、実際にやってみないと身につかないんだけど、
2chでいう半年ROMれじゃないけど、雑誌とか書籍買ってざっと流し読みしたり、
技術系のRSSフィード購読しまくったりしてると、いざ仕事の時にパッと判断しやすいんだよ
逆に全然知識入れてない分野だと想像で少ししか解決手段が上げられず、困ることは多々あるよ
だから、むしろ次々にどんどん読んでく
未知のことは完璧に覚えても、それを実際に使うかってわからないじゃん？
しかも、実際の仕事だと習得した技術がそのまま使えるかわからなくて、
結局早いサイクルで上手く行くか、ダメかを判断して、いくつも方法をためしてみるしかない。
となると、引き出し一杯合ったほうが判断しやすいじゃないかなーと。
俺は駆け出しだからかなり想像で書いてる、細かいことはわからんｗ
この手の知識や言語に詳しい人が居るけど、だからと言って
顧客の要望をうまくシステムに落としたり、仕様を満たした
プログラムを作れるかと言うと、実は全然ダメダメだったりする。
こういう自分仕様の物しか作れない人間は、特にリナクサウニクサに多い。
という脳内設定で得意になるドザであった
>>622 この手の知識や言語に詳しい人は、それが一番重要と思っているから記憶できる(学者タイプ)。
顧客の要望や仕様を満たすプログラムが作れる人は、それが一番重要と思っているからできる(職人タイプ)。
足りない所を補い合うのです
>>624 学者タイプと職人タイプでそれぞれ代表的な有名人の名前を挙げてください。
えんえん粘着攻撃を続けることがありありと予想できますのでエサをやらないでください。
>>619 数が数えられないの？特別養護学校に入んな。
>>622-624 確かにそれはある。本を読んでいる奴は大概仕事ができない。
うちでも、クソみたいなコード書くのを嫌がったりせう、テストしなくてもいいと思ってどんどん実装して
素早くコード書いていくような奴が一番仕事ができてる
テストしなくてもいい、とか、それ単にアウトプットの量が多いってだけじゃね？
自分がやってることの効率が悪さが分からない奴ほど頑張れるってことだろｗ
まさに何の工夫もなく頑張るだけなので、プロジェクトは当然の流れでデスマになる。
で、馬鹿らしくなった奴は抜け、よりデスマ向けの体力馬鹿ばかりが召集されることになり、
デスマは加速していくのさｗ
デスマの話なんて出てたっけ？
アウトプットの量？
そうじゃなくて、落としたクソの量だろ。
そう、糞な設計、糞なコードは、何ページ、何行書いても、糞の塊でしかない。
書けば書くほど泥沼化ｗ
確かにできないやつは全然本を読んでないね。
せっかく読んだのに使わなくなる技術もあるんだけどね。
あんなに勉強したCOMもActiveXもCORBAもEJBも
なんだったんだ...(?ｴ－д－；`)
>>636 勉強するものを間違ってるからだよｗ
そんな人が作ったフレームワークやライブラリを勉強して何が面白いんだｗ
どういう思想やアーキテクチャやアルゴリズムなのかを勉強するのはいいんだがな。
大卒と中卒の違いはそのあたりにある。
いまどき、ライブラリもフレームワークも使わずに開発するのか?
と思ったら、なんだ、趣味でのオナニー勉強の話か..
>>639 使い方の勉強は実際に使う直前にでもすればいいんだよ。
思想やアーキテクチャやアルゴリズムの知識や、世の中（主に科学技術の世界）の注目が
どういう風に動いているのかというような事は一朝一夕で理解できることではないし、
いざ問題を解決する段になってベストなソリューションを選択するためにはそういう知識がなければ駄目だ。
使い方なんてのはすぐに覚えられるから大して重要じゃない。
C言語を使ってHelloWorldを10回表示しなさいという問題を解決するとき、
printfしか知らない人は10回printfを書けばいいじゃんと思うかもしれないけど、
繰り返し文を知っている人ならC言語には繰り返しを実現する機能があるに違いないと目処をつけて
for文の存在を見つけ、for文で10回printfを回すようにすることで実現する。
その人は、そうすれば100回に仕様変更になっても簡単に対処できる、という事も想像できるんだよ。
繰り返し文という概念が脳内にない人はひたすらprintfを100回書くはめになる。
そう。そういう思想とかってすげぇ重要。
でも技術が衰退すると、そういう事が記述されている書籍も消えていく…。
InsideCOM/OLE(´・ω・｀)
>>636 当時の先端理論を具現化したものがそれらのライブラリだから、
それで学んだことがまったくの無駄ってわけではないと思うけど。
EJBパターンなんて今でも現役で使われている主要な手法だし、
COMなんかもテンプレートやコンポーネントによる言語非依存性
の実装とか、CORBAのスタブやモックオブジェクトによる分散処理
の実現とかも、考え方は全然廃れてないでしょ。
つか、俺はデザパタとか理論とかの理解より、それの実装である
ライブラリやフレームワークなんかの理解の方に苦労するわ。
最近ずっとやってるCocoa APIとか、OpenGLも１年やつてやっと
まぁ理解したかなって感じだわw 頭もいいけど、手も動かせってね。
>>643 勉強法なんかより、俺のとこにはCocoaやOpenGLを使う仕事が全然来ないことのほうが重要な問題なんだが。
仕事来なきゃ勉強しても役に立たねぇw
>>644 そんなもの勉強してもしょうがないだろ。
Cocoaを勉強するんじゃなくてGUIについて勉強しろ。
OpenGLについて勉強するんじゃなくてグラフィックスについて勉強しろ。
まあなんだってそうだな。
表面的なことばかり勉強したがる奴は、応用が効かず、
実務では何の役に立たないよな。
業界が資格を全然アテにしてない事実がそれを証明している。
でも、開発の仕事の募集って、◯×経験者とか、△□を用いた設計に
精通している人ってのが多いよな。
うちでも、現場で使えねぇ理論馬鹿はいらねーわ。
メスも触ったこと無ぇ医者に手術させるようなもんだろ。
うん。何でもそうだろうけど、物事を深く理解することは、
システマティックには中々理解して貰えないものだが、
現場の人には分かるもんだよね。
学生なら別に経験とか無くても口先と学歴だけでどこでも入れるだろ。
気にすんな。
> ◯×経験者とか、△□を用いた設計
こういうのは本で勉強した人とかは含まれないよ。
実際に仕事でやったことがあるかどうか、ってこと。
単一責任や開放閉鎖のようなオブジェクト指向の基本原則も知らずに
理論馬鹿は、、、といってるような開発者が下についたらほぼ放置。
>>652 それは基本原則ではなくて、テストなど一連の工程を含めた開発体制における常套手段の一つに過ぎないよ。
日本の業務系では日常だが、オブジェクト指向開発での基本原則ではないよ。
そのクラスを直接変更したほうが都合が良い場合もあるし、
そもそもテストで動作を保証する必要がない場合もある。
何が言いたいかというと、しがらみがないなら自由に思ったようにプログラミングすればいいってことｗ
え？
「オブジェクト指向の基本原則」だよ。
良く知られた６つ（＋１として繰り返し禁止の原則）の
「オブジェクト指向の基本原則」だよ。
適さない場合もあるというか、完璧に従うこと自体無理だけど、
知っておくべきだよ。
良かった、良かった。
知ってるよそんなもんと言われたら、５つ＋１だろ、と言うところだった。
自分らが考えたアイデアを他人から覚えておけと言われるのはなんというか複雑な気持ちになる。
今日もシコシコとエロ動画の研究に余念のない童貞君なのでした。
659 ：
仕様書無しさん：2010/09/03(金) 00:29:23
つまり君はロバート・C・マーチンなんだね。
>>659 別にそいつだけが考えたことじゃないよｗ
そう、開放・閉鎖はバートランド・メイヤー
他のも構造化設計や抽象データ型からの受け売りだシナー。
>>661 そんな雑魚どうでもいいしｗ
日常的な業務から発生した習慣を誰が編み出したとか言ってもしょうがないだろう。
そいつでもなく俺でもなく俺らが編み出したんだよ。
オブジェクト指向言語、オブジェクト指向開発手法の発展に携わってきた人間なら
誰だっていいんだよ。
それに、お前が言う原則は原則じゃないよ。
原則というよりもオススメ設計法と呼んだほうがしっくり来そうじゃない？ｗ
そもそもオブジェクト指向自体がクラウドやWEB2.0みたいなのと同じバズワードで
オブジェクトとは何かを正確に定義できていないよね。
いろいろ書いてる本は数多あるが、どれもこれも俺定義じゃん。
あと全く学問的でない発展をしてきたから宗教論争が絶えない。
お前が言う原則も含めて経験的なことばかりだよ。
その原則はおかしいという人もいれば正しいという人もいる。
オブジェクト指向はそういう世界なんだよ。
バートランドおじさんのおすすめ設計法ｗｗｗ
おまえの脳みそが学問的なことをスルーしてきただけだろwwwwwwwwwwww
>>665 学問的なオブジェクト指向ってどの本を読んだら勉強できますか？
経験的オススメ集じゃない物をよろしくです。
現場で使う道具を学問にしたがるおぼっちゃまがいるスレはここですか？
その人の大工道具には、梃子の原理も運動量保存則も適用されないんだろう。
すごいユートピアだな。
根拠がフラフラしているようでは道具として安心して使えないわなｗ
大工さんが使う道具は力学というしっかりした学問が背景にあるからこそ
少なくとも根本原理はついては安心して使えるってわけ。
もし力学が間違いだらけだって事がわかったとしたら、
水平器が水平を示さない場合があるかもしれないってことで大工さんストレス溜まるだろうなぁｗ
672 ：
仕様書無しさん：2010/09/03(金) 23:35:27
正しい、正しくない、役に立つ、役に立たないはともかくとして
この道のプロフェッショナルなら知ってることだね。
デザインパターンより先に知っておくものだと思うが、
デザインパターンほどまだ日本には入ってきていないね
>>670 でも大工が力学の教科書を読む必要はないわな
またオナニーか..
大工は力学の理論など知らずとも、職人の勘って奴で本能的に道具を
使うからな。まさに職人よ。
俺も、はじめてデザパタの本読んだ時に、ほとんど無意識に実践して
いることばかりだったんで、名前とパターンを一致させるぐらいで、
あらためて学ぶほどの目新しさはなかったなぁ。
職人にとって理論なんてそんなもんよ。毎日毎日何万行ものコードを
読んで、まねして、書いて、書いて、失敗して、学んで、そうやって、
次第に、定形パターンなんかはあらためて考えずとも無意識にコード
がかけるぐらいになっていくもんだ。
汗をかかずに本だけ読んで理解したつもりの評論家気取りは、すっこんでろ。
visitor なんか無意識に実践してたら逆にアホかと思うけどな
え？ Document-ViewタイプのGUIの設計とかで普通に使うだろ
Document-View タイプの GUI 設計をオブジェクト指向でやればいいんだってのは
自分が経験的に会得したのかい？本無しで？
ＡもＢも必要なことが自明なのに、何故人はＡかＢかという議論をするのだろう
まだデザインパターンがどうのこうのと言ってるアホがいるのか
あんなもん何の参考にもならねーよ
>>678 あぁ、MFC使ってWinアプリ作ってた頃のサンプルがそんな感じのばっかりだったからな。
その当時はデザバタなんてまだ聞いたことなかったし。まC++だからOOは意識していたが。
682 ：
仕様書無しさん：2010/09/04(土) 01:42:58
実際のところ、
一般レベルのプログラマにとってはコードを書くことよりも
読んで知識をつけることのほうが難しいんだよ。
オブジェクト指向の基本原則なら、最近はいくつかの良書翻訳が
出版された。デザインパターンはGOFの本の翻訳がある。
アーキテクチャパターンならマーチンファウラーが読めるが、
それしかないので更にPattern-Oriented Software Architectureの
Vol1～5を読むしかなかった。（１だけなら邦訳が読める）
ドメイン駆動、SOAのパターンも原著を読むしかなかった。
正直かなりしんどいよ。
コーディングは仕事の一部で、誰でも朝から夜まで
書いてる日があるのは当たり前。
たくさんの専門書を読むのはプライベートな時間も
犠牲にするからほとんどのやつは十分できない。
いなそうだね、目標とする人の域に達している人は。
簡単だよ、読まずに持論を展開するだけなら。
言葉通じないから困るけどね。放置するレベル。
今や記憶の隅に、読んだはずだよなという記憶が微かに残るだけで、
読んだ内容の１割も覚えていない
>>682なのでした．．．
リスコフの置換原則はリスコフが考えたんだよな？
Wikipedia嫁
>>678 Visual Studioの使い方知ろうと思ってマニュアル読んだら、最初にDOC-VIEWモデルで書かないといけないと書いてあった。
こんなもん別に学問でも何でもないだろ。
読んで知ってる程度の知識なんか現場じゃ役に立たないって。
納期があるんだから、ツールをいかに使い込んで効率良く書けるかが一番大事。
ツールを使い込んで慣れているかどうかは本を読むのと違って時間がかかる。
OOの手法だって事前にコード書いて練習したことだけが実践で使える。
それにツールにも癖があるから、「こう書くとうまく動かない」ということも事前に知ってなきゃいけない。
そうでないと本番でなかなかバグの原因がわからず無駄に時間を食ってしまう。
だから事前に使い込んでおくことが大事なんだよ。
ツールは自分の一部になるくらい使い込んでないとスラスラ書くというわけにはいかない。
こういうことをしないでOOがどうのとごたく並べるだけの奴につきあう必要はない。邪魔なだけ。
そんな奴はほっぽり出すか無視しとけばいいんだよ。
例えばWinDBGのようなデバッグツールは使い方うんぬんじゃないよ。
OSやCLRのデータ構造知ってないと使えないよ。
そのソースは日本語では手に入らないよ。
学ぼうとしない技術者はよくない。
ついでに無茶苦茶書籍読んでるやつはツールを使えないという
意味のわからない前提でコケにするのもよくないな。
残念だけど、20倍男が負けてるのは知識だけじゃないと思うよ。
689 ：
仕様書無しさん：2010/09/04(土) 03:39:45
お前ら、御託はいいから、さっさとものを作れよ。う・ご・く・も・の・を！
ぇーと、納期は来月末な。納品物はシステム一式と、設計書、テスト仕様書、操作マニュアル、
管理マニュアルな。運用前にエンドユーザ集めて説明会やるから。で、今回は先方の要望で、
イージービルダーとオープンウルトラを使って開発してくれってことなんで、宣しくな。
営業の奴等がこの暑い中、汗水垂らしてやっととってきた仕事だ。少しタイトだが、昨今の不況
の煽りでうちもカツカツだから。察してくれよ。リーダーは今日中にリソースの手配と計画書作っ
てくれ。
何？勉強させてくれだぁ？ んなもん休日にやれよ。
オブジェクト指向で、パターンで、最適解で、Win-Winで、みんなが幸せになれるだぁ？
綺麗に組めるだぁ？ 保守性が上がるだぁ？ お前の念仏で、みんなが救われるだぁ？
そうか．．．よし、わかった。お前ら疲れてんだな。しょうがない、今日はもう帰っていい。
明日からがんばってくれ、これ、やるから、ソープにでも行ってパーっと羽目外してこい。
だけどなぁ、言っとくぞ。俺たちゃ、おまんま食わなきゃいけねぇんだからよ。霞を食って生き
てるわけじゃないんだぞ。な？ 頼むわ。自分だけ満足できればいいってもんじゃないんだぞ。
悠長なことやってるヒマ無ぇんだわ。な？
これが終わったら気が済むまで勉強させてやるから。本も買ってやるから。な？
妄想や理想論は聞き飽きた。お前一人で作るならまだしも。こちとらチームでやってんだ。しかも
いろんな人間がいるぞ。真面目な奴。短気な奴。楽観的な奴。悲観的な奴。評論家気取りな奴。
俺を説得したいなら、人間工学と環境工学に基く客観的な分析と実績、失敗事例、成功事例、成功
の見込みとロードマップ、展望、計画を資料化して見せてくれ。それが嫌なら一生一人でシコってろ。
プライベートな時間を犠牲にしてって書いたよな。
忘れて長文読ませる前に見直してくれ。
２０倍男がおれより劣っているのは知識だけじゃないと書いたよな。
忘れて長文読ませないでくれ。
俺のような若造に見くびられたレベルで知識不要もないだろ。
今までのプログラマ人生何してたんだと。
え？ 念のため言とくけど、俺２６だけど、もしかして２０代前半の方ですか？
もしかして、１０代とか？ それだったらマジで尊敬しちゃうですけどぉ～w
なんだ、たいして変わらんってか俺のが上じゃないか。
頼むから俺の下に派遣なんてされるなよ。
お前は誰だ..
694 ：
仕様書無しさん：2010/09/04(土) 04:10:17
俺だよ、俺。
いや、車ぶつけちまってよ～。
わやじ、悪いが俺の口座に300万ほど振り込んでくれないか。
わやじ？ はて、聞いたことないな。
人違いだな。わしは、わやじなんて者じゃない。しかもうちには３００万なんて大金はないんだわ。
すまんな、他あたってくれや。
やる気なくなってきた。寝るわ。
バカホイホイスレです、ってスレタイに書いてあるのに、
なんでそんなところで必死になるかねぇ。
職人崇拝の人に聞きたいんだけど、
経営者もＰＭも、日頃から読書して理論を勉強している人よりも
たたき上げの経験者の下で働きたいってこと？
>>689 >納品物はシステム一式と、設計書、テスト仕様書、操作マニュアル、
>管理マニュアルな。
この中で、日頃から本を読んでいない奴が作れるものは「システム一式」だけだな。
他は全部「日本語」で書くんだろ？
読書の習慣がない奴の日本語は酷いよ。ほんとひどい。お話にならない。
読書が好きな人は
小説書くのもうまいからね。
英語の文法書ばかり読んでいないで、外国行って、身振り手振りでも
いいから積極的に外人とコミュニケーションとれってことだろ。
そうすりゃ、buttonはボタンじゃなくて、バドンって発音するん
だって自然と覚えっから。
バドンwww
アメリカに8年住んで技術コンサルタントやってたけど、
バドンなんて発音するアメリカ人なんて会ったことねえwww
バドゥンだろ
英語の文法書ばかり読んでいても発音はわからない。
音声対応の電子辞書じゃないと。
辞書に発音記号が書いてあるだろう
ネイティブがIPA通りに発音するわけねえだろw
アメリカだと元々世界中の人間が入り乱れてるんだから
多少発音が悪くたって話は通じる。中国系、インド系、フランス系、
別に日本人のカタカナ英語だけが特別なわけでもなく、みんな癖ある。
だけど結局、話し言葉はともかく、英文を書いて文法的にブロークンだと馬鹿だと思われる。
>>707 ここは日本である以上
そんな事いわれても実感がない。
日本人が英語勉強するなら教科書読んで文法から覚えないと駄目だろってこと
ネイティブが生活の中で自然と英語を身に付けているからといって、
そんなことは外人には関係ない
プログラミングも同じ
ガキの頃からヲタクでプログラムばっかり書いてました
中学生でＣＧＩゲー作ってＷｅｂサイト運営してました
みたいな奴は教科書なんか無しで何でもゴリゴリ書くだろうけど、
専門や大学でプログラム覚えてＳＥになりました
みたいな奴が、そういうネイティブの真似なんかしてたら３０引退コース間違いない
つまり、同じ水泳教室に通っていても
オリンピックに出場できる人と
ただの水泳好きで終わる人がいあるって話。
やぁ、みんな、今日も元気にシコシコと技術本を読んでるかい？
もう、今朝から１００ページくらい読んじっゃたかい？
本を読んでないと、不安になっちゃうよね。焦るよね。
本を読んでると、なんだか落ち着くよね。昨日より賢くなった自分に会えるよね。
本を読まない奴は、きっとそのうち技術についていけなくなって辞めてくんだろうな。
今のうちにせいぜい遊んどけっつうの。その間に俺はシコシコと読んじゃうぞ。
シコシコいいたいだけだろ
ふぅ、一冊読了。
ちょっくらアマゾンに書評書いてくっか..
ついエロいサイト見ちゃうと抜きたくなっちゃう
>>711 読んだ読んだ言ってるだけじゃなくて、
本当に読んだ方がいいぞ。
技術本で読んだ内容って、大概の事はその内忘れちゃうよね。
実践で使わない限り。
文章読んだだけで理解できたと思っちゃうやつ多すぎ
単純記憶だけは得意な奴は居るよな。
つか何故か日本ではそういう奴の方がSEとして重宝される傾向にある。
本当は逆なのにな。
鳩山邦夫とかな
アメリカのプログラマは相当な量読んでるが、
日本のプログラマは全然読まない。
アメリカに夢見すぎｗ
読むことが目的じゃなくて、得た知識でいいものをつくる事が目的なんだから、
読めばいいってわけじゃないわな。読む事より、つくる事が主体にならなきゃ。
いいものがつくれるなら、それが本を読んで得た知識によるものだろうが、
経験から得た知識によるものだろうがどーでもいい。
趣味の世界ならまだしも、読書量が多いことなんか自慢にゃならない。
客に、私はこんだけ読んだんですよ。とか言っても、はぁ。って言われるだけ。
読書は、目的達成のための手段のひとつに過ぎない。目的はあくまでも成果物だ。
結果が全てだ。
読書馬鹿にはわからないだろうが、遊びだって、実は仕事のいろんな場面で役立つ
んだぞ。客との折衝の場面での話題作りだったり、チームのコミュニケーションの
円滑化のためのスキルだったり、いろいろな人生経験から身につけることも多い。
読書馬鹿はひとりでやらせとく分にはいいかもしれんが、集団の中でうまくやってく
スキルに乏しい印象があるな。たまには、外に出て酒飲んだり女抱いたり車走らせたり
いろんなこと経験した方がいいぞ。
別に仕事のために生きてるわけじゃないからｗ
読書のために生きてんだよなw
読書と2chで己のアイデンティティーを辛うじて保っているのだよ。
読書から知識を得て人より優れているという安心感を得たいのだよ。
私から読書と2chをとったら自己が崩壊してしまうのだよ、きみ。
俺も本は読むけど、必要に迫られてって事の方が多いな。
実現したいことのやり方が分からない時とか、面白そうだなって思った技術の本とか。
でも、圧倒的にコードを書いてる時間の方が長いわ。プライベートでも。
727 ：
仕様書無しさん：2010/09/04(土) 22:46:38
本を読むことでは得られないものが経験から得られることがある。
逆もまた真なり。
読むことが目的化してるような奴は、どうせ読んでも成功しないだろう
何かのために本を読むとか考えるなよ。
本を楽しめよ。
そうだな
>>729 趣味の読書と、仕事で必要だから読むのは全然意味が違う。
趣味なら勝手にやってればいい。仕事なら必要最低限は読んで自分のものにしとかないと仕事がこなせない。
そこんとこごっちゃにしないように。
高度な論文を読んで理解した気になってもその人の研究を超える研究ができる人は一握り。
>>731 個人のスキルアップのためにプライベートで読む本の話だろーが。
仕事に必要で読むのは、それも仕事なんだから、仕事中に読むのが当然。
仕事は持ち帰って家でやってアタリマエ、とか考えてるタイプの人ですか？
あーあ
ここでゆとり君の登場か
ゆとりはないよりある方がいいぞ
企業戦士とか今時はやらんよ
企業戦士とかそういう問題じゃないｗ
家で仕事はしないよ。
趣味が仕事に役立つことはあるし、仕事で使った技術が面白くて趣味になることもあるが、
それでも家ではあくまで趣味。仕事じゃない。
連レス失礼。
どっちかというと俺の周りでは、業務時間中に本来の仕事から外れて
自分の趣味の勉強に時間使ってる奴の方が目に付くんだが。
お前らの周りにもそういう奴いない？
典型的な言い訳野郎
741 ：
仕様書無しさん：2010/09/05(日) 06:50:04
趣味は女装です
気持ちよさそうだな
Googleの20%の自由時間にプロダクトを作っているのを素晴らしいと思っている奴がいそうだな。
逆だよ。仕事とは別の20%の時間を使ってプロダクトを造らないといけない。強制だよ。それも仕事のうちだからな。
>>722 >読書馬鹿はひとりでやらせとく分にはいいかもしれんが、集団の中でうまくやってく
>スキルに乏しい印象があるな。たまには、外に出て酒飲んだり女抱いたり車走らせたり
>いろんなこと経験した方がいいぞ。
よくわからん前提で否定されたが、とりあえず家庭持ちバージョンで頼むよ。
>>744 いや、俺は普通にカウチポテトしてるが？
>>746 それやってるとすぐにデブデブになるぞ。ポテトチップ 1袋のカロリーはハンパじゃなく高い。
それに、プログラマーは体動かさないからてきめんに効いてくる。
>>747 だいじょうぶ。ヒルズ勤務っていう時点で女には困らんし。
とりあえず、今まで継続して技術書を読みまくって良かったこと
知識的、技術的にレベルアップした以外で列挙してみる。
上の世代が持っている今となっては懐疑的な考えに振り回されなくなる。
例えば、設計さえしっかりすればコーデングは指を動かすだけだとか、
プロトタイプは捨てなくてはならないとか、継承信仰とか、、、
入ってくる情報が頭を右から左にスルーすることが減った。
単に知識が幅や深さのせいだけじゃなく、その技術はここでは
自分が一番だという気持ちから生じる集中力や興味がらというか。
そういう意味では、早い時期に詰め込んで良かったかな、と。
読みながら賛成・反対したり自分の経験と照らし合わせたりということを
自然とやるものなので、自分の哲学を磨くことができた。
仕入れた知識を仕事で使う。これがフィードバックと評価のステップになる。
特にプロセスのようなある意味知識だけでなくやってみないと実感のわかない
方法論を客観的な視点でうまくいくかどうか試せたのは大きかったな。
あまりにも知ったかが多いことに気づいた。
自分の主張をあたかも一般論のように言う輩だ。
本当にうるさいときは黙らせることができる。
どうでもいいけど、派遣でなくても何の保証もない世界だから
自分の命くらいテメェで守れる力は持てよ、と。（意味不明）
ソーブ行く金に困らんってこと？
ソープいかなくてもやれるってこと。
>>749 長文の割に要領を得ない。そもそも文章の主語も分かり難いし、列挙
してみるとといっといて書き方が列挙になってないし、何だか無理し
て難しい言葉を選んでるみたいで、人をいらいらさせる書き方だ。
それでも一生懸命に想像力を働かせて読んでみると、文章の前後に
脈略がなく結局何をいいたいのかよく分らない。頭の悪さがよく滲み
出ている文章だと思う。
プロセスのような方法論ってなんだ？ 客観的な視点で試せた？
一体何の仕事してるの？ 客観的に試せたと言ってる割には主張が
全部主観的なのもパカっぽい。
本をいっぱい読んで自分は賢くなったはずだと妄信している典型的な
読書バカだな。
>>752 20倍男はもういいよ、、、
「典型的な＊＊」っていう言い方好きなんだと言いたいんだろ。
>>751 ヒルズというステータス目当てに寄ってくる尻軽女を相手にしてるってこと？
また出たかｗ
内容で勝てねえから文章であら探しｗ
ここでニートの登場か
757 ：
仕様書無しさん：2010/09/06(月) 02:20:40
読書君に負けたのがよっぽどくやしいんだなW
俺も２０倍の宿題待ってるんだがW
バカがみ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～るぅ
。
www
>>754 尻は軽いぐらいが丁度いい。
顔と体で選んでおいて、飽きたら交代すればいいし、便利だぞ。
鬼畜だな
素人童貞同士の笑えるなじりあい
堪能させていただきました
この程度で笑えるとか幸せな人生だな
楽しくて笑ってるのならな。
嗤われてんだよｗ
俺は嗤ってるんだ、と必死に思い込もうとしている様子が目に浮かぶようだ。
嗤う価値もないヤツを嗤えるとか幸せな人生だな
世間から嗤われ放題の素人道程の癖に恥ずかしくもないとは、幸せな人生だなｗｗ
おやおや、嗤っている主体が、「俺」から「世間」に変化したぞwwwwwww
おやおや
「素人童貞は恥ずかしい」
これは一般論ですよ。
マジで恥ずかしくないモンだと思ってるようですね。
真性かよｗｗｗ
でも真性童貞よりは恥ずかしくないだろ
クラブとか行ってる奴らの価値観だろｗ
知的な俺らにああいうフィーリングだけで生きてるカスの価値観押し付けられても困るｗ
知的ｗｗ
まいりましたｗ
おやおや、一般論ときましたか。
こんなスレで必死になっちゃってるあなたが吐く「一般論」ってなんなんですかね？
774 ：
仕様書無しさん：2010/09/06(月) 18:59:00
お、20倍か？
お前ら必死だなｗ
クラブに行く奴は頭が悪い？
よく恥ずかしくもなく自分の器量の狭さを宣伝してあるけるなw
776 ：
仕様書無しさん：2010/09/07(火) 00:17:55
クラブで踊ってナンパして振られてってのが、
男なら誰でも通る道だろ。イケメン以外は。
>>775 知的な人間はやすやすとアガらないんだよ
779 ：
仕様書無しさん：2010/09/07(火) 11:13:33
いや、普通に楽しいよ。
だいたい、楽しみ方を知らない奴に限って他人の趣味にケチをつける。
そして、無駄だのなんだのと自分の価値観を押し付ける。
行こうと思えば誰でも行けるんだから、
行ったこと無いのにクラブどうのこうの言うわけ無いだろ。
アホか。
>>781 すごーい。
「だから」で前後の文が接続されてない。
やっぱ、知的な人は言う事が違いますね。
知的な人が多くて、香ばしいスレだな
痴的だな
>>782 動機から考えれば当たり前のことだろ。
アホか。
人間のコミュニケーションは日常的に推理力を必要とするってこと覚えときな。
>>785 なるほど、知的な人は推論で話し合うんですね！参考になります！
クラブに何の恨みがあるんだよw
自分とは違う世界で美味い汁を吸ってる連中が居る状況ってのは僻まれるんだよ。
しかもあることないこと妄想した上、それを根拠に僻んでくるからタチが悪いｗ
>>787 音楽やダンスよりも、ナンパ、酒、薬、フィーリング、ルックス、
という全く知的でも文化的でも無い事がメインになっているゴミのたまり場とかしているからだよ。
>>788 凄く童貞っぽいよね。
>>789 そこに複数の価値が同時に存在する以上仕方のない事じゃん。
君のような人は「知的で文化的」な人たちだけが集まるユートピアを探しててくださいよ。…多分存在しないけど。
>>790 ライオンズクラブみたいな集団もあるよ。
>>790 ああいうところはむしろ一つの価値観で一体となって盛り上がるところでしょうが。
いろんな価値観は認められないよ。
あんなところでクソ堅苦しい政治議論みたいなのをはじめてみ？
キモがられるからｗ
興奮状態の人間の観察をて楽しんでいる人が居るかも知れん。
まぁ知的な場所かと言われりゃ違うと思うが、全否定はない。
ごく少数であれマイノリティが居る可能性は忘れちゃならん。
ぶっちゃけどうでも良い。
知的知的と自分を推してるような人種は、実は社会においてあまり美味しい立場になりえない。
成功者、つまり美味しい立場になるためには何が必要なのかを正しく知っている者はおろか、
何も考えるず一身に情交してる人種の方が美味しい立場にすら見えてくる。
だから妬む。
悲しすぎる人生である。
>>791 そうだね。
でも、全部とは言わないけど、善意のオブラートで包んではいるが、単なる利害関係のつながりでしか無いでしょ。
>>792 そう？
音楽を楽しんむ、ナンパを楽しむ、踊りを楽しむ、酒を飲んで楽しむ、友達と過ごす空間を楽しむ、跳ねてストレス発散する、
遊び疲れた夜明けの今日が終わるのがちょっと惜しい儚さを楽しむ、そこに存在するニーズを分析して楽しむ。
パッと思いつくだけでも色々な価値が同時に存在してるけど？
何で政治議論？まぁ、それもシチュエーションによってはありだと思うけど？
>>795 ああいう場所ではごく限られた価値観しか無いんだよ。
もちろんライオンズクラブだって限られた価値観の集まりだよ。
ナンパやセックスに興味がある人間の集まりに対して、
セックスを最大重視する奴らだ、と言って間違いではないだろ？
>>796 ああいう所(クラブ)に集まる奴の多くは
似通った目的の為に集まっているっていう主張なのかな？
少なくとも自分の仲間内はもっと貪欲な奴ばかりだから同意出来なかったけど、確かに自分の側は少数派だと思うよ。
深夜位セックスを最大重視してもいいだろw昼間からじゃないんだからw
いいじゃん、たまにクラプに行ってハメ外すぐらい。
ストレス発散ぐらい知的にやらなくていいだろ。
799 ：
仕様書無しさん：2010/09/07(火) 23:21:59
セクスなんてどうでもいいから
ごみの分別の話しようぜ。
>>797 ところがこのスレのようにオブジェクト指向の話題で集まっている集団では
セックスは大した重大事じゃないんだよ。
だから
>>750-770のような価値観はこのスレでは間違いなんだよ。
ゴミの分別めんどくせーよなー
>>800 お前友達少なそうだな。
現実を理想に近づけたいなら、仕組みを作れよ。
みんな雑談しかしてないっていう現状から考えて、君の主張の方が非現実的なんだよ。
ヤサイ好きですが、何か？
何も。
きっと、OOは知的か否か、という話に繋げる伏線に違いない。
上でOOは学問的じゃないという下りがあったから、その話の続きか。
808 ：
仕様書無しさん：2010/09/08(水) 12:01:18
暴風警報でおやすみage
>>789 うちのクラブはコンピューターオタクやゲームオタクばっかりだったが・・・
それはクラブじゃなくて、クラブのことでしょ。
ここで言ってんのはクラブの方だよ。
蟹？
オタクはクラブに行かないってのは偏見でしょ。
アクティブなオタクもいるし。
「オタクのステレオタイプ」っていうのはテレビ局の印象操作だよ。
テレビ局っていうのは音楽やダンスやお笑いなどの芸能を売っているわけで、
それら「以外」に興味を持っているオタクはダサいあるいは文化的でないという印象操作を
行うのは動機的に筋が通っているよね。
アニメももちろんテレビ局が扱うコンテンツの一つだけど、これは放送時間的にも短いし、
制作側はたくさんいるんだけど、実際にテレビに関わってくる人っていうのは
バラエティ番組や音楽番組などに比べると極端に少ないため、あまり力がないのかもしれない。
公平な見方をすれば、
ファッションや音楽って、いわば単なる一つの趣味に過ぎないし、
もちろんプログラミングや漫画・アニメなども一つの趣味ですよ。
ファッションや音楽に興味がない人をキモイと称するのはちょっと不公平な印象工作だと思う。
オタクとはファッションや音楽以外の趣味を持っている人
という定義でいいよね
>>814 いや…
オタクとは、ファッションや音楽以外の趣味しか持っていない人。
の方が正しい気が。
ファッションオタクや音楽オタクやダンスオタクもいるだろ。
オタクと言うから印象が悪い。
Geekと呼んでくれ。
テレビ局の印象工作という意見には賛成
よく分からんから、オタクとクラブとセックスとオブジェクト指向とテレビ局の関係をUMLにおこしてくれ。
821 ：
仕様書無しさん：2010/09/08(水) 19:33:01
あと、ごみの分別も。
このスレ年齢層低そうだよなw
オタクという言葉は、一般認知される以前は非常にキツイ侮蔑語であって、
使う場合は言う方も言われる方も喧嘩覚悟の上ぐらいの勢いだったが、
そのうちオタク自ら、アイデンティティーの証かのように自称し始めたんだよｗ
その辺は逆にテレビの恩恵なのではないかとｗ
20前後じゃないか？
音楽は流行歌で満足できなくて、色々探して先鋭化したらいつの間にかアニソンや
電波ソングに行き着いたな。
アニソンとかエロゲソングって曲にストーリーがあって、
それが本編と繋がってるから楽しめるんだよね。
最初聞いたときつまらない曲だなぁと思って、クリアしたあとにもう一度聞いてみると
良い曲だと思ったりすることはよくある。
828 ：
仕様書無しさん：2010/09/09(木) 04:15:56
オレのスレに来ないで。
このスレ、もう次スレいらないな
スレタイから頭悪いしな
そりゃまともな話になんがならんわ
学問的な話のとっかかりとしては、岩波から出た（たぶん絶版じゃないかという気がするが）
「オブジェクト指向コンピューティング」がいいと思う。
まあ止めとけ。
オブジェクト指向を極めたところで、日本には活かせる現場はない。
そのままじゃ日本は終わるけどな。
既に終わってるけどな
x このスレ年齢層低そうだよなw
o このスレ精神年齢低そうだよなw
古いビジネスモデルはいずれ終わり、新しいビジネスモデルに取って替わられるだけ。
それが日本て国は、いつまでも過去に縋りつく勢力が抵抗勢力として居座り続けるという、悪い慣習があってだな
つうか、オブジェクト指向自体が既に古い技術なのだが。
今は何指向ですか？
840 ：
仕様書無しさん：2010/09/09(木) 21:20:10
コンポーネント思考
サービス指向
これから10年ぐらいは統計的手法の時代だよ。
たかがプログラミング言語で技術どうこう言える素朴な時代はもう終わった。
バズワードの時代だろ。
適当に言葉作って、とにかく金集め。
ああ、クラウドね。
バズワードはいつの時代もあるだろ
846 ：
仕様書無しさん：2010/09/09(木) 22:21:48
まあオブジェクト指向ってだけで
未だに脊髄反射で批判し始める化石はマジ勘弁だな
お前の欠点はオブジェクト指向とかどうとかじゃなく
お前の頭が弱いだけって話しなんだけど。
847 ：
仕様書無しさん：2010/09/09(木) 22:34:21
Please send your progress report by the end of the day.
848 ：
仕様書無しさん：2010/09/09(木) 22:35:32
It's demo, It's demo, Curry ware, He done lee kick it,
What a she know, What a she know, Car ray ware, He durty kick it,
おまえ必死だなｗ
そんな事よりクマグスのメイドが酷い
クソすれになってきたｗ
オブジェクト指向の存在自体が面白くない奴の工作が思う通りになった結果だろう。
こんなトコで暴れたって、何も変わりゃしないのになｗ
>何も変わりゃしないのになｗ
2chでこんなレスが見られるとは思わなかった。
バリバリOOPで仕事してるけど。
わざわざスレ立てて話すほどの内容がないだけなんだが。
騒いでる奴は物事の本質が見えていないだけ。
>>854 クラスライブラリ使うだけのOOPと、考え方から設計までOOP思考でやるのと、どっちですか？
>>855 うるせーな、後者だよ
使うだけならOOPって言わねーだろ
最近ムツゴロウみないな。
オブジェクト指向プログラミング思考
つまり残念ながらまだ研究段階ってことか
つうか、もうドカタ段階。何の差別化にもならん罠。
聞こえねえ。
OOPなんて言っても工夫しだいでいろんな実装があるんだから充分差別化できる。
856みたいな短気な奴が作ったプログラムは構造も通り一遍だろうから差別化が難しいだろう。
それにお客から見れば内部がどうなっててもわからないから、見た目が良くて納期通りにできてバグなしなら満足するさ。
>>863 書き方を変えただけで本質は変わらないって話をしたつもりなんだが。
君には理解出来なかったみたいだね。
エスパーご苦労様。
「本質」って言う奴の99%は「俺の定義」の意味なんだよなw
そうかな、反発する奴ほど俺様定義の気がするんだが。
そして脊髄反射で反発するけど、反論は出来ないという。
繰り返すけど、本質はOOP以前から変わっていないよ。
コンピュータの本質は、「いかに効率よくCPUを動かすか」の歴史だろ。
お世辞にもOOPが効率いいとは言えない。
フルアセンブラで一品物を作るよりも
記述は人間寄りでコンパイラで機械寄りにするほうがいいだろ
メンテナンスや拡張性のないソフトは勿体無い
>>867 PGはコンピュータの奴隷なんですね。わかります。
>>867 速度を要求されるものにおいてはね。
トレードオフになる要求もあるから、そこまで単純ではないと思う。
>>867 今時のJITのほうが、君のハンドアセンブルよりも実行効率のよいコードを吐くと思う。
>>870 Inteコンパイラの最適化技術は速度最優先でやってるようにしか見えない。
作りやすさ重視では普通に作っても遅くて使い物にならなくなりやすいからね。
別にフルアセンブラでなくても高速化は充分可能。
今はマルチコアCPUが普通になってきているから、複数のコアを無駄なく動かすことができればさらに高速化できる。
シングルコア時代の高速化の考え方だけでは古くなってきている。
速度を考えずに作りやすさしか考えないOOPプログラマーはCPUレベルでどれだけ無駄なコードが動いているか
知ろうともしない。
>>872 並列FORTRANの時代ならともかく、
その手の話はコンパイラの仕事になってきていることに気付かないほど
技術動向に疎いのですか？
＞コンピュータの本質は、「いかに効率よくCPUを動かすか」
はいはい、数千ステップのシステム作るのに何百億も掛けていた時代の人は帰っていいよｗ
>>874 じゃ、俺はそっちにつこうかな？
数千ステップのシステムで何百億もとってこれるならそっちのが職がありそうだ
>>875 8本のトグルスイッチと1個のプッシュボタンでのプログラミングを楽しんでくれたまえ。
ミニコンだとワードは16ビットとかのほうが多いかな
>>875 まずは、タイムマシーンを作らなければならないという、超難関が待っているぞｗ
リソースが無限にある世界で生きてる人達が羨ましいっス
無限にはないけどOS様が最後はなんとかしてくれる世界はいい
OS様がいない世界で自由を謳歌したい。
ゲームだが、MS-DOSの時代は、MS-DOSを使いたくないんで、自分で作ってたな。
つても自前で作ったHWを直接叩く系のEXEだけ動けばいいので、
中身はほとんどファイルIOだけだったけど。
で時代はHDDインスコの時代になっちまって、おわた。
最近の組み込みだとFlash化したものだから
書き換え用プログラムもつくらにゃいけないから面倒
携帯や組み込みのやつらはJavaのバイトコードもJITでどんなアセンブラにされるか
予想して組んでるよな
そんなことやるのはゲーム屋と組み込みやくらいだろうが(OS屋もか
しかし、楽天の分散DBのROMAだっけ？高速なKVSとかいってRubyで実装してて笑える
流行だからとそれに乗る人が多いほど仕事は安くなる。
他人がやらない特殊技術をやる人だけが大きな利益を得るもんだ。
そんな簡単なことにも気づけない874みたいなのがいるから俺は楽して食えてるw
特殊技術が特殊技術でなくなったとき
仕事はなくなる。
889 ：
仕様書無しさん：2010/09/13(月) 00:02:10
知識労働すべきでないレベルの人間が設計をやっている。
この職は入口の壁が高いわけではないから、
完成品の品質をそういう輩に下げられて困る。
>>888 その頃にはたっぷり儲けてさっさと引退してるからいいのさw
同じ仕事がいつまでもあると思ってるようじゃ最初から負けてるだろ
ただ、ソフト作りの基本を身に付けてれば意外に長く応用できたりするもんだ。
逆に、本質を知らないまま流行を追いかけてるほうが寿命は短いと思うよ。
ソフト作りこそ常識がめまぐるしく変化するものはない。
基本とか本質とか言ってる奴は、レガシーな開発手法とともに消え去るのみ。
892 ：
仕様書無しさん：2010/09/13(月) 02:14:32
おまえら必死だなｗ
893 ：
仕様書無しさん：2010/09/13(月) 02:27:18
「ソフト作りこそ」っつーか単に業界が成熟してないだけだな。
>>890 本質を知って流行を追いかければいいのでは？
なんでも自分の都合の良い人物像を
仮定しないほうが良い。
まあ、javaグラマには無理な話だけどなｗ
言語に潰されたプログラマってこの言語が初めてじゃないだろうか？
なに言ってんだこの馬鹿？
流行ってのは作る人と追いかける人しかいないんだよ。
お前らどっちがいい？
>>894 そう言うのは簡単だｋど、変化が激しい業界ほど長く生きるのは難しい。
芸能界だと毎年1000人新人が出て翌年まで生き残るのはほんの数人。
それに比べればソフト業界は緩いがそれでもその変化に10年以上ついていけるのはかなり少ない。
あんたはその自信があるんだな。
フーリエ変換って難しいな。
誤爆った…
最近のゆとりは、九九だけじゃなくフーリエ変換もろくに知らないのか・・・
そういうおまいも、誰かのコピペを動かしただけで、マスターしたつもりになってるだけだろ。
903 ：
仕様書無しさん：2010/09/13(月) 18:10:17
おまえら必死だなｗ
おまえ余裕だなｗ
ほんと達人ばかりだな
技術の話ではあるが、思想の話であって、職人芸ではないので、
次のスレタイから「達人」は削除すべきだろう。
EXEなんて簡単な構造だよ。
ヘッダ部に各セグメントへのオフセットが書いてあるので、
丸ごとメモリーに打ち込んだら、各レジスタ用に計算して
CPUに叩き込んでやれば、もう実行だ。
その後の管理は一切出来ないので、
後は野となれ山となれだがｗ
>>908 DOSじゃないのに、わざわざEXE www
わざわざって程手間か？
寧ろ普通に作るとEXEだろ。
> 寧ろ普通に作るとEXEだろ。
腹イテwww
厨臭いのが混ざってるな
中身はuyかな
うん。そうだな。プロならCOMだよなｗｗｗ
コンポーネント・オブジェクト・モデル？
単にメモリーにスタティックにロードするだけでいいのに、んなもん使うかよ。
拡張子COMの意味だろう。
その程度かよ。
むしろ、ELFで
ＣＯＭモデルは８０８６時代の規格だから、セグメントの概念が無いぞ。
918 ：
仕様書無しさん：2010/09/14(火) 00:37:26
で、どこがオブジェクト指向の達人なんだ？
つ 自称
オブジェクト指向なんてものはコンピュータの長い歴史の中ではほんの上澄みに過ぎない。
長い歴史のほとんどはCPUや周辺機器との格闘の歴史であって、そう簡単にそこから離れることはできない。
オブジェクト指向を究めると、人間とかが只の物質以上の存在に見えるようになるらしい。
>>920 コンピューターの歴史なんて、1949年にEDSACが出て、1970年にはsmalltalkの
開発が始まってるわけだから、オブジェクト指向自体は新しい概念じゃないぞ。
matzが見てるぞここ
CPUや周辺機器との格闘をしてる人など、どんな時代にでも居る。
ただ、居るからといってCPUや周辺機器との格闘が出来なければ、
コンピューターを使ったシステムをデザイン出来ないなどと考えるのは、
いかにもシステムデザインのセンスが無い人の意見だな。
広義でシステムを捉えるのなら、ある状況下においてはその通りだろうな。
だからと言って知らなくてもいい訳ではないけど。
>>902 はあ？今時、馬鹿はコピペなんて使わないだろうが
馬鹿はコピペするまでもなくオプソで常にバグとりされてるライブラリを使う
馬鹿になるためには、ライブラリを使うために「使う側のOOP」を覚える
馬鹿も大変なんだよ
927 ：
仕様書無しさん：2010/09/14(火) 23:09:55
オブジェクティブクラウドインターフェイス（ＯＣＩ）を提唱します
♪ いえーーーいMatzみてる～～～？？
☆ノハヽハヽ☆ ♪
从* ’ｗ’） )
彡 ⊂ つ つ ミ クルクル
(( ⊂、 / ヽ _つ ))
ミ ∪ ≡ U′
>>923 まじで？
雑記
_,,..r'''""~~`''ｰ-.､
,,.r,:-‐'''"""~~`ヽ､:;:;:＼
r"r ゝ､:;:ヽ
r‐-､ ,...,, |;;;;| ,,.-‐-:､ ヾ;:;ゝ
:i! i! |: : i! ヾ| r'"~~` :;: ::;",,-‐‐- `r'^!
! i!. | ;| l| ''"~~ ､ i' |
i! ヽ | | | ,.:'" ､ヽ､ !,ﾉ
ゝ `-! :| i! .:;: '~~ｰ~~'" ﾞヾ : : ::|
r'"~`ヾ、 i! i! ,,-ｪェI二エﾌﾌ : : :::ﾉ~|`T ＜イエーイ、matzさん見てるー？
,.ゝ､ r'""`ヽ､i! `:､ ー - '" :: : :／ ,/
!､ `ヽ､ー､ ヽ‐''"`ヾ､.....,,,,＿,,,,.-‐'",..-'"
| ＼ i:" ） | ~`'''ー---―''"~
ヽ `'" ノ
Twitterでこのスレの内容を引用している人がいて、それをさらに転載してた
931 ：
仕様書無しさん：2010/09/15(水) 00:50:07
引用するほどの内容も無いスレなのにｗ
暇つぶしにもなんね
暇つぶしてるじゃんw腹いてwww
933 ：
仕様書無しさん：2010/09/15(水) 03:04:41
だめな設計者ってインタフェースうまく使えないよね
オブジェクト指向など、ソフトと格闘をしてる人はどんな時代にでも居る。
ただ、居るからといってソフトと格闘が出来なければ、
コンピューターを使ったシステムをデザイン出来ないなどと考えるのは、
いかにもシステムデザインのセンスが無い人の意見だな。
>>922 ソフトウェアのいろいろな概念はLISPなども含めて初期の頃からいろいろある。
それらは実験的だったり研究者の興味で作ったものなどさまざま。
しかしだからと言ってそれらは実用敵なソフト開発の主流にはなってこなかった。
OOPはCPUが速くなった現代だから何とか使えるようになったが、
それで開発して顧客から遅いと言われたとき、簡単に速くすることができないという致命的欠点がある。
バグ潰しと違って納期内に目に見えて軽く動くように改善するのは難しい。
サイズもでかいからキャッシュからはみ出すこともあってますます遅くなる。
小さくコンパクトに作れれば、ただでさえ速いし、全部がキャッシュに入るからさらに軽く動く。
だから今でも小さく軽く速く作れるソフトが必要なんだ。
936 ：
仕様書無しさん：2010/09/15(水) 04:55:49
ドメイン駆動について詳しい人いるか？
ドメイン駆動のスレに行くか、無ければ立ててください。
>>934 ＞オブジェクト指向など、ソフトと格闘をしてる人は
おまえ、まず、オブジェクト指向が何かを勉強してくること。
それまでは出入り禁止だｗ
>>935 簡単に速くすることができないのは激しく同意だが、OOPとの関連性がわからない
OOP使わなければクリティカルな影響が出て速くなる場面がなかなか想像できない
ゲーム屋さん？
Web屋だとほとんどIOやDBがネックになるし、台数増やせばOKな場面ばかり。人件費高いからな
そもそも、
>>935 の前提ならOOPしなくても比較的遅いLLなんて普及してないだろｗ
どうしても、並列処理で処理稼ぎたいなんてときは他の言語使うだろうし
例えば、OOPだと開発効率が悪いとか、OOPがいいという技術者はクソのようなLinuxみたいな考え方はわかるんだが
小さく軽く速く作れるよりも、早く作れてスケールできればいいんではないのか？
>>940 早く作れてスケールすることで逃げられればいいんだが、現実には予算が足りないとか時間的に間に合わないなど
問題山積みでうまくいかないことが多い。それくらいなら最初から小さく速く動くように計画して作ったほうが安全で確実。
>>939 たとえばオールJavaで作った売り物のゲームなど聞いたことがないんだが。
iアプリやAndroidのゲームって全部Java製だろ。
超上級
------------------
上級
------------------
中級
------------------
初級
------------------
ダメ
インタフェースが巧く使えない
------------------
ここまでアスペクト指向の話は皆無。
いや一瞬あったか…
>>944 インターフェースはいらないのですね、分かります
>>945 議論するほどの中身がない。
そして、ここの達人にはわからないんじゃないかなw
ここの住人には無理
俺の尻がアスペクトした
いまいち
ドメイン駆動も無理
おまえドメイン駆動言いたいだけだろ。
読んだばかり本に書いてあったか？
どっか他のスレでも見かけたな
実は意味を知らなかったビジネス用語ランキング
1位 クラウドソーシング
2位 CSF
3位 バズマーケティング
4位 ロングテール
5位 CPC
6位 BSI
7位 ブレスト
8位 B2C
9位 B2B
10位 ステーク・ホルダー
．．．ゆとりが浸透してきたな
アスペクトなんて全社的に使いこなしてる会社なんてあるのか？ 言葉だけだろw
インジェクションとアノテーションを使いこなせれば
アスペクトをマスターした気分が味わえます。
注入するぞ。
注入するぞ。
注入するぞ。
注入するぞ。
注入するぞ。
注入するぞ。
注入するぞ。
注入するぞ。
注入するぞ。
注入するぞ。
そのくらい知ってるぜ
という返しはできないんだなｗ
できるけどしない。
良く分かってない上層の命令でインジェクションを導入するけど、
下も良く分かってないので、使う側と使われる側が
密に連絡を取り合って仕様を決めてしまう。
結局、手間が増えて工数が掛かるだけの代物と化す。
それが日本の現場におけるインジェクションの実体。
まさにブタに真珠の世界ですね
ブタどもにDIは過ぎたオモチャだわ
リフレクションとか使いまくりで重いし、リソース喰いだし。
何事も幸せになるには、何かを犠牲にしなければならない。
世の中のスピリチュアルな人々の幸せのための犠牲がプログラマだ
日本は精神的には未だ士農工商の時代ってことだよ。
通常では最下層身分のSEだが、わざわざ
無理矢理お粗末なPJをこしらえては人足を雇い、
上の身分の気分を味わいたいという構図なのさ。
つまり現代の得た否認＝PG
まあ、そんなウンコPJのために大金払わされるクライアントが
一番のババを引いている訳だが。
幕僚がクズだらけだった旧日本軍の兵士達も同じ気持ちだったんだろう
まさに fubar ですなｗ
あ、てことは米軍も同じ？？
967 ：
仕様書無しさん：2010/09/16(木) 20:11:34
俺くらいの優秀なオブジェクティブプログラミンガーになるとコード書かないでも動くようになる
968 ：
仕様書無しさん：2010/09/16(木) 20:15:50
プログラミンガーｗ
969 ：
仕様書無しさん：2010/09/16(木) 20:16:57
で、まとめると、
ここにはオブジェクト指向の達人はいないからわからない
でいいか？
まぁ焦るなよ。まだ30レス以上ある。
ゆっくりまとめようぜ。
971 ：
仕様書無しさん：2010/09/16(木) 21:09:45
オブジェクト指向の達人は
屁を５回連続でだせるくらいスゴイ
972 ：
仕様書無しさん：2010/09/16(木) 21:12:37
オブジェクト指向の達人ならば
ハエを箸でキャッチできる。
オブジェクト指向の達人には、世の中のあらゆるもの同士を繋いでいる関連線が
実際に見える。
調子がいいと線の根っ子に多重度が見えたり、線の上に浮かぶノートが見えたりする。
調子が悪ければ見えないなら達人じゃねえわ
弘法も筆の誤りですよ
976 ：
仕様書無しさん：2010/09/16(木) 22:15:33
豚にかかと落としですよ
ハエにウンコですよ。
猫に小判ですよ ←このスレのまとめ
979 ：
仕様書無しさん：2010/09/17(金) 00:10:55
オブジェクトシコシコ
980 ：
仕様書無しさん：2010/09/17(金) 00:21:47
いぬもあるけばつかれる
実装における具体面でしか語りきれてないと言うのならば、
まだこのスレは、オブジェクト指向の優位性の
ほんの一部にしか辿りついてないと言えるだろう。
983 ：
仕様書無しさん：2010/09/17(金) 02:15:35
つまり、設計における抽象面を語れと？
ここで、包丁もろくに扱えない料理評論家の登場か懼
>>966 別板のコテで、戦後駐留してきた米兵から配給品を受け取ろうとしたときにいくつ
あるか分からずに、数えさせようとしたら九九も出来なく、そんなにに負けたのかと
愕然としたとかいう書き込みがあったな。 多分、今も最下層くらいは同じ位だろ。
>>981 羽生の将棋見てると同じことが体験できるよ。ときどき局面と全然関係ない駒を動かすんだけど、
そのときは解説者も意味がわからず、かなり手が進んでから
「 そ う い う こ と だ っ た の か あ ～ ～ 」
とわかる。それくらい一流の頭を持った人がOOで設計やったらすごいと思うよ。
でもプログラマー全員がOOで考えようとするのはあまり意味がない。
オーソドックスに構造化でしっかり書いたほうがまともなコードが書ける。
