アルファルファモザイクは移転しました。
最新の記事、コメント等は、順次反映していきます。
新URL:http://alfalfalfa.com/
新RSS:http://alfalfalfa.com/index.rdf
1 仕様書無しさん :2007/07/26(木) 00:41:39
なぜオブジェクト指向は嫌われているのか?
http://pc11.2ch.net/test/read.cgi/prog/1183255047/
なぜオブジェクト指向は嫌われているのか?2
http://pc11.2ch.net/test/read.cgi/prog/1184258633/
スレ違い多発注意。
・教育論
煽りは華麗にスルー推奨。
3 仕様書無しさん :2007/07/26(木) 00:46:57http://pc11.2ch.net/test/read.cgi/prog/1183255047/
なぜオブジェクト指向は嫌われているのか?2
http://pc11.2ch.net/test/read.cgi/prog/1184258633/
スレ違い多発注意。
・教育論
煽りは華麗にスルー推奨。
オブジェクト指向を導入してる、という現場で見たのは、
わからんちんが混乱して、理解してる奴のフォロー負荷が高かったということ。
4 仕様書無しさん :2007/07/26(木) 00:59:40わからんちんが混乱して、理解してる奴のフォロー負荷が高かったということ。
やっぱ、OOよりC言語でカーネル、デーモンいじりほうがめがっさいいだろ。
ま、>>1 乙
6 仕様書無しさん :2007/07/26(木) 01:14:45ま、>>1 乙
>>4
激しく同意なんだが、そうもいかないんだよな。
長くカーネルいじりした後でバリバリOOの話になったときにこまんね?
まあカーネルに強い奴はそれほど困らないかもしれないが。
激しく同意なんだが、そうもいかないんだよな。
長くカーネルいじりした後でバリバリOOの話になったときにこまんね?
まあカーネルに強い奴はそれほど困らないかもしれないが。
15 仕様書無しさん :2007/07/26(木) 20:32:58

