デスマーチの原因は「オブジェクト指向」だった

1: 名無しさん@涙目です。(北海道) [US] 2019/03/03(日) 09:11:07.91 ID:smHSnNt+0 BE:422186189-PLT(12015)

無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。

カプセル化(英語:encapsulation)とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。

偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。

一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。

オブジェクト指向の発案者であるアラン・ケイもコーディング規約(頭文字にアンダースコアを付けるなどの命名規則)で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。

オブジェクト指向ってクソじゃねぇかよPart3 ・
https://mevius.5ch.net/test/read.cgi/tech/1542884872/

3: 名無しさん@涙目です。(山梨県) [IL] 2019/03/03(日) 09:12:14.86 ID:m3+7nYBS0
別にそんなご大層なもんじゃねえよww
隠蔽って別にpublicにすればいいだけじゃねえかww

 

5: 名無しさん@涙目です。(茸) [CA] 2019/03/03(日) 09:13:10.32 ID:EGr/UJV70
>>3
そう、オープンソースならね

 

7: 名無しさん@涙目です。(茸) [DE] 2019/03/03(日) 09:13:31.39 ID:RzkOkXR70
>>3
遮蔽した意味ねぇw

 

8: 名無しさん@涙目です。(チベット自治区) [AU] 2019/03/03(日) 09:13:38.14 ID:MrTcU3LA0
staticおじさん「デスマーチの原因はオブジェクト指向!」

 

78: 名無しさん@涙目です。(庭) [US] 2019/03/03(日) 10:24:48.18 ID:VDrOB0Ow0
>>8
COBOL一筋なおっさんに多いw
逆にJava厨な俺はCOBOLがちんぷんかんぷん

 

82: 名無しさん@涙目です。(西日本) [SE] 2019/03/03(日) 10:32:49.97 ID:PRYyENEy0

>>78
> 逆にJava厨な俺はCOBOLがちんぷんかんぷん

そういうのもよく聞くけど不思議に思う
あんな古臭い言語なんて簡単に理解できるでしょ?
実際に使うパターンだって少ないもんだし

ただ、よく読み込まないと全体像が理解できないってのはあるだろうけど
言語が理解できないと言うよりただ面倒くさいって話だと思う

 

11: 名無しさん@涙目です。(新疆ウイグル自治区) [DE] 2019/03/03(日) 09:14:22.78 ID:NbA+XTL60
たしかにprotectedは使うけどprivateは使わんな

 

15: 名無しさん@涙目です。(京都府) [FR] 2019/03/03(日) 09:15:31.70 ID:jiBppbIz0
getter/setterなんかエクリプスが一瞬で作ってくれるだろ
そんなんでデスマーチになるなら、開発者のスキルを疑った方がいい
素人同然の人間を放り込んだらデスマーチになるに決まってる

 

91: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 10:54:42.21 ID:rREatrQT0
>>15
派遣発見w
今時エクリプスみたいなオワコン使ってるとか

 

104: 名無しさん@涙目です。(京都府) [FR] 2019/03/03(日) 11:34:13.06 ID:jiBppbIz0
>>91
getter/setterは自動で生成できるから簡単という話の要点が読めずに、
エクリプス云々言い出すお前が発達障害なのは分かるw

 

27: 名無しさん@涙目です。(東京都) [ニダ] 2019/03/03(日) 09:20:33.66 ID:LKcWNq+x0
Cでもデスマは起きる

 

28: 名無しさん@涙目です。(チベット自治区) [US] 2019/03/03(日) 09:21:38.47 ID:vHkGchkh0

「絶対に使うな」

使わないと(使命感)

 

31: 名無しさん@涙目です。(庭) [CN] 2019/03/03(日) 09:23:08.70 ID:qHvlLSpn0

無茶振りかつ納期が決まっているのが日常だからじゃないですかね

「毎回三回宙返りを決めろ」みたいな話で、
戦術的な勝利を積み重ねても、戦略の時点で負けているわけですね

 

32: 名無しさん@涙目です。(catv?) [CN] 2019/03/03(日) 09:24:34.55 ID:0ZG2QN6n0
想定外の仕様を後から無理やり追加するから悪い

 

46: 名無しさん@涙目です。(東京都) [US] 2019/03/03(日) 09:38:50.73 ID:1D8e9+3Q0
>>32
結局それだね
人間側が悪い

 

37: 名無しさん@涙目です。(東京都) [US] 2019/03/03(日) 09:31:58.16 ID:1D8e9+3Q0

あってるだろ

今後の保守に影響あるだろうが

 

44: 名無しさん@涙目です。(神奈川県) [GB] 2019/03/03(日) 09:38:34.46 ID:WG9nBFz00
>>37
本来は実装の意図が明確になって保守が楽ってのがメリットでもあるんだぞ
改修の時に中身いじらなきゃいけないって時点でキチンとモデル化出来てないだけじゃん
まぁ、まともに使われてるの殆んど見たことないけど

 

42: 【大吉】 (catv?) [US] 2019/03/03(日) 09:38:10.14 ID:N1JfVU3M0
再設計や
あるいはアドホックなコードでスパゲティ化

 

43: 名無しさん@涙目です。(愛媛県) [US] 2019/03/03(日) 09:38:30.18 ID:r0o1lbC00
どんな道具も使いようによっては身を滅ぼすってこった

 

48: 名無しさん@涙目です。(東京都) [US] 2019/03/03(日) 09:41:18.33 ID:1D8e9+3Q0
結局機能の作り込みまで適用するからだな
APIなど不動固定のもので留めて置くべきかもね

 

143: 名無しさん@涙目です。(庭) [GB] 2019/03/03(日) 13:09:10.93 ID:4yqoYbup0
>>48
その通り、フレームワークとそにユーザは結構違うよね

 

50: 名無しさん@涙目です。(神奈川県) [BR] 2019/03/03(日) 09:42:46.20 ID:Za/Y2s410

オブジェクト指向がどうこうよりも、命名規約がバラバラ、変数のスコープがいい加減とか、統一感がない実装が一番厄介だと思う

下手な実装でも下手なりに統一されてれば割と読める

 

51: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 09:43:45.85 ID:bseAkZ660
想定外を想定する
って一流もいる

現実の馬鹿はそれを超えてくる

 

58: 名無しさん@涙目です。(やわらか銀行) [FR] 2019/03/03(日) 09:52:19.35 ID:9hdlZ72/0
設計書書かないバカが多過ぎるからデスマになる。

 

144: 名無しさん@涙目です。(庭) [GB] 2019/03/03(日) 13:11:42.98 ID:4yqoYbup0
>>58
その通り、設計書を書けない人は脳内コーディング出来ない人。「実装しながらじゃないと掛けません」←経験不足か脳の限界

 

60: 名無しさん@涙目です。(dion軍) [RU] 2019/03/03(日) 09:52:49.95 ID:UxISEM6c0
てか、設計が悪いのが原因やろ。
オブジェクト指向で失敗するやつは何やっても失敗するような気がするわ。

 

61: 名無しさん@涙目です。(千葉県) [US] 2019/03/03(日) 09:56:37.19 ID:7yc5pwIs0
これ仮に隠蔽やめたとしても、クラスの詳細な設計と使用方法が無いと馬鹿がgetterとか使わないでどこへでもアクセスしまくるから
参照して取れる値が違うとかありそう

 

80: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 10:29:06.34 ID:nP0ASC520
昔から思っているけど、privateな変数を外とやり取りするだけのgetter、setterってほとんど意味無いよな。オブジェクト指向を勘違いしている。

 

107: 名無しさん@涙目です。(新疆ウイグル自治区) [AU] 2019/03/03(日) 11:40:49.75 ID:+ilPOSM60

>>80
アクセサを脳死で作るとカプセル化にならない

アクセサはそれが本当に必要か、設計をよく考えてから作るといいね

 