オブジェクト指向の問題点 1/2
・クラスが増えすぎる
→ 単純すぎる機能のためにクラスが作られる(いわゆる『低脳クラス』)
→ 例:キーと値のペアを保存する型が欲しい!⇒Bean
文字列の分割がしたい!⇒Tokenizer
→ しかも再利用できず、再入可能性も無く、状態も持たなかったりする
→ そもそも独立したクラスであるべき理由すら無い
→ 目的の機能(メソッド)を持っているクラスを探すのが面倒
たとえば、 ファイル操作という当たり前の機能のために、5個以上のクラスを使ったりする
→ クラスのことで頭がいっぱいになり、例外処理などの本当に重要な部分が疎かになる
→ くだらない例外やエラーでシステムが落ちる
・機能が複数のファイルに分散しがち
→ 依存関係が複雑になりすぎる(可視化が難しいことがさらに問題を深刻化させる)
→ 役立つ機能があっても、他のソースに絡み付いていて部品化できない
→ 最初からプロジェクトを本体とライブラリに分けてしまえば多少はマシになるが、
それはそれでクラスが分散するため、複雑化に貢献してしまうこともある
→ インターフェイスが把握し辛い
→ 本当に重要な(非常に多く使われている)メソッドと、そうでない『おまけ』メソッドの区別がつかない
→ 大抵は、書いた本人もよく分かっていない
→ まともなサンプルを見るまで誰も満足に使えない
16 仕様書無しさん :2007/07/26(木) 20:34:52・クラスが増えすぎる
→ 単純すぎる機能のためにクラスが作られる(いわゆる『低脳クラス』)
→ 例:キーと値のペアを保存する型が欲しい!⇒Bean
文字列の分割がしたい!⇒Tokenizer
→ しかも再利用できず、再入可能性も無く、状態も持たなかったりする
→ そもそも独立したクラスであるべき理由すら無い
→ 目的の機能(メソッド)を持っているクラスを探すのが面倒
たとえば、 ファイル操作という当たり前の機能のために、5個以上のクラスを使ったりする
→ クラスのことで頭がいっぱいになり、例外処理などの本当に重要な部分が疎かになる
→ くだらない例外やエラーでシステムが落ちる
・機能が複数のファイルに分散しがち
→ 依存関係が複雑になりすぎる(可視化が難しいことがさらに問題を深刻化させる)
→ 役立つ機能があっても、他のソースに絡み付いていて部品化できない
→ 最初からプロジェクトを本体とライブラリに分けてしまえば多少はマシになるが、
それはそれでクラスが分散するため、複雑化に貢献してしまうこともある
→ インターフェイスが把握し辛い
→ 本当に重要な(非常に多く使われている)メソッドと、そうでない『おまけ』メソッドの区別がつかない
→ 大抵は、書いた本人もよく分かっていない
→ まともなサンプルを見るまで誰も満足に使えない
オブジェクト指向の問題点 2/2
・デバッグし辛い
→ 過度のカプセル化(あるいは情報公開機能の欠如)のせいで問題点が把握できない
→ さらに、あまりにも多くのオブジェクトが絡み合った構造体が作られる
→ テキストとしてダンプできない
→ 人間が読めない
→ ダンプできるようにしたくても、修正すべき箇所が多すぎる
→ しかも半機械的な作業だったりするので、誰もやりたがらない
(※よくアスペクト指向によるソリューションが語られるが、それもまた対症療法でしかない)
→ 生成方法が存在しないか、生成が難しい『謎の』オブジェクトがある(例:HttpServletRequest)
→ これらに依存していると、そもそも単体テストができない
・オブジェクト脳になりすぎて、『サブルーチン的』な解決策に目が向かない
→ 例外処理のためにコードがどんどん縦に伸びていっても、何も感じない
→ 同じようなコードのコピペが繰り返されていても、
『こういうフレームワークだから』で納得してしまう
→ オブジェクト指向を部分的に捨てて共通関数ライブラリを作れば
劇的にコードが読みやすくなるのに、それをしない。
→ にも関わらず、単機能のいわゆる『低脳クラス』を量産する
20 仕様書無しさん :2007/07/26(木) 21:06:20・デバッグし辛い
→ 過度のカプセル化(あるいは情報公開機能の欠如)のせいで問題点が把握できない
→ さらに、あまりにも多くのオブジェクトが絡み合った構造体が作られる
→ テキストとしてダンプできない
→ 人間が読めない
→ ダンプできるようにしたくても、修正すべき箇所が多すぎる
→ しかも半機械的な作業だったりするので、誰もやりたがらない
(※よくアスペクト指向によるソリューションが語られるが、それもまた対症療法でしかない)
→ 生成方法が存在しないか、生成が難しい『謎の』オブジェクトがある(例:HttpServletRequest)
→ これらに依存していると、そもそも単体テストができない
・オブジェクト脳になりすぎて、『サブルーチン的』な解決策に目が向かない
→ 例外処理のためにコードがどんどん縦に伸びていっても、何も感じない
→ 同じようなコードのコピペが繰り返されていても、
『こういうフレームワークだから』で納得してしまう
→ オブジェクト指向を部分的に捨てて共通関数ライブラリを作れば
劇的にコードが読みやすくなるのに、それをしない。
→ にも関わらず、単機能のいわゆる『低脳クラス』を量産する
>>15-16
いいたいことはよくわかるが
それって実装の都合で適当にクラス作って膨れ上がっただけじゃね?
もはや、当初の設計図などは無視で機能追加による継承とか使いまくった後だろ?
要はオブジェクト指向をよくわかってない奴が組んだソースだな
41 仕様書無しさん :2007/07/26(木) 22:20:15いいたいことはよくわかるが
それって実装の都合で適当にクラス作って膨れ上がっただけじゃね?
もはや、当初の設計図などは無視で機能追加による継承とか使いまくった後だろ?
要はオブジェクト指向をよくわかってない奴が組んだソースだな
>>15,16
あるある。
良くまとめたな。乙
27 仕様書無しさん :2007/07/26(木) 21:32:36あるある。
良くまとめたな。乙
設計だっつのに実装テクばっかり披露してくれる人が多いんだよ。このスレ
29 仕様書無しさん :2007/07/26(木) 21:36:53>>27
技術的背景を無視した上っ面だけの糞設計のせいで、プログラマが
アーキティクチャレベルから再設計しなきゃいけなくなるんだよ……。
31 仕様書無しさん :2007/07/26(木) 21:43:05技術的背景を無視した上っ面だけの糞設計のせいで、プログラマが
アーキティクチャレベルから再設計しなきゃいけなくなるんだよ……。
良い実装ってのは割と自明だよな
良い設計ってのはどんなだ?
32 仕様書無しさん :2007/07/26(木) 21:45:44良い設計ってのはどんなだ?
設計と実装の切り分けができない状態で
オブジェクト指向なんて覚えようとするからおかしいことになるんだな
33 仕様書無しさん :2007/07/26(木) 21:46:18オブジェクト指向なんて覚えようとするからおかしいことになるんだな
良い設計とは、渡されたコーダが、
思わずにっこりと微笑むような設計。
34 仕様書無しさん :2007/07/26(木) 21:50:07思わずにっこりと微笑むような設計。
良い設計は、基本に乗っ取った設計を元に、
コーダの利便性を考慮したような独自色を微妙に盛り込んでくれているもの。
35 仕様書無しさん :2007/07/26(木) 21:51:25コーダの利便性を考慮したような独自色を微妙に盛り込んでくれているもの。
設計の目的ってなんだよ
39 仕様書無しさん :2007/07/26(木) 22:07:24>>35
とりあえず基本情報処理試験的に言うとウォーターフォールだと
設計には外部設計、内部設計、プログラム設計があってそれぞれ
・外部設計
ユーザ側の立場で、システムの機能や性能などを決める。
画面、帳票、コード、論理データなどの設計を行う。
・内部設計
コンピュータの処理に適した設計を行う。
機能分割・構造化、物理データ設計、入出力詳細設計。
・プログラム設計
プログラムの構造設計を行う。
機能ごとにプログラムをモジュールに分割し、モジュール間のインターフェースを決める。
って書いてある
資格試験も馬鹿にならんなw
54 仕様書無しさん :2007/07/27(金) 00:31:07とりあえず基本情報処理試験的に言うとウォーターフォールだと
設計には外部設計、内部設計、プログラム設計があってそれぞれ
・外部設計
ユーザ側の立場で、システムの機能や性能などを決める。
画面、帳票、コード、論理データなどの設計を行う。
・内部設計
コンピュータの処理に適した設計を行う。
機能分割・構造化、物理データ設計、入出力詳細設計。
・プログラム設計
プログラムの構造設計を行う。
機能ごとにプログラムをモジュールに分割し、モジュール間のインターフェースを決める。
って書いてある
資格試験も馬鹿にならんなw
>>39
設計の目的はって聞いてんのにそのレスはなんなんだ?
だいたいウォーターフォールかスパイラルかによって設計の目的は変わるのか??
55 仕様書無しさん :2007/07/27(金) 00:38:10設計の目的はって聞いてんのにそのレスはなんなんだ?
だいたいウォーターフォールかスパイラルかによって設計の目的は変わるのか??
>>54
何を設計するかで設計の目的の詳細が違うっつー話だろ。
強引にまとめるとすれば「(何かの)機能をはっきり定義する」ことが目的だと思うがどーか。
57 仕様書無しさん :2007/07/27(金) 00:43:48何を設計するかで設計の目的の詳細が違うっつー話だろ。
強引にまとめるとすれば「(何かの)機能をはっきり定義する」ことが目的だと思うがどーか。
>>55
50点。
設計の目的は、何をやるかを定義することよりも、
何をやらないかを定義すること。
58 仕様書無しさん :2007/07/27(金) 00:48:3750点。
設計の目的は、何をやるかを定義することよりも、
何をやらないかを定義すること。
>>57
マジか?w
●このアプリケーションには起動画面にウルトラマンとか出てきません
●外観をMacOSのアプリに近づけようとする人がいますが今回はそれをしません
●GUIをエクリプスだかなんだかの礼儀にのっとって作ろうとしてる人がいますが今回はそれをしません
・
・
・
とか延々どうでもいいこと書くの?w
37 仕様書無しさん :2007/07/26(木) 22:01:13マジか?w
●このアプリケーションには起動画面にウルトラマンとか出てきません
●外観をMacOSのアプリに近づけようとする人がいますが今回はそれをしません
●GUIをエクリプスだかなんだかの礼儀にのっとって作ろうとしてる人がいますが今回はそれをしません
・
・
・
とか延々どうでもいいこと書くの?w
ローカル変数は小文字、
定数は大文字。
改行は分かりやすく、インデントを統一。
これが良い設計。
104 仕様書無しさん :2007/07/27(金) 23:11:34定数は大文字。
改行は分かりやすく、インデントを統一。
これが良い設計。
だれか言ってやれよ。
言語の差であって
オブジェクト指向はまったく関係ない。
112 仕様書無しさん :2007/07/28(土) 00:22:38言語の差であって
オブジェクト指向はまったく関係ない。
よし
誰か要求定義から実装までの流れのセオリーについて語ってくれよ
113 仕様書無しさん :2007/07/28(土) 00:23:53誰か要求定義から実装までの流れのセオリーについて語ってくれよ
>>112
右から左へ受け流す
142 仕様書無しさん :2007/07/28(土) 12:44:06右から左へ受け流す
プロトタイプ⇒非OOPで作る又は動的OOPで作る
製品⇒プロトタイプをリファクタリングして、良い設計のOOPで作り直す
俺のところでは、上記で良い成果が出ているけどな。
非OOPのスペシャリストは、すごいアイディアとすごいコーディング速度で
プロトタイプを作ってくれる人が多いもんね。
OOPの人ってアイディアが固まっている人が多いような気がする。
143 仕様書無しさん :2007/07/28(土) 12:45:50製品⇒プロトタイプをリファクタリングして、良い設計のOOPで作り直す
俺のところでは、上記で良い成果が出ているけどな。
非OOPのスペシャリストは、すごいアイディアとすごいコーディング速度で
プロトタイプを作ってくれる人が多いもんね。
OOPの人ってアイディアが固まっている人が多いような気がする。
結構適性というか能力が必要だからな。
構造化が中学数学、ニュートン力学としたら、オブジェクト指向は
微積分、相対論みたいなもん。
口先だけのノースキルには扱えないだろ。
でも自分では「ボクの能力では無理です」とは言えないし思いつきもしない。
だから「俺は無能じゃない。オブジェクト指向が使えないシロモノってだけ」
って思おうとしている。
精神の防衛機構だろ。
というか単なる馬鹿。
馬鹿にもそこそこ出来るようにするための技術じゃなくて、
頭いい人がさらに効率を上げるためのシステムだからさ。
扱う能力がないなら、使わない方がマシだしな。
144 仕様書無しさん :2007/07/28(土) 12:55:45構造化が中学数学、ニュートン力学としたら、オブジェクト指向は
微積分、相対論みたいなもん。
口先だけのノースキルには扱えないだろ。
でも自分では「ボクの能力では無理です」とは言えないし思いつきもしない。
だから「俺は無能じゃない。オブジェクト指向が使えないシロモノってだけ」
って思おうとしている。
精神の防衛機構だろ。
というか単なる馬鹿。
馬鹿にもそこそこ出来るようにするための技術じゃなくて、
頭いい人がさらに効率を上げるためのシステムだからさ。
扱う能力がないなら、使わない方がマシだしな。
>>143
その通りだと思う。
その通りだと思う。