83: 名無しさん@涙目です。(家) [US] 2019/03/03(日) 10:40:49.82 ID:y+Lc+Vsp0

オブジェクト指向自体が古い発想だからなあ
80年代のパソコン誌でSmalltalkがよく話題になってたっけ

俺は組み込みで今もCと時々アセンブラがメインでやってるから
時々趣味でC#やる時以外に思想とか触れる機会がないが、
他にも色々より進んだのあるんじゃないの?

というかデザインパターンとか、全体の設計の次元の方が
もっと重要なんじゃないのかな、アーキテクトだっけ?
戦略と戦術というか

 

359: 名無しさん@涙目です。(庭) [KR] 2019/03/03(日) 23:33:01.63 ID:GLzeb0te0

>>83
「プログラム」という考え方がもうすでにやや古い気もする
アルファベットを1文字間違えただけで動かなくなる訳だから
(もちろん、実際問題になるのは違うバグだとしても)

「プログラム」によるシステム自体、大変脆い訳だが、
では、機械学習によるAIに全て切り替わるか?と言ったら当然違うし、
その辺を組み合わせとか、第三の方法論とかでモニョモニョっとやりそうな気もするけど

 

85: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 10:47:32.14 ID:L+8hAEUn0

デザパタはオブジェクト指向をちゃんと理解できてないと無理だろ
継承とかオーバーライドとか

んで、オブジェクト指向を理解するには、まずみっちり手続き型の関数を覚えて、
使い方をマスターせにゃならん
メモリ上の挙動を完全に把握できるくらいに使いこなして始めてオブジェクト指向を使いこなせると言える

マーケッティングのために
「オブジェクト指向はメモリもポインタも意識する必要ありません。だから簡単で文系でもできます。」
と言うけど実際は違う

このマーケッティングがデスマの主な原因
工数の目算を誤って見積もりが甘くなるのが原因

 

92: 名無しさん@涙目です。(家) [US] 2019/03/03(日) 10:57:50.76 ID:y+Lc+Vsp0

>>85
JavaもC#もJITのコンパイル後を考慮した速いコーディングがあるのを最近知ったよ

CもC++もやってるからメモリリークには元々気を遣ってるけど、
C#とかもやっぱりリークするって聞いて基本は大事だと思う今日この頃

 

86: 名無しさん@涙目です。(東京都) [ニダ] 2019/03/03(日) 10:50:09.67 ID:mxKIqMIM0
動きゃ何だっていいんだよ

 

88: 名無しさん@涙目です。(千葉県) [RU] 2019/03/03(日) 10:52:33.05 ID:atg3Axt+0
下請技術者の技術が低いのが悪い
ユーザーとか元請は何も悪くない
なのにみんなデスマ巻き込まれて人生狂ってかわいそう

 

93: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 10:59:07.08 ID:L+8hAEUn0

大企業の上流行程にいる奴はそもそもメジャーなプログラム言語すら理解できてないだろ
やっててC++をかじってる程度
オブジェクト指向の理解も怪しいし、デザインパターンなんか誰も理解してない

年功序列だから、その人間が教育を受けた時代はBASICでGOTO文を打ってた世代だろ

だからジャップメーカーのIT機器はクソアプリしかバンドルできないんだ
大手ほど酷い

 

96: 名無しさん@涙目です。(庭) [TW] 2019/03/03(日) 11:15:35.28 ID:+tqggUIs0
小さい頃N88BASICから始めて、今はUnity C#やVB.net、Perlとかある程度扱えるんだが、未だにオブジェクト指向って何なのかよくわからん
いろんな文献読んだのにふわっとしか把握できてなくてすんげえイライラする
たぶん俺の各コードめっちゃやばいんだろうなとは思ってる
ちなみに変数は全部publicにしてる

 

99: 名無しさん@涙目です。(チベット自治区) [US] 2019/03/03(日) 11:24:15.77 ID:XWsibIbr0
>>96
『オブジェクト指向でなぜつくるのか』がオススメ
概念ベースと実装ベースでの違いがよく説明してある。

 

409: 名無しさん@涙目です。(茸) [ニダ] 2019/03/04(月) 11:00:06.10 ID:LOc1Asdp0

>>96
全部パブリックとかクソコードかかれるとブチ切れるわ。
setter とかで値のチェックできないよね。
setterで不正な値(例えば1~9以外)をはじくとかしてても、public な変数宣言されたら意味ないよね。

private な変数を public に変更してくるばかがいるんだよ。

 

108: 番組の途中ですが名無しです(奈良県) [US] 2019/03/03(日) 11:43:53.81 ID:prBsXZfm0
OOPって再利用が前提じゃないの?
プロジェクト毎に、ゼロから作ってりゃ意味ないし、
むしろ、使わないほうが効率いいんじゃね。

 

142: 名無しさん@涙目です。(新疆ウイグル自治区) [AU] 2019/03/03(日) 13:07:03.62 ID:+ilPOSM60

>>108
オブジェクト志向で再利用とか相当古いぞ

再利用しないわけじゃないが、継承やインターフェースは再利用が目的じゃない

 

148: 名無しさん@涙目です。(東京都) [US] 2019/03/03(日) 13:16:59.65 ID:jYG1nyTc0
>>108
これなんだよな
カプセル化だの隠蔽だのってのはそれ実現するための手段であったり副産物
カプセル化自体が目的になってる奴もいるけどさ

 

150: 名無しさん@涙目です。(やわらか銀行) [ニダ] 2019/03/03(日) 13:18:36.67 ID:isatBjXW0
>>108
色々作ってるとこれ絶対いつも使うよなっていう定番を再利用する為のもんだね。
毎回微妙に違うものを無理やり再利用したら効率悪化する。

 

154: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 13:23:47.50 ID:L+8hAEUn0

>>150
でも作るたびドンドン良くなっていくから、結局、昔の物は使わないというねw
せいぜい、過去互換性でデータの同期取る時くらいしか使わない

そんくらい市場環境の動きが早すぎる

 

110: 名無しさん@涙目です。(新疆ウイグル自治区) [US] 2019/03/03(日) 11:49:22.22 ID:F3OYILAl0
デスマーチの原因は上流工程の弱さだよ。
言語仕様なんて枝葉の問題でしかない。
多分この有識者連中は業務システムのスクラッチ開発経験に乏しい。
ミスリードも大概にしてほしいし客側は騙されてはいけない。

 

111: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 11:53:31.50 ID:L+8hAEUn0

まぁ、やってみりゃわかるけど、再利用性はそんなに高くない
使う場所は使いまくるけど、全体ではごく一部だよ

あと、システムが複雑化してくると、あやとりになってくるからなOOPは
そのあやとりを上手くやるコストがメチャメチャ高いんだ
特に教育投資や引継が大変
そこ全然やらないからジャップはダメなんだよ

十分教育されてない新人を入れるってのは、目隠し状態であやとりに参加させるようなモンだ
失敗するのは明かだよね

 

116: 名無しさん@涙目です。(新疆ウイグル自治区) [TW] 2019/03/03(日) 12:11:13.53 ID:erD/dyvf0
ご託はいいから仕様決めてから仕事させようぜ
それだけで発注リスクの大半は無くなる

 

119: 名無しさん@涙目です。(庭) [KR] 2019/03/03(日) 12:19:39.23 ID:ze957l7i0

>>116
それはウォーターフォールだなw

昨今は制御系でもアジャイルが多いんだが、おかげで客先から離れられん。要するに派遣だw
アジャイルを自社でやるとデスマーチになるが、客先でやる分にはダラダラと長くなるだけだと言う違いがある。

そりゃ、結果を見て仕様が変われば納期がダラダラ伸びるのは当たり前。受託向けじゃないってだけ。

 

117: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 12:16:02.71 ID:L+8hAEUn0