オススメの動画
■赤ちゃんの笑い声をスローにしてみると・・・w
赤ちゃんの声を逆再生してみると…w
■【TAS】スーパーボンバーマン 13分45秒
SFCで発売された初のボンバーマンである「スーパーボンバーマン」のTAS動画だよ。
■成人式で配られたDVDで弾幕作った
成人式で配られたDVDがひどい件ってのが前に話題となって、いろいろなネタ動画がニコ動にアップされているわけだけれども、今回は東方風の弾幕ゲームを作ったみたい。
■アフガニスタンの戦地から帰宅した飼い主に大喜びする犬
犬は人懐こい動物なんだけれど、この動画では久しぶりのご主人さまの姿を見て大興奮する様が収録されているんだ。
赤ちゃんの声を逆再生してみると…w
■【TAS】スーパーボンバーマン 13分45秒
SFCで発売された初のボンバーマンである「スーパーボンバーマン」のTAS動画だよ。
■成人式で配られたDVDで弾幕作った
成人式で配られたDVDがひどい件ってのが前に話題となって、いろいろなネタ動画がニコ動にアップされているわけだけれども、今回は東方風の弾幕ゲームを作ったみたい。
■アフガニスタンの戦地から帰宅した飼い主に大喜びする犬
犬は人懐こい動物なんだけれど、この動画では久しぶりのご主人さまの姿を見て大興奮する様が収録されているんだ。
「掟破り系 ふるぼっこRPG アークサイン」
数の力で敵を制圧するといった一風変わった戦闘コンセプトをもつMMORPG
同じカテゴリーの記事
コメントありがとう御座います。★最新のコメントへ(36)
オブジェクト指向の目的ってなんなの?
>>143の言葉が痛すぎる・・・。確かにその通りだけど、技術力の乏しいやつにもオブジェクト指向でどうたらって話が来るから辛い。経験が無いっては相当厳しい。
オブジェクト指向に馴染みやすい人が楽な様にすることじゃね?
オレなんかはその口だが。実に楽。
馴染みにくい人にやらせても、15、16みたいなことにしかなんね。
オレなんかはその口だが。実に楽。
馴染みにくい人にやらせても、15、16みたいなことにしかなんね。
出来ない奴ほど、俺は出来ると思ってるから困る
仕事仲間にやりづらい奴がいるってだけで、べつにオブジェクト指向が嫌われてるんじゃないと思うよ。
学校でオブジェクト指向の授業落としたから嫌い
ってーか、OO な設計・実装と、OO な言語を一緒にしてる奴が多いから問題。
OO な言語を用いなくても、抽象型をサポートした言語であれば、OO なプログラミングが行えることを理解した上で、それを安全で簡単に実現する手段として OO な言語を使うというシナリオがなければ、OO な言語を使う意味は無い。
で >>4, >>6 なんだが、カーネルの中は OO なフレーバであふれていると気がついてほしい。
OO な言語を用いなくても、抽象型をサポートした言語であれば、OO なプログラミングが行えることを理解した上で、それを安全で簡単に実現する手段として OO な言語を使うというシナリオがなければ、OO な言語を使う意味は無い。
で >>4, >>6 なんだが、カーネルの中は OO なフレーバであふれていると気がついてほしい。
>>35
プログラムだけ納品すればいいけど、
世の中紙の設計書に意味がある。それだけ。
>>57
だいたい外部設計完了で一旦納品したりするんだけど、
後になって、客から文句がでたとき、
「外部設計はもう納品してますよね」
「それに書いてないんだからできません」
とか言い訳につかう。
プログラムだけ納品すればいいけど、
世の中紙の設計書に意味がある。それだけ。
>>57
だいたい外部設計完了で一旦納品したりするんだけど、
後になって、客から文句がでたとき、
「外部設計はもう納品してますよね」
「それに書いてないんだからできません」
とか言い訳につかう。
>>1004
「昔の技術枠組みの中では出来る人だったけどその後全然勉強してない」って人の方が発言力がある分タチが悪い。
「昔の技術枠組みの中では出来る人だったけどその後全然勉強してない」って人の方が発言力がある分タチが悪い。
知らなかった言語をちょっと囓ってみるときは
思い切ってクロスコンパイラを作るかOO的な設計で取り組みます
思い切ってクロスコンパイラを作るかOO的な設計で取り組みます
便利かどうかはわからないが、
確かにクラスを再利用することってあんまりないな・・・。
JAVAとかどんどんバージョンアップしちゃって、
そのまんま使えないこともある品。
確かにクラスを再利用することってあんまりないな・・・。
JAVAとかどんどんバージョンアップしちゃって、
そのまんま使えないこともある品。
JAVAの勉強してるが、確かに無駄に肥大化しすぎな気がする。
似たようなクラスが多すぎるしそのくせ細かい部分に差異があって・・・
似たようなクラスが多すぎるしそのくせ細かい部分に差異があって・・・
>>1007
それ裏返せばOOPが設計変更を要する事態に弱いってこと。
その考えが行き着くところ、上流がOO的設計で要請しないかぎり使うべきでないってことになるでしょ?
阿吽の呼吸の仲ならまだしも、OO理解している者同士でも脳内モジュール設計を口や紙で説明するよりコード見たほうが早いのが普通。
つまりOOは言語ごと設計のステージまで上げてこそ真価を発揮するんじゃないかと思う。>>142 みたいに。
それ裏返せばOOPが設計変更を要する事態に弱いってこと。
その考えが行き着くところ、上流がOO的設計で要請しないかぎり使うべきでないってことになるでしょ?
阿吽の呼吸の仲ならまだしも、OO理解している者同士でも脳内モジュール設計を口や紙で説明するよりコード見たほうが早いのが普通。
つまりOOは言語ごと設計のステージまで上げてこそ真価を発揮するんじゃないかと思う。>>142 みたいに。
オブジェクト指向嫌ってるとか、アホだろ。
いまだにOO理解できてないってどんだけオツム弱いの
憂鬱本こと「憂鬱なプログラマのためのオブジェクト指向開発講座」と
オブ脳こと「オブジェクト脳のつくり方」。
あとコレと同じことを言ってるコンサル会社や設計者。
こういった連中がオブジェクト指向に対する誤解を広めてるだけ。
オブ脳こと「オブジェクト脳のつくり方」。
あとコレと同じことを言ってるコンサル会社や設計者。
こういった連中がオブジェクト指向に対する誤解を広めてるだけ。
OOなんてやってる奴ら馬鹿だろ
時代遅れだっつーの
OOってなにか知らないけど
時代遅れだっつーの
OOってなにか知らないけど
>>1016
そういうなら、1016のお勧めの本は?ぜひ、教えて欲しい。
自分は古い本なら オブジェクト指向プログラミング入門 (カモノハシが表紙絵)がお勧め。
自分は「OOでもいいよ派」だが、基本的にOOはあんま凄いものじゃないし、
リスクに見合うだけのリターンがどんな場合にもあるとも思わないし、
結局は”アイディアと設計”そして”コード化力”次第だと思うから、
その両方さえ揃ってれば、OOなんて糞という人もアリだと思うがなぁ。
そういうなら、1016のお勧めの本は?ぜひ、教えて欲しい。
自分は古い本なら オブジェクト指向プログラミング入門 (カモノハシが表紙絵)がお勧め。
自分は「OOでもいいよ派」だが、基本的にOOはあんま凄いものじゃないし、
リスクに見合うだけのリターンがどんな場合にもあるとも思わないし、
結局は”アイディアと設計”そして”コード化力”次第だと思うから、
その両方さえ揃ってれば、OOなんて糞という人もアリだと思うがなぁ。
JavaはちょいOO以外の面で発達が失敗してるなぁと思う。
OOを考えてて触れてみたいと思うなら、
英語を覚えてpythonとかの方がずっといい気がする。
英語さえクリアしてれば、どれだけだよ!っつうぐらい情報もあるし、
入門OOには適してると思うし、意外と実用的な言語だし。
OOを考えてて触れてみたいと思うなら、
英語を覚えてpythonとかの方がずっといい気がする。
英語さえクリアしてれば、どれだけだよ!っつうぐらい情報もあるし、
入門OOには適してると思うし、意外と実用的な言語だし。
分かってる人も多いと思うけど、"OO"だけだと意味ないからね。念のため。
なんていうか、理論がどうこうじゃなくて、
いろんなものからつまみ食いして、
自分らの一番楽なやりかたするのが幸せになれると思う。
いろんなものからつまみ食いして、
自分らの一番楽なやりかたするのが幸せになれると思う。
amazonがレゴブロックwwww
ブラックボックス化は結局開発のためにはならん。
それと、走るジャンプするゴールするって単純だけど奥が深いゲームの方が
覚えゲーよりも遥かに重宝される点も無視できないよね。
それと、走るジャンプするゴールするって単純だけど奥が深いゲームの方が
覚えゲーよりも遥かに重宝される点も無視できないよね。
効率的に作業をする上でOOは欠かせない。
理解できない連中は、その分必死で働けば?w
納期が迫ると火消し要因にされるけど…Otz
理解できない連中は、その分必死で働けば?w
納期が迫ると火消し要因にされるけど…Otz
1012とかデザインパターンとリファクタリングで解決できるような気がするのだが
オブジェクト指向とか言いながら社内で勉強会やってるやつに限って極度の○○
OOが使いものにならないなら別の使える方法を考えてくれよ。
こころいいよ
C++みたいな汚い言語仕様ばっかり使ってるからいけないんですよ
C++そんなにひどいか?
C++は言語仕様としてはかなり汚いね。アレに染まってしまうとまともな言語が使えなくなる。C言語のコードが、ほぼそのまま動くことやその気になれば貧弱なハード上でも動くことを除けば、言語としては良い点はほとんどない。
できないオブジェクト指向マニアはデルファイ信者が多いよな。
うちのチーフもデルファイ・マンセーで仕事は早いが品質が悪すぎるw
バグがあるって言ったら、「テストはプログラマーの仕事じゃない」とか言いやがるw
で、結果として工数オーバーww
うちのチーフもデルファイ・マンセーで仕事は早いが品質が悪すぎるw
バグがあるって言ったら、「テストはプログラマーの仕事じゃない」とか言いやがるw
で、結果として工数オーバーww
汚い点を具体的に幾つか挙げてみてくれないか?
米1032
>できないオブジェクト指向マニアはデルファイ信者が多いよな。
デルファイ信者自体が滅多にみかけないので、デルファイ信者に
そういう人が多いかどうかは知らないが、デルファイ信者でなくても
できないオブジェクト指向マニアというのは珍しくないよ。
>できないオブジェクト指向マニアはデルファイ信者が多いよな。
デルファイ信者自体が滅多にみかけないので、デルファイ信者に
そういう人が多いかどうかは知らないが、デルファイ信者でなくても
できないオブジェクト指向マニアというのは珍しくないよ。
1034補足。
そのデルファイ信者ができないプログラマーというのには同意。
でもそれって初心者のVB信者でも同じじゃないか?
良く分からないままにIDE任せで部品をペタペタ張り付けるだけ。
できたコードはグダグダのスパゲッティ。
そんなのオブジェクト指向じゃないっつーの。
そのデルファイ信者ができないプログラマーというのには同意。
でもそれって初心者のVB信者でも同じじゃないか?
良く分からないままにIDE任せで部品をペタペタ張り付けるだけ。
できたコードはグダグダのスパゲッティ。
そんなのオブジェクト指向じゃないっつーの。
オブジェクト指向ってさ、流動的要素をカプセル化して、変更に強いプログラムを作るってことでいいんだよな…?