まー
数年でフレームワークやOS自体変わっちゃうからな
ちょっと前まで.netでc#って言ってたのが、今じゃiphoneアプリでunityだもんさ

じゃあ、今unityの奴らが.netの昔のやつの保守やらされたらどーなんのっていう
多分メチャクチャな作法で改悪していく

そういうことだよな

 

130: 名無しさん@涙目です。(庭) [DE] 2019/03/03(日) 12:35:34.61 ID:6f/zGmez0

データを安全に扱うための縛り、機能をシンプルな単位で分割
この辺りまでは積極的に使うけど、全部をデザパタに当てはめて設計とかまでしないな。

デザパタに忠実だと、スパゲティはある程度避けれて、既存のコードをほとんど触らずに機能変更や追加ができるコードになるけど、
ピタゴラススイッチになって保守が死ぬほど辛い。

 

159: 名無しさん@涙目です。(茸) [ニダ] 2019/03/03(日) 13:27:02.03 ID:o/P48XiO0
昔、従業1000人ほどのIT企業にいたけど大きめのプロジェクトが見積もりどうりに行ったのを一度も見たことがない
競合他者との受注競争でギリギリの額で見積もるしかないのかも知れんが結局燃えてから増員して余計に効率が悪くなる

 

163: 名無しさん@涙目です。(大阪府) [US] 2019/03/03(日) 13:28:15.62 ID:ciF4MeaX0

>>159
やっぱ
火付き案件とか言うように

どこかで火という言葉を使うんだなぁ

 

202: 名無しさん@涙目です。(新疆ウイグル自治区) [SE] 2019/03/03(日) 14:11:49.30 ID:qtT9mkvV0

オブジェクト指向アプローチの最大の問題はデータをカプセリングさせようとすること
これで後で仕様が変ってそのデータが変ったら隠蔽された中をいじらなければいけなくなる
上位オブジェクトではgetter/setterで操作すれば良いのかもしれんが階層の下のオブジェクトの
プロパティも変えなきゃならないことが繰り返されると速攻でスパゲッティ化とデスマーチになる

オブジェクト指向厨はオブジェクト指向が原因だと絶対考えようとしないので
仕様をぐらつかせる顧客が悪い!営業が悪い!ちゃんとモデリングしない奴が悪い!
と人のせいにしてる

データはpublicでstaticで良いんだよw

 

310: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 18:39:37.42 ID:L+8hAEUn0

>>202
ラッパー被せりゃいいだけじゃん

その発想すら浮かばないから構造化プログラマーはダメなんよね
名前のバッティング気にしてやらないんだろw

それに継承でデータガーとか、そもそもオブジェクト指向設計できてねーじゃんみたいな
手続き型でクラス階層化だけやってオブジェクト指向語ってる設計にあるあるのクソだよ

 

203: 名無しさん@涙目です。(埼玉県) [DE] 2019/03/03(日) 14:13:07.53 ID:X3D8fyMJ0

オブジェクト指向ってsetter/getterだけなんっすかね?

 

204: 名無しさん@涙目です。(京都府) [FR] 2019/03/03(日) 14:14:28.54 ID:jiBppbIz0
>>203
全然違う。この記事はレベルが低すぎる。

 

206: 名無しさん@涙目です。(新疆ウイグル自治区) [SE] 2019/03/03(日) 14:18:11.37 ID:qtT9mkvV0

オブジェクト指向はおじさんたちの青春だからな
C++とかをお勉強して当時の新しいやり方でプログラミングして
古い人達と違うんだとバカにしてのしあがって来た数十年前の大切な思い出

現代になっていざ自分たちが逆の立場に立たされていることを雰囲気で感じ始めて
困惑し逆切れ発狂している

 

209: 名無しさん@涙目です。(埼玉県) [DE] 2019/03/03(日) 14:23:19.51 ID:X3D8fyMJ0

データと一言でいうが、そのデータがどのような状態にあることについての考えがまるでない

通常データは単一ではなく複数のまとまったある時は数珠繋ぎのようなある時はランダムなものであり

データの側から見たオブジェクト指向はそれを効率的に扱うのであればオブジェクトのようなものにいれてコレクションで管理したほうがいいんじゃないですかね?

といった一つの考えでしかない。

つまりmainのような箇所にデータの取り扱いを記述するよりも、データを格納するdataクラスにその記述を書いておけば再利用性高くね?

といった感じ。

 

210: 名無しさん@涙目です。(沖縄県) [US] 2019/03/03(日) 14:25:44.34 ID:ly6kpIxB0
カプセル化ばっかり取り上げられるけど
継承とかは便利じゃないの?

 

216: 名無しさん@涙目です。(茸) [ニダ] 2019/03/03(日) 14:32:52.46 ID:1S/OD2ts0
>>210
継承しようと思ったけど肝心のデータがカプセル化されていて、結局似たようなクラスを再開発するパターンが多い

 

226: 名無しさん@涙目です。(新疆ウイグル自治区) [SE] 2019/03/03(日) 14:47:37.84 ID:qtT9mkvV0

>>210
アランケイが創案したオブジェクト指向では継承はオブジェクト指向の要素とは認めてないからな
継承はC++作ったおっさんが勝手に導入した概念

C++的なアプローチはクラス分割して部品を独立させてと疎結合を頑張っちゃうけどその
その分断の補完として統一性を保つためにやむを得ず継承の再利用を取り入れたやり方

アランケイのオブジェクト指向はメッセージ指向で彼が言うには
「”全体より強度の弱いもの”に分割するのではなく、…つまり、そのセマンティクスは、
無数のコンピュータがすべて超高速ネットワークでつながっているようなものだ」
という非分割的なアプローチで180度考え方が違ったりする

 

212: 名無しさん@涙目です。(新疆ウイグル自治区) [SE] 2019/03/03(日) 14:27:44.96 ID:qtT9mkvV0

以前はプログラマー35歳定年説ってあったろ?
ところがなまじC++とJavaの時代が長かったので、
「いや俺は40過ぎても現役だぜ」というおじさんプログラマがいっぱい登場してしまった。
クライアントがパソコンでサーバーは三階層の時代が長すぎたのがいけない

新しい言語や考え方を身に付けるには若くないと付いてゆけない筈

40代のおじさんがjuliaやGoをReactとか駆使してマイクロサービスやサーバーレス上で
がしがし新しいサービスを創出できていればその人は現役と言えるけどそんなの僅かやん

オブジェクト指向の考え方を振り回してC++やJavaで身に付けた古い考えを語って皆に迷惑を掛けてることに気付かない

35過ぎたら後進に道を譲ることをおじさんは考えるべき

 

235: 名無しさん@涙目です。(埼玉県) [DE] 2019/03/03(日) 15:01:48.10 ID:X3D8fyMJ0

継承と切っては切れないものにinterfaceがある。

interfaceの役割はそれを実装したものはinterface型の子供にする役割がある。これが重要。

たとえばclassAにclassA1のthisを渡すよりもclassA1にinterfaceIを実装させてIの子供としてclassA1をclassAに渡せば

classAはclassA1をinterfaceIとして認識してinterfaceIのメソッドにだけアクセスできてclassA1のpublicすべてにアクセスすることは許されない

まぁたいていのstaticオジサソはinterfaceといえばオーバライドするものだ程度の認識しか持ち合わせてないのが現状www

すべてをピーコーで満足してるwwstaticオジサソに限らずmvpの解説をする企業のサイトまでthisを渡しちゃえ!みたいなことが書いてあって目も当てられないwwww

 

237: 名無しさん@涙目です。(大阪府) [US] 2019/03/03(日) 15:02:51.19 ID:ciF4MeaX0

しかし、後輩の後輩の後輩の後輩ぐらいの製造(PG)に聞いたけど(20代前半)

今の話で、FIXされたソースの変更を無許可で改修し、
詳細設計所も製造が勝手に書き直してるって聞きました

誰も責任を取らない職場があるようですね
それがすべてとは思いませんが
現場にサブリーダすら居ないって・・・・・

 

336: 名無しさん@涙目です。(dion軍) [US] 2019/03/03(日) 22:33:37.77 ID:L+8hAEUn0

大体、まぁ、オブジェクト指向ってのは方法論が腐るほどある
それこそ、星の数ほどある
マニュアルなんて存在しないし、存在できない
要は発想力が重要になってくる

日本人の苦手な分野なわけよ
12年間ずっとパターン学習ばっかりやってくるからな
解法と教科書だけを暗記して繰り返すだけ
そういうマニュアル野郎だと、オブジェクト指向でデザインパターンを使って応用っつっても何もできないわけ

マニュアルが無いからなw
つまり全てそういうこと

 

443: 名無しさん@涙目です。(dion軍) [US] 2019/03/04(月) 19:15:21.55 ID:To8kduEf0

結局の所、デスマの原因は
・クライアントが満足な報酬と期間を用意しない
・安易に安請け合いして、安易に安値で下請けに流す
・安易に受け取る下請けが膨大に存在する
・これらの存在が仕事単価の切り下げ圧力になり、さらにクライアントは調子扱いて金を払わなくなる
・金を払わないから当然工期も短縮されていく

このループで悪化の一途
どこの業界も同じ圧力が掛かる

日本全体どこ行っても同じ形でデフレしている
全てジャップが悪い

 

448: 名無しさん@涙目です。(庭) [US] 2019/03/04(月) 20:25:42.07 ID:X4gPbs3B0
>>443
高レベル技術者、取り分け優秀なPMがいればデスマにならない。
デスマが発生するのは良いメンバーがいない時。
つまり、受注が順調な時だよ。

 

466: 名無しさん@涙目です。(dion軍) [US] 2019/03/04(月) 23:58:19.64 ID:To8kduEf0

>>448
そもそも良いメンバーが集まらないのが問題だろw

その原因は低賃金と待遇が悪いからだ
見合ってない

国際的に見ても日本のIT技術者の賃金は1/3しかない

受注が順調なのではなくて、あまりにも待遇が悪すぎて人手不足なだけだ
日本中全てコレ

 

2: 名無しさん@涙目です。(茸) [ニダ] 2019/03/03(日) 09:12:11.97 ID:SMaMwZZn0
コミュ力不足が9割だよ

引用元

管理人からひと言

どっちみち炎上するさ

関連記事

  1. プログラミング始めたけどどの分野も難しい・・・

  2. Vue.jsについて語るスレ

  3. オブジェクト指向がわからない

  4. プログラム言語なにがいい?

  5. ゲーム作りとかプログラミングとかに詳しい人マジで来てくれ!!!!!!!!

  6. カテゴリ_プログラム

    CとPHPがあればJavaは要らない

  7. プログラミング詳しいやつwebサービスについて相談に乗ってください

  8. jQueryの勉強したいんだがJavaScriptの勉強先にした方がいいの?

  9. カテゴリ_プログラム

    プログラマに聞きたいんだけどテストってどうやってるの?

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

最近の人気記事

  1. カテゴリ_その他

おすすめ記事

新着記事

  1. 閉鎖のお知らせ
  2. SES社長だけど質問ある?
  3. windowsにAI搭載するとか言ってるけどさぁ
  4. 新卒エンジニア僕、資格勉強する気が起きない
  5. 文系学部卒一般企業志望の君の進路はここから選んでもらうぞ!→ 営業・販売・未経験…

ボンブの戯言

  1. 【ボンブの戯言】ITエンジニアがフリーランスになる理由
  2. 【ボンブの戯言】フリーランスのメリットを全否定してみた
  3. 【ボンブの戯言】フリーランスが払う税金など6選!私たちはこんなに支払っている!
  4. 【ボンブの戯言】サーバーって何なの(オンプレに限る)
  5. 【ボンブの戯言】ITエンジニアが徹夜してでも間に合わせる理由
PAGE TOP