2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

技術力が低い会社にありがちなこと part 6 [転載禁止]©2ch.net

1 :仕様書無しさん:2015/03/14(土) 12:53:44.52
猿でも使えるWindowsで、パワポ紙芝居・エクセル方眼紙のポエム、上司はひたすらソリテア
Linux使えない、GCC何それ食えるの? Javaって飲み物? Macってハンバーガーでしょ?

前スレ
技術力が低い会社にありがちなこと part 5
http://kanae.2ch.net/test/read.cgi/prog/1413465994/

2 :仕様書無しさん:2015/03/14(土) 18:25:05.49
>>1
スレが伸びないww

3 :仕様書無しさん:2015/03/15(日) 14:54:19.72
>>2
それは 技術力が低いスレ主にありがちなこと だろw

4 :仕様書無しさん:2015/03/15(日) 18:24:48.75
MacオンリーでWindows認めない人は
技術力低そう

5 :仕様書無しさん:2015/03/15(日) 22:06:17.27
技術力が低い人って大抵意味の分からないプライド持っているよな
教えてあげても口答えしてくるか、訳の分からない言い訳並べ始める
結果的に良いのか悪いのか関係なく自分のやり方を貫き通す人ばかり
構っている時間が勿体ないから、みんなから放置されてああなったんだろうなぁって思う
技術力皆無でも新人が好かれるのは、素直に学ぶ姿勢が良いのだろうね

6 :仕様書無しさん:2015/03/15(日) 22:26:51.10
何も疑問を持たずに受け入れたら、それはそれで怒るじゃないか

7 :仕様書無しさん:2015/03/15(日) 23:30:36.62
>>5
> 教えてあげても口答えしてくるか、訳の分からない言い訳並べ始める
だいたいそんなの誰でも知ってるよってことばかりなので、
普通は無視してあげる。

8 :仕様書無しさん:2015/03/15(日) 23:32:34.36
>>5
このスレで技術力をやたらと口にする人間にも
全く同じことが当てはまると感じるのは気のせいか?

9 :仕様書無しさん:2015/03/15(日) 23:36:25.67
>>8
同意

10 :仕様書無しさん:2015/03/16(月) 00:25:23.63
>>8
一体、ここの技術力の高い人に何を教えてあげようとしてそれを無視されてるんだ?

11 :仕様書無しさん:2015/03/16(月) 00:49:36.15
リース品の開発用PCのスペックが微妙で
CPUとメモリは割りとまともなのに、激遅のHDDを搭載してるPCばかり
1日の作業の20%以上がHDDアクセス落ち着き待ちのムダ時間

12 :仕様書無しさん:2015/03/16(月) 06:40:54.07
リースってまだSSDになってないの?
やっぱマック以外は糞だな

13 :仕様書無しさん:2015/03/16(月) 17:24:52.76
>>11
サムスンでも使ってるんじゃね?

14 :仕様書無しさん:2015/03/16(月) 17:39:08.30
リースってだいたい自社製品だからあまり悪口言えないしなw

15 :仕様書無しさん:2015/03/16(月) 21:20:52.84
ドキュメントが全部Excelで作られている。

16 :仕様書無しさん:2015/03/16(月) 21:22:10.79
>>4
能力ある人は、MacだろうがWindowsだろうが組込だろうが、
ちゃんと結果を出すからね。

17 :仕様書無しさん:2015/03/16(月) 23:27:07.23
>1日の作業の20%以上がHDDアクセス落ち着き待ちのムダ時間

リース品なんて俺自身は使った事ないから知らんが、今時こんな事ありえるのかね
どんな作業してんだ?

18 :仕様書無しさん:2015/03/17(火) 00:07:11.12
>>13
最近のサムチョン製品は意外とあなどれん
http://gigazine.net/news/20150316-ssd-endurance-experiment-4th/
SSDドライブの耐久テストで最後まで生き残りやがる

>>17
業務系受託開発やってる中小には意外と多い気がする
CPUは数%しか使ってないのに、延々バックグラウンドでHDDアクセスやってることがある

19 :仕様書無しさん:2015/03/17(火) 06:30:33.06
>>16
そりゃどんな環境だって人によって結果に差は出るさ
相対じゃなくて絶対の話だよ
全員がWindowsにしたほうが絶対に早いんだよ

macは個人向けにターゲットを絞って法人切り捨てたんだから当たり前だろ

ハードウェアスペックの差によるリース料金の差なんて微々たるものなんだよ
人件費に比べればね

20 :仕様書無しさん:2015/03/17(火) 07:20:41.95
Linux用のコード書くならMacのほうが向いてる
現にOSSなんかのイベントはMacだらけ

21 :仕様書無しさん:2015/03/17(火) 07:21:54.82
Windowsの場合はLF改行だのUTF8だのが専用エディタ
ファイルアップロードやSSHも外部アプリ頼みにならざるを得ない

22 :仕様書無しさん:2015/03/17(火) 07:33:04.79
これから円安で国産PC復権するよ
マックの時代は終わる

23 :仕様書無しさん:2015/03/17(火) 08:39:36.49
業務開発用Windows機は、基本的にSSD搭載品に
しないとそれだけで生産性に影響するよ
シマンテクのエンドポイントなんかを強制する
業務環境なんかだと特に

オレのいる会社だとみんなリアルタイムビルド切って
30分毎くらいにビルド掛けてタバコ休憩行く糞環境
そろそろ転職するわ

24 :仕様書無しさん:2015/03/17(火) 08:48:02.56
え?ビルドって昼休みと営業時間終わってからの2度だろ
30分毎にビルドって優秀じゃないか

25 :仕様書無しさん:2015/03/17(火) 22:41:57.73
何をそんなにビルドしてるんだい?

26 :仕様書無しさん:2015/03/17(火) 23:02:06.95
>>23見てふと思ったが、毎日全スキャン走るとことかあんのかな
うちは週一だけども

27 :仕様書無しさん:2015/03/17(火) 23:40:11.87
HDのアクセスが何なのかも調べず、ただ待っている阿呆こそ、クソ会社の社員だろw

28 :仕様書無しさん:2015/03/18(水) 01:02:06.70
同じマシンに複数人の環境が残ってて
よく分からんものが動いてるけど消せない、とか

29 :仕様書無しさん:2015/03/18(水) 01:30:54.18
>>20
macでサーバー立てるんじゃない限りはVMの上でlinuxを本番環境に近い構成で動かしたほうがいい。
いまどきだとvagrantやdockerやらでチームメンバーと同じイメージで環境立てるのなんて簡単だし、
chefやPuppetでローカル環境で試して、実際に本番環境でとかでミスも減らせるし。
見栄でmac使っているのか、メモリーケチってる奴とかいるからな。

30 :仕様書無しさん:2015/03/18(水) 02:13:39.49
>>29
その通り。うちではWindowsだったりLinuxだったりMacOSXだったり
バラバラだが開発環境はvagrantとdockerで構成されてるので、
ぶっちゃけどれでも変わらん。

LinuxだとDockerがネイティブで動くとか
WindowsだとCygwinが必要とか
そういう些細な違いがある程度。

31 :仕様書無しさん:2015/03/18(水) 02:15:47.60
>>20
> 現にOSSなんかのイベントはMacだらけ

その理由は簡単で、MacだとWindowsとLinuxも使えるから。
と言うかAppleがMacOSXを自社パソコンでしか動かなくしているから。

高スペックなマシンは自宅や会社にあって
移動用はどうせデスクトップに比べてスペック低くなるので
スペックは諦めて一台でWindowsとLinuxが動く環境として用意している。

32 :仕様書無しさん:2015/03/18(水) 08:28:57.76
後付で色んな理由が言われてるけど
結局、iOS開発するのに必要だから買ってるだけ

33 :仕様書無しさん:2015/03/18(水) 17:28:20.83
一般人の場合、macはかっこつけが多いよなw

34 :仕様書無しさん:2015/03/18(水) 17:29:35.53
実際、かっこいいからな
業者に頼めば安価にWindowsも入れてくれるし

35 :仕様書無しさん:2015/03/18(水) 17:40:11.15
>>34
よく見るとチープだぞ。

36 :仕様書無しさん:2015/03/18(水) 18:15:57.55
>>34
業者に頼まなくても簡単にWindows入れられるぞ

37 :仕様書無しさん:2015/03/18(水) 19:56:12.91
そんなの当然把握してて、素人でも安価で二刀流環境に出来るからねという意味だろ…

38 :仕様書無しさん:2015/03/19(木) 00:20:48.39
Windowsは馬鹿でも使えるからな

39 :仕様書無しさん:2015/03/19(木) 01:30:56.58
WinのGUIソフトでぽちぽちSVN弄ってる人たちはgit使えるようになるの?

40 :仕様書無しさん:2015/03/19(木) 04:44:51.29
使えるか心配するほど高難易度なら普及しないから使う価値がないってことだ

41 :仕様書無しさん:2015/03/19(木) 07:26:26.46
>>40
普及しないのはその通りだと思うが
自分達のために使う価値はある

42 :仕様書無しさん:2015/03/19(木) 19:23:11.01
>>35
よく見なくてもチープなマシンが多いなか、貴重な存在。

43 :仕様書無しさん:2015/03/19(木) 23:25:04.63
・自分のPCに仮想環境はインスコ禁止
・エディタは秀丸のみインスコ可
・開発ツールは枯れて安定しているメジャーバージョンが1つ前のもののみ使用可
・SSDは耐久性に問題あるから使用禁止
・Macはグラフィックや映像を作るマシンだから使用禁止

・・・こんな会社だったんで早速辞表を書いた

44 :仕様書無しさん:2015/03/19(木) 23:52:36.11
10cmのタコ糸と針だけで釣をさせてるようなもんだな

45 :仕様書無しさん:2015/03/19(木) 23:58:01.39
>>43
そんな理由で退職するお前も相当痛いぞ・・

46 :仕様書無しさん:2015/03/19(木) 23:58:45.81
>>45
そう?
俺はよくやったと思う。

47 :仕様書無しさん:2015/03/20(金) 00:00:03.42
開発楽しめないような環境で仕事するなんて
時間の無駄だからな。

48 :仕様書無しさん:2015/03/20(金) 00:01:22.54
職場環境が自分に会わないなら自分に会うように環境を変えればよい、
それが出来るだけの技量も実績もない人間は転職しても結局同じ事を繰り返すだけ

49 :仕様書無しさん:2015/03/20(金) 00:02:27.76
>>48
なるほど、零細なら自由かもな

50 :仕様書無しさん:2015/03/20(金) 00:03:59.99
>>48
それが出来ないからいつまでも奴隷のままなんだろ

51 :仕様書無しさん:2015/03/20(金) 00:04:22.81
こちとら環境を変えるほどの情熱もコミュ力も持ち合わせてないわ。

52 :仕様書無しさん:2015/03/20(金) 00:05:15.22
>>48
コミュ障にはムリ

53 :仕様書無しさん:2015/03/20(金) 00:07:40.44
自分では何も出来ないくせに何かあれば全て他人のせい・・・
ホント糞ばかりだな

54 :仕様書無しさん:2015/03/20(金) 00:08:56.02
零細企業の人間がわらわらと

55 :仕様書無しさん:2015/03/20(金) 00:10:03.76
自分は職場のサーバーがLinuxだったのですぐに退職した
今時Windowsじゃない時点でどう考えてもクソ過ぎるわ

56 :仕様書無しさん:2015/03/20(金) 00:11:27.01
零細企業にすら採用されない底辺がわらわらと

57 :仕様書無しさん:2015/03/20(金) 00:15:16.53
>>34
windowsの方がかっこいいじゃん

58 :仕様書無しさん:2015/03/20(金) 00:15:19.96
Linuxなんてまだあったのww

59 :仕様書無しさん:2015/03/20(金) 00:18:25.75
老害がLinuxのコンソールでチマチマとキーボード叩いて泥臭い開発をしている傍らで
俺はWindowsでマウスでスマートにインテリジェンスな開発を行う

60 :仕様書無しさん:2015/03/20(金) 01:13:42.42
windowsさんは一人でレスしていて虚しくならんのかね。

61 :仕様書無しさん:2015/03/20(金) 01:24:25.59
Linux用のソフトも、秀丸とTeratermで作るよなあw

62 :仕様書無しさん:2015/03/20(金) 01:36:43.36
こういうのがWindows使いの一般的な姿なんですよ?
わかりましたか?
ね? Windows使いっておかしいでしょう?
私の言ってることに納得したでしょう?

63 :仕様書無しさん:2015/03/20(金) 06:30:44.43
Windows使いもなにもビジネスの分野では今やWindows一択じゃん
所詮LinuxなんてOSすら買えない貧乏で臭いキモヲタご用達のオモチャOS wwww

64 :仕様書無しさん:2015/03/20(金) 06:47:02.73
WEB系ならLinuxで十分だろ
もはや自前で構築することもないが

65 :仕様書無しさん:2015/03/20(金) 20:27:53.16
本当にできる奴は
会社辞めて起業する
出世して会社を変える

66 :仕様書無しさん:2015/03/20(金) 23:08:56.44
会社を変えようと考えてるような人間を出世させるわけねえじゃん

67 :仕様書無しさん:2015/03/21(土) 02:53:34.51
できない奴はできない理由を並べる

68 :仕様書無しさん:2015/03/21(土) 03:08:47.62
理由もなくできないと言った方がいいのか?

69 :仕様書無しさん:2015/03/21(土) 04:54:12.25
馬鹿「永久機関を作れって言ってるんだ。作れない理由を言うんじゃない。」

70 :仕様書無しさん:2015/03/21(土) 07:30:25.49
賢いおれ「出来ないのではなく、やらない」

71 :仕様書無しさん:2015/03/21(土) 08:37:42.75
できる人から見たら一目瞭然なのにわざわざ恥ずかしい嘘をつく

72 :仕様書無しさん:2015/03/21(土) 08:42:00.18
自分でも経験してないことを他人にやらせる
「できるけど、やらない」
アホw

73 :仕様書無しさん:2015/03/22(日) 01:14:45.90
会社が用意するPCを使わなければならない
自分の好きなPCのスペックなど選ばせてもらえない
本当に技術力の高い所は自分の好みで選んで買う

74 :仕様書無しさん:2015/03/22(日) 01:19:14.62
>>73
ちょっ、自腹購入wwwって思うのは自由だけどね

75 :仕様書無しさん:2015/03/22(日) 01:46:28.55
自腹購入なんて許されるわけないだろ
どんなルールゆるゆるの会社なんだよ

76 :仕様書無しさん:2015/03/22(日) 02:40:09.69
持ち運びしやすいモバイルノートでも無い限りは、BTOの一番下のランクにメモリを山盛りしたPCで
今どきは問題ないけどね。 変にSSDで128GB位のを使わされると、何時の時代だよって感じで
いらないファイルを消す作業に従事させられるから勘弁してもらいたいけど。

77 :仕様書無しさん:2015/03/22(日) 05:05:34.87
独立して起業すればいくらでもって自分の好きなスペックのPCが使えるぞ

78 :仕様書無しさん:2015/03/22(日) 05:13:09.36
>>77
そんなことしなくてもPCメーカー買収すれば
自分の好きなスペックのPCが使えるんじゃね?

79 :仕様書無しさん:2015/03/22(日) 05:27:11.01
零細企業なら割と自由にPCを選べる所が多いけどね
その代わりその場合大抵自腹だけど・・

80 :仕様書無しさん:2015/03/22(日) 05:33:23.16
法律違反

81 :仕様書無しさん:2015/03/22(日) 06:50:22.07
開発言語や自分好みのPCを使えるかどうかで会社の技術力を判断している時点で
そいつのレベルの低さが垣間見れる

82 :仕様書無しさん:2015/03/22(日) 06:53:53.12
>>73
自分では選べないとしても仕事内容に合わせた機種は与えるね
仕事内容や用途が理解されてないとゴミのようなPCが与えられるけど

83 :仕様書無しさん:2015/03/22(日) 06:56:47.72
>>81
俺は十分判断できると思うぞ?
チョイスする言語でも、選定するPCでも。

84 :仕様書無しさん:2015/03/22(日) 07:22:20.45
>>79
さすがに自腹はないけどかなりハイスペックなPCを買ってくれるね零細は
古くなればすぐに新しい機種を用意してくれるし
必要ならタブレットでもノートPCでも周辺機器でも希望するものを二つ返事で買ってくれる
少人数で動くから仕事はキツいだろうけどね

85 :仕様書無しさん:2015/03/22(日) 07:43:50.56
>>83
だよな

今時C#以外の開発言語やWindows以外で開発している企業は総じて技術力が低い

86 :仕様書無しさん:2015/03/22(日) 07:46:39.41
>>81
言語やPCは、必要条件だもんな。

87 :仕様書無しさん:2015/03/22(日) 07:47:45.90
開発に必要なスペックといっても、今時のPCならメモリさえ盛れば低価格PCでも開発には問題ないレベルだと思うが?

88 :仕様書無しさん:2015/03/22(日) 07:51:10.70
業務系の技術力なんてたかが知れているのに技術力がどうのこうのと騒ぐオマエラをみていると笑えるww

業務系プログラマーなんてゲームプログラマーと比べたら技術力では足元にも及ばないのになw

89 :仕様書無しさん:2015/03/22(日) 07:52:16.31
>>88
ゲーム開発の現場なんて高専、高卒の巣窟だろww

90 :仕様書無しさん:2015/03/22(日) 07:56:08.15
>>88
ゲームはゲームでもソーシャルゲームの開発現場は酷かったな
あれで金を取ろうって考えられるのが凄い
コンシューマも今はUnityが小難しい部分をほぼ吸収してくれるし

91 :仕様書無しさん:2015/03/22(日) 07:58:09.30
>>90
それでも業務系よりははるかにマシだろ

業務系開発は中卒やパートがやる仕事

92 :仕様書無しさん:2015/03/22(日) 07:59:39.01
>>89
学歴で語る人間ほど技術力が無いんだよな・・・

技術者は技術力で語る、無能は(誇れるものが学歴しかないので)学歴で語る

93 :仕様書無しさん:2015/03/22(日) 08:05:56.55
>>91
仕事の楽しさで言えばゲームの方が楽しいだろうけど
難易度は業務系が遥かに高いな、一歩間違えば多額の損害賠償で自殺だ

94 :仕様書無しさん:2015/03/22(日) 08:09:25.99
>>93
ゲーム系の開発なんて全然楽しくないぞ…
一ヶ月自宅に帰れないなんてザラだし、時給換算したら給料はコンビニバイトより少ないし

95 :仕様書無しさん:2015/03/22(日) 08:11:24.82
技術力なんて多種多彩なんだから他人に理解してもらえるわけないだろ
そんな理想の集団どこにいるんだよ

96 :仕様書無しさん:2015/03/22(日) 08:11:40.08
>>87
PCを一人一台しか割り当ててくれないとか、しょうもない制限がある会社は多い。

97 :仕様書無しさん:2015/03/22(日) 08:12:53.39
>>96
あ、それは開発の仕事じゃなくても地味に嫌だわ・・・

98 :仕様書無しさん:2015/03/22(日) 08:15:19.09
>>93
それは難易度じゃなくて影響の大きさ。
弁当工場の工員が「俺の仕事は、異物混入したら社長が謝罪会見開くんだぜ」
と自慢しているようなもの。

99 :仕様書無しさん:2015/03/22(日) 08:15:21.62
ユーザー企業勤務で内製開発しているけど開発用マシンはデュアルXeonとか普通にあてがってくれるぞ・・

100 :仕様書無しさん:2015/03/22(日) 08:19:40.52
>>98
そんな気楽なもんじゃないよ、今のIT業界の責任者なんて飾りで
コードを書いた本人が吊し上げられる

101 :仕様書無しさん:2015/03/22(日) 08:21:38.84
そりゃ、異物混入した本人はパート辞めさせられるだろう。

102 :仕様書無しさん:2015/03/22(日) 08:24:37.01
ゲーム自体最新技術の塊みたいなモノだからな、ゲームプログラマーの技術レベルが高いのもうなづける

103 :仕様書無しさん:2015/03/22(日) 08:35:16.79
>>101
クビだけならいいけどな

104 :仕様書無しさん:2015/03/22(日) 08:37:17.78
>>96
型落ちが一台だけだろ?
なんで何台も割り当てて貰えるんだよ
メモリなんて2GBだ

>>102
業務系はコアな技術はミドルウェアが吸収してくれるからな

105 :仕様書無しさん:2015/03/22(日) 08:37:17.79
>>102
確かにゲームプログラマーの技術力は他のプログラマーと比較しても抽んでてるよな

106 :仕様書無しさん:2015/03/22(日) 08:41:31.22
>>96
自分は運用サーバーと同じ環境のテスト用サーバーも含めて複数のPCを仮想で飼っているので
モニターさえ複数あればPCは一台で十分

その代わり自分の職場では開発用PCは無駄にハイスペックばかりだけどw

107 :仕様書無しさん:2015/03/22(日) 08:44:04.79
>>104
ゲームがミドルウェアの恩恵を受けていないと?

108 :仕様書無しさん:2015/03/22(日) 08:45:33.28
>>106
ミーティング用や外出先用は?

109 :仕様書無しさん:2015/03/22(日) 08:49:26.50
>>108
外出用はタブレットを一台あてがってもらってる。
内製なので外出先でコーディング等の作業が殆どない(偶にRDPで職場のPCに接続する程度)のでこれで十分

110 :仕様書無しさん:2015/03/22(日) 08:57:29.66
ユーザー企業の情シスのPCとか無駄にハイスペックなのが多いよな、羨ましい限りだわ

111 :仕様書無しさん:2015/03/22(日) 08:59:06.65
>>110
ユーザー企業は導入するPCを情シスが選定するところが多いからな。
そりゃ自分達が使用するPCには金をかけるだろよ。

112 :仕様書無しさん:2015/03/22(日) 09:31:06.41
技術力が低い会社ほど個人が希望するPCを与える

113 :仕様書無しさん:2015/03/22(日) 09:40:37.50
>>107
ゲームってポトペタとSQL投げる程度で完成するほど落ちぶれてるのか?

114 :仕様書無しさん:2015/03/22(日) 09:57:50.76
>>113
業務系がポトペタとSQL投げる程度で完成するとでも?

115 :仕様書無しさん:2015/03/22(日) 09:59:53.85
>>112
完全に逆だろ

116 :仕様書無しさん:2015/03/22(日) 10:03:48.22
色々と認証を受けてる会社は自由にできないからね
受託開発やSIerほど望まないPCが配布される

その点は自社開発のほうがいいのかもね

117 :仕様書無しさん:2015/03/22(日) 15:01:11.78
>>73で爆弾投下しておいたら、おまえら頑張ってるな
適当に書いたんだけど

118 :仕様書無しさん:2015/03/22(日) 15:21:49.66
>>117
技術指向の人間は給料上げるよりも
最新の開発環境とパーテーションあげるほうが喜ぶ

119 :仕様書無しさん:2015/03/22(日) 15:34:37.94
>>118
おれは給料も開発環境もパーティションも上がったら喜ぶな。
あと、もっとも嬉しいのは、まともな上司の下で働くことかな?

120 :仕様書無しさん:2015/03/22(日) 16:08:57.04
>>119
とっとと出世してマネージャーくらいまで出世すれば給料も開発環境もパーティションも思うがまま

実力があれば出世なんてチョロいだろ?

121 :仕様書無しさん:2015/03/22(日) 16:12:13.00
>>120
うちはみんな実力があるから
ほぼ全員がマネージャーだよ。

122 :仕様書無しさん:2015/03/22(日) 16:12:47.77
うちはほぼ全員が部長だな

123 :仕様書無しさん:2015/03/22(日) 16:31:09.84
>>119
まともな上司というか、まともな評価だな。
褒め称えよ、俺に傅けなんてことは少しも思わないが、
難しい作業をポンポン投げて来て、早く終わらせたら
誰にもアサインされていない浮いている作業を投げて、
それをやって当たり前みたいなのは嫌だなあ。

作業や評価の見える化()みたいなことを言っていて
色々バカなことしてるところ多いけど、難易度の高さや
浮いている作業に関して鈍感なところは多い。

やれば現場での心象はいいが、それが会社内での
評価にどの程度なっているか不透明だし、断れば
現場どころか会社内での評価も落ちるとかどんな
罰ゲームだよ。

124 :仕様書無しさん:2015/03/22(日) 17:43:40.22
俺はこんなにやってるのに評価されない
底辺リーマンの定番愚痴
評価されたいなら評価する側の視点を把握しろよ
俺様視点はどうでもいいから

125 :仕様書無しさん:2015/03/22(日) 18:24:57.12
パーティションはなくてもいいな、
こっち向いて大声で電話するようなキチガイさえいなければ。
逆にそういう騒音源があったら、パーティションは無意味。

126 :仕様書無しさん:2015/03/22(日) 18:48:33.13
>>124
> 俺はこんなにやってるのに評価されない

え? 誰かそんなこと言った?

127 :仕様書無しさん:2015/03/22(日) 18:57:39.07
>>124
なんか話がずれてないか?

給料の話じゃないよ。会社の設備の話だよ。
会社は儲けを追求するものなわけで、
お前は成果を出したから、生産性を上げるために
開発環境を新調してあげよう。これはご褒美だ。
っていうのはおかしい話でしょ?

工場で例えるなら、新人は手作業で機械を作りなさいって
言っているようなもの。これ会社の生産にとってはマイナスでしかないよね?

もちろん会社が貧乏であればどうしようもないが、
そうでないのなら生産性を上げるようにすることは
個人の評価とは無関係の話だよ。

128 :仕様書無しさん:2015/03/22(日) 19:42:11.12
>>124
なんでそんな脈絡のない話を?

129 :仕様書無しさん:2015/03/22(日) 19:58:35.62
評価されないのはおまえに興味がないからだよ
なんで嫌いな奴の良い所を見つけて出世の手伝いをしなきゃならないんだ

130 :仕様書無しさん:2015/03/22(日) 19:59:46.35
え? 会社の利益のために
嫌いでもやるもんじゃないの?

131 :仕様書無しさん:2015/03/22(日) 20:00:58.51
嫌いな事はやらないよ
社畜じゃないんだから

132 :ねこ:2015/03/22(日) 20:01:01.85
大学生で、アプリ作って月3万円儲けてるけど質問ある?
http://www.newsch.info/archives/7616515.html
アプリの広告収益儲かりすぎwwwwwwww
http://katsumoku.net/archives/6636584.html
【アプリ開発】今月のアプリの広告収益200万いったあああ【iPhone/Android】
http://neoneetch.blog.fc2.com/blog-entry-831.html
個人で年1億円の収入も スマホアプリ広告で大もうけできる?
http://trendy.nikkeibp.co.jp/article/pickup/20120614/1041485/
儲かる?儲からない?アプリの広告収入まとめ
http://appmarketinglabo.net/app-ad-revenue/
無名の個人がアプリを出して一週間! DL数、収益、周囲の反響は?
http://chemieclub.com/first-app-result/
広告収入5,000万円超え・・!?
中毒ゲーアプリ「白いとこ歩いたら死亡」作者が語るアメリカンドリーム。
http://appmarketinglabo.net/whitetile/
「最初はお小遣い稼ぎだった」上原さんがアプリ開発者になった理由と「新宿ダンジョン」ヒットの裏側。
http://appmarketinglabo.net/ueharalabo/
「アプリは何がヒットするかわからない、とにかく出す」メタップスCEO佐藤さんが語る世界で成功するアプリ。
http://appmarketinglabo.net/metaps-appmarket/
売上低迷にあえぐアプリを救った広告売上 収益最大10倍で起死回生
http://app-review.jp/news/167182 👀

133 :仕様書無しさん:2015/03/22(日) 20:03:17.28
>>131
そういって辞めさせられた人いるわwww

嫌いなことはやらないよ。

134 :仕様書無しさん:2015/03/22(日) 20:03:48.24
>>133
別に構わん。

135 :仕様書無しさん:2015/03/22(日) 20:05:07.76
>>134
じゃあ今すぐ仕事辞めてみて

136 :仕様書無しさん:2015/03/22(日) 20:07:26.61
>>135
辞める理由がない。

137 :仕様書無しさん:2015/03/22(日) 20:11:23.92
>>133
声や態度に出すバカはいない
よほど精神的に追い詰められてたか、もともと社会に不適合だったんだろう

138 :仕様書無しさん:2015/03/22(日) 20:13:28.64
人のスキルは言動にはっきりと表れる。
能力がある人は「やらない」とは決して言わない、たとえ出来ても「できない」と言う。
能力のない人は出来ないことに対して「出来ない」とは決して言わない、「やらない」と言う。

139 :仕様書無しさん:2015/03/22(日) 20:20:00.77
「やらない」
なんて聞いたことないが
どこの園児だよw

140 :仕様書無しさん:2015/03/22(日) 20:24:28.55
>たとえ出来ても「できない」と言う。

この時点で無能
自分がやらずともどうすれば目的を達成できるか、選択肢を提示出来るのが最低限

141 :仕様書無しさん:2015/03/22(日) 20:24:45.76
>>139
>>131
もっとも「やらない」はネット上で使うのであって
普段はやらないとは言わない、が「できない」とも言わない
できるふりをするのでいざ仕事を振ってみるとあれこれ理由を付けて拒む
口先ばかりでやれるスキルがないのをわかってて意地悪してるだけだけど

142 :仕様書無しさん:2015/03/22(日) 20:25:52.04
>>140
なんでも引き受けることが有能と思ったら、それは無能の考え

143 :仕様書無しさん:2015/03/22(日) 20:26:07.23
そこはお互いの妥協だろ。
会社の無茶ぶりに我慢出来なければ拒否する。
使いづらいと思われても、スキルと比較して役に立ってれば切られない。
最悪切られても他に行くところはあるしな。

144 :仕様書無しさん:2015/03/22(日) 20:27:56.05
なんでも引き受けるなどとは言っていない
明確な選択肢を提示すればよいだけ
上が判断できるように選択肢出せない奴は基本ゴミ

145 :仕様書無しさん:2015/03/22(日) 20:29:42.70
何でも引き受けるしか選択肢ないだろ

146 :仕様書無しさん:2015/03/22(日) 20:32:10.88
>>144
相手がそれを望めば当然意見を出すだろうが
断られてそれ以上の意見を望んでなければ口を挟まないだろう

147 :仕様書無しさん:2015/03/22(日) 20:32:42.13
お前ら出来ると言えばなんでもかんでも一人に集中する底辺会社に勤めてるんだな…

148 :仕様書無しさん:2015/03/22(日) 20:33:11.29
おまいらのスキルを向上させるのは会社ではなく自分だろ。
会社の言うことハイハイ聞いてても、なんにも残らんぞ。
自分を大事にしろよ。

149 :仕様書無しさん:2015/03/22(日) 20:34:26.75
まともにプログラミング出来るの俺だけだから仕方ないだろ
残りの奴らは営業と運用SEが片手間にコーディングしてる程度だ

150 :仕様書無しさん:2015/03/22(日) 21:20:00.22
ふむ、スレタイ通りという事だ

151 :仕様書無しさん:2015/03/22(日) 21:21:10.29
>>115
会社としての技術力が低いと、個人に頼らざるを得ない
→ 個人の希望が通りやすい
というのはある。

152 :仕様書無しさん:2015/03/22(日) 21:49:52.95
>>148
だな。
管理能力のない会社は結局できる人に際限なく仕事を集中させるから
自分でどこかに制限を付けないと確実に壊れる。
しっかり仕事してるなら時には拒むことも大事。

153 :仕様書無しさん:2015/03/22(日) 21:52:17.69
キャパ超えてるから調整してくださいってお願いしたら干されてクビにされた俺が通りますよ

154 :仕様書無しさん:2015/03/22(日) 21:52:59.87
>>152
俺は壊れてさんざんだよ。
異業種に転職したけど、休み癖は治らないw

155 :仕様書無しさん:2015/03/22(日) 21:54:08.10
>>151
技術的向上心や技術者への偏見がない会社ならそうかもしれないけど
技術力の低い会社って、大半が向上心はなく技術者への偏見も酷いから
適当にそこらのPCを渡しときゃ仕事できるだろ程度にしか考えてない。
目に余るほど環境が酷いと、ソフトやPC本体に至るまで自前のものを使ったりとかね。

156 :仕様書無しさん:2015/03/22(日) 21:55:19.79
お前らの視点の低さにどん引きだわ
お前らの思考回路は大前提として自身が何とかするという方法しかない
末端作業員しかいないんだな

157 :仕様書無しさん:2015/03/22(日) 21:56:10.54
いまだにPentium4だよ
Pentium3の次の奴ね
なにいってるかわからんと思うがw

158 :仕様書無しさん:2015/03/22(日) 22:02:34.76
>>156
管理者がまともなら末端作業員の負担は重くないはずなんだけどな

159 :仕様書無しさん:2015/03/22(日) 22:09:22.26
>>154
実害が出たなら法的手段も考えた方がいい
昔ならともかく今は過労、パワハラ、モラハラの裁判はごく日常的で
会社や個人を相手にほぼ確実に勝てるから

160 :仕様書無しさん:2015/03/22(日) 22:10:10.26
>>157
クロック周波数高いから余裕だろ?

161 :仕様書無しさん:2015/03/22(日) 22:11:39.65
>>160
チップセットも古いからメモリとかの同期周波数は低いんじゃない?

162 :仕様書無しさん:2015/03/22(日) 22:15:07.57
>>156
プログラマは技術力次第で100人の凡人と渡り合える職業なんだよ。

163 :仕様書無しさん:2015/03/22(日) 22:17:52.98
>>156
上がケツ持ちしてくれてそこまでしなくていいならやらないけどね。
現実は終電すぎでタクシーだの休出で振り休なしとか当たり前だったり
するからな。

政治力じゃ結局、ソフトウェアは動かない、無理を通せば道理は引っ込む
ようなことが出来ればいいのかも知れないけど、道理はコンピューター
だから、ソフトウェアをきちんと書かなければ絶対に動かないっていう。
なのでどうにか出来る奴がどうにかしなきゃならない。現場から離れて
新しい技術のキャッチアップもしてないような人だとどうにかしなきゃ
ならない時ほど役に立たないしな。

164 :仕様書無しさん:2015/03/22(日) 22:19:35.04
>>162
うははw
それで何作ってんの?
どうせよそ様のシステム作ってる下請けだろ

165 :仕様書無しさん:2015/03/22(日) 22:22:14.92
うちの会社も個人技の集まりみたいなもんだわ
だから人が抜けたら受注できなくなる仕事がある

166 :仕様書無しさん:2015/03/22(日) 22:23:05.41
>>164
一人社内SE
インフラも開発もやるぞ
システム部持つより安上がりだろ

167 :仕様書無しさん:2015/03/22(日) 22:32:04.08
>>163
上がケツ持ちとか意味不明なんだけど
終わるべくして終わらせろよ
それが出来ないなら諦めて終電がんばれ

168 :仕様書無しさん:2015/03/22(日) 22:33:23.09
いまだに残業が問題視されない会社の可愛そうな人たちの集いなのか

169 :仕様書無しさん:2015/03/22(日) 23:01:24.34
>>167
自分の仕事が終わらなければ同僚に勝手に手伝ってもらっても
大丈夫な会社にでも勤めてるの? 自分自身で何とかしなきゃと
思わせないようにするには上がどうにかするしか無いッペ?

170 :仕様書無しさん:2015/03/22(日) 23:05:44.26
終電だの休出だのしてる時点で何かが間違ってるとまず疑えよ
終わるべくして終わらせろというのはそういう意味だ
最初からお前は長時間労働を前提にしたスケジュールで仕事してんのかよ

171 :仕様書無しさん:2015/03/22(日) 23:09:54.18
とは言っても長時間労働が当たり前の職場ではそれが当たり前なんだろうな
んでもって毎回毎回疲弊してそういう狭い世界でしか通用しない社会人の出来あがりなんだなぁ

172 :仕様書無しさん:2015/03/22(日) 23:33:34.45
まずスレタイは技術力が低い会社にありがちなことなわけだ
終電だの休出ってのは技術力が低い会社にありがちなことってことでおk?

173 :仕様書無しさん:2015/03/22(日) 23:38:41.98
ここのスレの人間って技術云々以前に社会人としての最低限のスキルが欠けている気がする
海外のプログラマーはプログラミング能力はもとより、コミュニケーション能力、交渉力、政治力にも長けているのに
日本のプログラマーはプログラミング能力だけで他のスキルはまるで新人以下・・・

そりゃ海外に比べて日本のプログラマーのレベルが低い訳だわ

174 :仕様書無しさん:2015/03/22(日) 23:41:31.64
>>172
ありがちだね。
技術的な売りがないから、24x7でお客様に対応いたします状態なところとか。

175 :仕様書無しさん:2015/03/22(日) 23:49:02.26
2ちゃんでは何故かやたらと海外のプログラマはと言い出す奴いるが、
お前は実際にそこで働いた経験があって実物見て言ってんのかと。

>プログラミング能力はもとより、コミュニケーション能力、交渉力、政治力にも長けている

こんなスーパーマンがどれだけの割合でいるのかねぇ

176 :仕様書無しさん:2015/03/22(日) 23:54:06.46
コミュニケーション能力や交渉力に長けていなくてもいいけど
せめて普通の社会人並みのコミュ力、交渉力がないとただのプログラムが組める現場作業員でしかないぞ

177 :仕様書無しさん:2015/03/22(日) 23:55:35.91
インドのまともに英語も話せないやつらに仕事を奪われる海外スーパープログラマーwww

178 :仕様書無しさん:2015/03/22(日) 23:56:10.59
このスレの内容ってまんま無能なサラリーマンの愚痴だよなぁ

179 :仕様書無しさん:2015/03/22(日) 23:58:05.86
技術力が高い会社って終電や休出ないの?
例えばGoogleやMicrosoft、日本だったら昔のライブドアやはてなあたりか?

Oracleは残業なさそうだけどw

180 :仕様書無しさん:2015/03/23(月) 00:01:18.79
自分では何も行動せず全て他人任せ、そのくせ都合の悪いことは全て会社、上司、環境のせい。
ホント絵に描いたような無能な人間の典型だなw

181 :仕様書無しさん:2015/03/23(月) 00:03:54.84
ライブドアって自分自身が使用するPCは自腹だったよな
スーツや鞄と同様、社会人ならPCくらい自前で容易してあたり前というスタンスだったはず

182 :仕様書無しさん:2015/03/23(月) 00:05:53.00
>>179
ここの住人のレベルじゃGoogleやMicrosoftだと門前払いだと思うが?

183 :仕様書無しさん:2015/03/23(月) 00:11:41.89
GoogleやMSだとそれこそ>>173のいうスーパーマンみたいなのが標準レベルだからなあ

184 :仕様書無しさん:2015/03/23(月) 00:15:05.03
>>173
違う違う、日本と海外の違いはプログラマーではなく上流を担ってる人間の質の違い。
海外は全員がハイスキル、つまり当然のようにスキルの高い人間が上流も担っているが
日本はスキルの低い人間ほど上流に行きたがり、大した仕事もできないから下流に丸投げる方式をとる。

当然、スキルが高い人間に対する劣等感は異常で、その差は誤魔化しようがない。
だからスキルの高さは認める。それ以外の部分は劣等感による思い込みが大増幅して>>173のような人になる

185 :仕様書無しさん:2015/03/23(月) 00:17:53.17
結局、勤めている会社のレベル=自分自身のレベルなんだよ。

186 :仕様書無しさん:2015/03/23(月) 00:19:53.19
>>184
そのスキルが低い人間にいいようにコキ使われている時点で彼らよりレベルが低いということに何故気付かない?

187 :仕様書無しさん:2015/03/23(月) 00:21:53.62
>>184
発想がまるで現場の土方と同じレベルだなw

188 :仕様書無しさん:2015/03/23(月) 00:22:20.76
>>185
転職なんてそう何度もできるもんじゃないし
レベルの高い人は独立するわけか

189 :仕様書無しさん:2015/03/23(月) 00:24:43.83
>>186
コキ使ってると勘違いしてる時点で脳味噌がお目出度いのよ

190 :仕様書無しさん:2015/03/23(月) 00:24:45.17
なぜフリーのLinuxではなくて、有料のWindowsが普及してしまったんだろうな。
普通、タダのものが有料の(それも結構高いw)ものに負けるか?
もう少し早くLinuxが誕生していればあるいは

191 :仕様書無しさん:2015/03/23(月) 00:35:10.56
>>190
激しく悩んでるようだが簡単な話で、日本の企業は「カタチ」が好きなんだよ。
どれほど優れていても無料のものは使えない、どんな駄作でも有料だと安心できる。
ここはそういう国。

192 :仕様書無しさん:2015/03/23(月) 00:36:48.40
>>190
カーネルだけじゃ使い物にならんからな。

193 :仕様書無しさん:2015/03/23(月) 00:38:35.82
>>190
デスクトップ以外はLinuxが十分普及してると思うけど?
もうLinuxに関わらずにこの業界続けるのは無理じゃね?っていうくらい。

>>191
海外でも状況は同じ。

194 :仕様書無しさん:2015/03/23(月) 00:45:24.19
2chでよく、海外だと〜なのに日本は〜だからダメ
というカキコを見かけるけどはっきり言って海外を美化し過ぎ

195 :仕様書無しさん:2015/03/23(月) 01:55:53.82
>>191
ただほど高いものはない

196 :仕様書無しさん:2015/03/23(月) 09:40:45.12
>>190
値段が比較されるのはどちらも十分に用件を満たしている場合
Windwosは技術者の育成に力を入れてきた
おかげで労働力が大量に安価に集められる

技術者の安定供給はプラットフォームにとって重要

Linux陣営はLinuxが普及すればいいと思っているが
だからといって何も手を動かす事はしない
例えば初心者向けの記事を書いたり便利なソフトウェアを作ったりという事は忌避される

Linuxはたった一つの優れた解決方法を持っているべきで、初心者の為にシンプルさを崩すべきではないと考えるからだ

Linux陣営が考える普及とは人類がLinuxに追いつくことであって、Linuxが人類に妥協する事ではない

197 :仕様書無しさん:2015/03/23(月) 11:20:25.42
>>196
>例えば初心者向けの記事を書いたり

やってるだろ。
インストールの記事だらけじゃないか。
インストールだけね。

198 :仕様書無しさん:2015/03/23(月) 11:25:02.39
(初心者)「オープンオフィスのバグ見つけました。HTMLで保存するとAタグが正しく記述されない場合があります。再現方法は・・・」
(Linuxユーザー)「本家にレポート出せよ。英語ね。それにHTMLで保存なんて使わない機能なんだから修正する必要ないだろ」

これが現実

199 :仕様書無しさん:2015/03/23(月) 12:31:29.34
>>196
人類の覚醒を待ってるのか

200 :仕様書無しさん:2015/03/23(月) 12:55:59.41
タダなのに流行らない。過去の資産があるから。ソフトウェアは恐ろしいね。
OfficeとWindows押さえている限りMSは安泰。上手くやったものだ。

201 :仕様書無しさん:2015/03/23(月) 14:32:44.61
確かに最近のLINUXはGUI化が進んでるとは思うが

・古参がその状況についてこない。初心者の質問にも必ずコマンドで回答。
・業界標準のUBUNTUが糞すぎるUIをゴリ押し
・GUI化はまだ不完全。例えば音声を16bit/44.1kHzでなく24bit/44.8kHzで出したいとき
 WindowsみたくGUIで簡単に切り替えられるか?

202 :仕様書無しさん:2015/03/23(月) 14:33:57.81
CUIマニアならともかく一般の人にはCUIは敷居が高すぎるだろ。

Linuxが普及しない一番の原因だよ。

203 :仕様書無しさん:2015/03/23(月) 14:34:48.63
LinuxはWindowsよりもフリーソフト導入の敷居が高い
配布の敷居が高いと言い換えてもいい

204 :仕様書無しさん:2015/03/23(月) 17:46:44.60
毎回思うが、なぜUNIXには触れないのか?

205 :仕様書無しさん:2015/03/23(月) 18:51:13.09
高すぎ

206 :仕様書無しさん:2015/03/23(月) 18:55:36.01
UNIXなんてデータセンターで鎮座してるのを見たことがあったり
暇なときに自作PCにインストールしてみたりする程度で
実働してるの見たことないや

やっぱすごいの?

207 :仕様書無しさん:2015/03/23(月) 21:04:44.22
いや別にすごくない

フリーでここまでやるかという意味では凄いけど
商売という観点で見たらwindowsのほうが安心して任せられる印象

208 :仕様書無しさん:2015/03/23(月) 21:08:02.54
>>200

仕事でコンピュータ使う時であっても

コンピュータを趣味にしてるわけじゃないのだから
使いやすく直感的に使えるようにするのは真っ先に大事なことだろ

そういう意味でマッキントッシュは優れてたけど
業務という視点ではwindowsが圧倒的に優れてた

まあwindowsXPで勝負あった感あるね

209 :仕様書無しさん:2015/03/23(月) 22:01:26.09
>>207
はあ?

210 :仕様書無しさん:2015/03/23(月) 22:11:26.54
Windowsの方が簡単なんだからWindowsが流行るにきまってる
linux使ってるがapacheの設定まともに出来ない会社とかあって笑うわ
こういう連中は何なんだろうか

211 :仕様書無しさん:2015/03/23(月) 22:16:15.49
簡単とか難しいとかより、金を出して解決するかどうかだろう

212 :仕様書無しさん:2015/03/23(月) 22:41:07.16
Windowsのいいところは、その他のマイクロソフト製品の問題もマイクロソフトに丸投げできるところ。

それくらいしかメリットはない。

213 :仕様書無しさん:2015/03/23(月) 23:59:36.43
Windowsは銀行や証券取引所で使用されるくらいだから安定性派相当高いと思う。
実際メインフレームやUNIX並みの信頼性というのは結構有名な話。

Linuxは・・金のかかるシステムで使用されているところは一度も見たこと無い、
というかLinuxなんて不安定過ぎて商用では使い物にならんだろ。

214 :仕様書無しさん:2015/03/24(火) 00:58:31.77
単にサポートが無いのが気になるのとCUIでとっかかりにくいだけだろ

215 :仕様書無しさん:2015/03/24(火) 01:18:31.91
Linuxなんてリセットしなきゃならんからデータセンターに置くの怖いじゃん
昔は何度もデータセンターにいってそのまま直帰してたわ

今はリモートでリセットぐらいできるのか?

216 :仕様書無しさん:2015/03/24(火) 01:26:51.43
珍しくwindowsが優勢だな…w

217 :仕様書無しさん:2015/03/24(火) 06:13:00.19
>>216
珍しいもなにももともとLinuxがWindowsに勝てる要素なんて1ミリもないじゃん・・w

218 :仕様書無しさん:2015/03/24(火) 06:13:25.66
全く使用するメリットが見出せないLinux

・安定性・信頼性
 Linux
 フリーソフトであるLinuxの安定性・信頼性はハッキリ言って問題外。
 1日連続で稼動させることすら困難。

 Windows
 いまやWindowsの安定性・信頼性はメインフレーム(汎用機)をも凌ぐ。
 世界中のメインフレームが全てWindowsServerに置き換わったのがその証拠。

・脆弱性
 Linux()
 Linuxで稼動している世界中のサーバーがクラックされまくっている。
 シェアが全くないLinuxはウイルス対策ソフトも皆無。

 Windows
 デファクトスタンダードOSとしてあらゆる攻撃を受けてきたWindowsはいまや世界で一番強固なOSとなった。
 豊富なウイルス対策ソフトもさりながら、カーネルの構造的に絶対に外部からクラックされることが無いOSとなった。

コスト
 Linux
 フリーソフトなのでOSは無料。
 しかし上記内容により安定稼動させるのはほぼ不可能。
 またサポートが存在しないため自前で何とかするしかなくかえってコスト高となる。

 Windows
 OSは無料ではないが従来のメインフレームのOSと比較すると安価。
 もともと安定性に優れたOSであるため、誰にでも安定稼動させることが容易である。
 サポート面もマイクロソフトを始め、各ベンダーが完璧なサポートを行える体制となっている。
 またコンピュータOSとしてほぼ100%のシェアを誇っているので情報が豊富である。

219 :仕様書無しさん:2015/03/24(火) 06:14:36.55
・DiskI/Oを駆使するアプリケーションをがんがんまわすとOSがフリーズするか最悪HDD自体が死亡します。
・Linuxはセキュリティパッチが非常に多く出回るので油断ができません。Windowsより危険なんじゃないかと個人的に思っています。
・WEBサーバとしては最適ですがDBサーバとしては決して使いたくないOSです。
ttp://nosa.cocolog-nifty.com/sanonosa/2004/06/windows_vs_unix.html

220 :仕様書無しさん:2015/03/24(火) 06:14:57.00
>>215
クラウド

221 :仕様書無しさん:2015/03/24(火) 06:15:04.30
-- Windows搭載NASとLinux搭載NASの比較 - ELECOM --

【こんなに違うの!? 同時アクセスでの転送速度が段違い!】
同時接続でも転送速度が圧倒的に早いWindows OS搭載NAS!
速度の違いは業務効率にも影響を与えます!

ttp://www.elecom.co.jp/business/pickup/nas/201102/index.html

「ファイルサーバー、小型NASは安いものを選べ」本当にそれでいい?

― ファイルサーバー、または小型NASがさまざまな場所で便利に使われているが、
製品選択では「価格の安いものを買う」というケースが多いようだ。
値段が安くなりやすいのはLinuxをベースとしたNAS製品だが、
それだけでLinux搭載NASを選ぶのはもったいない、と専門家は警鐘を鳴らしている。

ttp://www.atmarkit.co.jp/ad/ms/1102windowsnas/1102windowsnas.html

222 :仕様書無しさん:2015/03/24(火) 06:15:37.58
組込みシステム/組込みソフトウェア|ユーザインタビュー|イーソル
http://www.esol.co.jp/embedded/interview_01.html

> Linuxを利用していたときには、原因不明のハングアップがよく起こりました。
> 100個、200個といったレベルで積み重なっている問題をひとつひとつ、根気強くつぶし、
> ようやく動く、という状況でした。

Linuxはまともに動くことさえままならない。これが厳然たる事実。

223 :仕様書無しさん:2015/03/24(火) 06:16:10.72
想像をはるかに超える高速性と安定性を持つWindows ServerをメインにWindows環境でインフラを構築
http://gihyo.jp/admin/serial/01/gloops/0001

たとえばWindows環境のメリットの1つに,
IISとASP.NET,そしてC#で書かれたアプリケーションが
想像をはるかに超える高速性を実現していることが挙げられます。
そのうえ,安定して動作しているのです。
Javaを中心としたプラットフォームのものと比べると,
もう全然比較にならないぐらい安定していると感じています。

224 :仕様書無しさん:2015/03/24(火) 06:16:38.80
驚くほど簡単に”できたらいいな”を実現する
小規模サーバーはWindowsの時代
http://www.mouse-jp.co.jp/business/mpro-sv/?cid=mpro_sv

225 :仕様書無しさん:2015/03/24(火) 06:18:43.60
CLIが扱えないプログラマーって・・・w

226 :仕様書無しさん:2015/03/24(火) 06:20:44.39
>>218-224
どんだけLinuxにコンプレックスを持ってるんだよwww

227 :仕様書無しさん:2015/03/24(火) 06:22:20.26
これが噂の無職Windowsさん?

228 :仕様書無しさん:2015/03/24(火) 06:25:02.84
>>215
いつ落ちるか判らないWindowsより遥かにマシかと思うが?
Linuxなんて一度設定が済めば年単位で無停止稼動できるし

229 :仕様書無しさん:2015/03/24(火) 06:46:25.47
Windowsは異常終了の可能性を常に気にするし落ちたの何度か見たことあるけど
Linuxでそれは気にしたことがないし実際落ちたことがない

230 :仕様書無しさん:2015/03/24(火) 07:15:59.90
>>228
セキュリティアップデートがたくさんあるのに
それを放置するとか怖すぎるだろ。

231 :仕様書無しさん:2015/03/24(火) 07:19:33.52
自分でリブートしない限り落ちない

232 :仕様書無しさん:2015/03/24(火) 08:19:00.86
>>230
個人ので使用するPCじゃあるまいし、普通運用サーバーで闇雲にパッチなんて当てないし
Linuxの場合パッチを適用して再起動が必要なのはカーネルを更新した時くらいで
通常はパッチを適用したデーモンの再起動かリロードて済む

大体パッチなんて稼働している既存のシステムへの影響を検証するのにそれなりの工数がかかるので
余程致命的か重要性の高いパッチ以外めったに適用しない

233 :仕様書無しさん:2015/03/24(火) 12:02:08.51
>>226
数年前のコピペだね。

234 :仕様書無しさん:2015/03/24(火) 23:13:02.36
>>207
いや、全然フリーじゃないし
電話掛ければエンジニアが駆けつけて問題解決してくれるUNIXベンダーのほうが安心。

235 :仕様書無しさん:2015/03/25(水) 04:01:43.93
何かと思ったらUNIXをフリーだと思ってる奴がいるのか
Windowsより遥か前からマルチタスク、マルチユーザに対応した
WS採用の超安定商用OS
Windows95が出る前はXでクライアントOSとしても広く使用

UNIX互換はいくつかあるが、その一つのLinuxはオープンソースで
UNIX同様多種あるが、こちらもOS自体の信頼性は高く使い易い
ただGUIベースのWindowsと比べたら難易度が高いので
近年では敬遠してるIT企業や社内SEが多い

236 :仕様書無しさん:2015/03/25(水) 06:46:02.69
またにわかが...

237 :仕様書無しさん:2015/03/25(水) 08:23:08.20
>>236
またにわかが!

238 :仕様書無しさん:2015/03/25(水) 08:34:30.98
>>207
フリーって、2つの意味(無料、著作権)が有るよ。
MSの枠内でよければwindows、それでは足りない場合はlinuxも選択肢に入るってだけ。
運用の安定化とかまで関わった場合、どっちも工数は大差無かったよ。

239 :仕様書無しさん:2015/03/25(水) 11:34:15.94
今まで企業向けでLinuxなんて普及した事ないだろ
WEB系のアプリケーションサーバに使われてたぐらいだろう

240 :仕様書無しさん:2015/03/25(水) 14:17:21.96
今時企業向けで大規模なシステムなんてほとんどwebベースだろ
小規模なシステムならPCにインストールして使用するタイプもあるだろけど

241 :仕様書無しさん:2015/03/25(水) 14:28:22.95
DBサーバなどに比べて重要度の低いシステムで使われているのではないかという事ね

242 :仕様書無しさん:2015/03/25(水) 15:43:24.15
重要性の高いDBサーバーをパフォーマンスや安定性でLinuxより遥かに劣る
WindowsServerで走らせる方が正気の沙汰じゃない気がする

243 :仕様書無しさん:2015/03/25(水) 15:45:15.77
Windowsサーバーって数ある商用のサーバーOSで唯一通常稼働で落ちるOSだからな・・・

244 :仕様書無しさん:2015/03/25(水) 18:19:53.02
Windowsサーバーで落ちた事ないけど・・・
おまえら本当に自分の体験で語ってるか?作り話を真に受けてないか?

245 :仕様書無しさん:2015/03/25(水) 19:51:40.28
同じく
Windowsサーバを物理も仮想も複数台導入しているが、落ちたことはない

246 :仕様書無しさん:2015/03/25(水) 23:23:19.93
【全ての分野においてWindowsが圧勝】
東京証券取引所の基幹システムとして稼動するWindows
ttp://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548
HPCでもダントツのパフォーマンスをたたき出すWindows
ttp://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html
Windows上で稼動するメインフレーム
ttp://wsmgr.jp.brothersoft.com/screenshot-50450.html
NASパフォーマンス比較テストでWindowsがLinuxを圧倒!!
ttp://www.flexense.com/documents/nas_performance_comparison.pdf
BDレコのOSはやはりWindowsだった!!
ttp://it.slashdot.jp/story/12/04/24/0052242/

【一方Linuxは…】
Linux Daily Topics:2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に|gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02
Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
ttp://japan.internet.com/webtech/20110902/2.html
Linux Daily Topics:2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に|gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15
Linux Daily Topics:2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に|gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02
Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
ttp://japan.internet.com/webtech/20110902/2.html
Linux Daily Topics:2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に|gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15
MySQL.comのWebサイトに不正なコード 闇市場でroot権限も販売か
ttp://www.itmedia.co.jp/news/articles/1109/27/news027.html
またもOSSプロジェクトが被害に! Wineプロジェクト、不正侵入を発表 | エンタープライズ | マイコミジャーナル
ttp://journal.mycom.co.jp/news/2011/10/13/115/index.html
「OpenSSL」の heartbeat拡張に情報漏えいの脆弱性
ttp://scan.netsecurity.ne.jp/article/2014/04/08/33945.html

247 :仕様書無しさん:2015/03/25(水) 23:24:00.52
全く使用するメリットが見出せないLinux

・安定性・信頼性
 Linux
 フリーソフトであるLinuxの安定性・信頼性はハッキリ言って問題外。
 1日連続で稼動させることすら困難。

 Windows
 いまやWindowsの安定性・信頼性はメインフレーム(汎用機)をも凌ぐ。
 世界中のメインフレームが全てWindowsServerに置き換わったのがその証拠。

・脆弱性
 Linux
 Linuxで稼動している世界中のサーバーがクラックされまくっている。
 シェアが全くないLinuxはウイルス対策ソフトも皆無。

 Windows
 デファクトスタンダードOSとしてあらゆる攻撃を受けてきたWindowsはいまや世界で一番強固なOSとなった。
 豊富なウイルス対策ソフトもさりながら、カーネルの構造的に絶対に外部からクラックされることが無いOSとなった。

コスト
 Linux
 フリーソフトなのでOSは無料。
 しかし上記内容により安定稼動させるのはほぼ不可能。
 またサポートが存在しないため自前で何とかするしかなくかえってコスト高となる。

 Windows
 OSは無料ではないが従来のメインフレームのOSと比較すると安価。
 もともと安定性に優れたOSであるため、誰にでも安定稼動させることが容易である。
 サポート面もマイクロソフトを始め、各ベンダーが完璧なサポートを行える体制となっている。
 またコンピュータOSとしてほぼ100%のシェアを誇っているので情報が豊富である。

248 :仕様書無しさん:2015/03/25(水) 23:36:30.47
WindowsはLinuxと比較してパフォーマンスが劣るのとメモリとHDDのリソースをバカ食いするのがなぁ・・・

249 :仕様書無しさん:2015/03/25(水) 23:42:08.87
あ〜あ、Linuxなんて採用するかこんな事に・・・w

みずほ銀行次期システム開発が順調に破綻中らしい
ttp://hello.2ch.net/test/read.cgi/infosys/1425616464/

250 :仕様書無しさん:2015/03/26(木) 00:48:10.53
みずほやっぱり駄目か

251 :仕様書無しさん:2015/03/26(木) 06:08:44.62
OpenSSL 1.0.1/1.0.2系に脆弱性、秘密鍵漏えいの恐れも
ttp://www.atmarkit.co.jp/ait/articles/1404/08/news134.html

>例えばRed Hat Enterprise Linux 6/6.5、Ubuntu 12.04.4 LTSなど、
>主要なLinuxディストリビューションやBSD系OSも脆弱なバージョンのOpenSSLを含んでいる可能性があるため、
>注意が必要だ

         ____
  .ni 7      /ノ   ヽ\  プゲラッチョ
l^l | | l ,/)   / /゚ヽ  /゚ヾ\      .n
', U ! レ' / /   ⌒   ⌒  \   l^l.| | /)
/    〈 |  (____人__)  |   | U レ'//)
     ヽ\    |lr┬-l|   /  ノ    /
 /´ ̄ ̄ノ    ゙=ニ二"   \rニ     |
                      `ヽ   l
  ─┐||┌─┐ l ─  ‐┼‐   ‐┼‐ヽ l  ノ │ .|  |   ‐┼‐ ‐┼‐
        日  フ 口  メ   __|__  フ |┬   |  |   ‐┼‐  d
  (__   .六  ↑ .田  (___  (丿 ) ↑.ノ│  ノ  ヽ__ノ (丿\ ノ

252 :仕様書無しさん:2015/03/26(木) 06:10:15.76
ファイルサーバー:CentOS5.7(Samba3.6.2) CPU:AthlonX2 4850e
-----------------------------------------------------------------------
CrystalDiskMark 3.0 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 113.188 MB/s
Sequential Write : 111.956 MB/s
Random Read 512KB : 107.814 MB/s
Random Write 512KB : 106.552 MB/s
Random Read 4KB (QD=1) : 8.405 MB/s [ 2052.0 IOPS]
Random Write 4KB (QD=1) : 8.542 MB/s [ 2085.5 IOPS]
Random Read 4KB (QD=32) : 60.464 MB/s [ 14761.8 IOPS]
Random Write 4KB (QD=32) : 57.562 MB/s [ 14053.1 IOPS]

OS : Windows 7 Ultimate Edition SP1 [6.1 Build 7601] (x86)
-----------------------------------------------------------------------
CrystalDiskMark 3.0 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 266.745 MB/s
Sequential Write : 81.424 MB/s
Random Read 512KB : 202.085 MB/s
Random Write 512KB : 60.541 MB/s
Random Read 4KB (QD=1) : 24.724 MB/s [ 6036.2 IOPS]
Random Write 4KB (QD=1) : 36.132 MB/s [ 8821.4 IOPS]
Random Read 4KB (QD=32) : 164.043 MB/s [ 40049.6 IOPS]
Random Write 4KB (QD=32) : 54.267 MB/s [ 13248.7 IOPS]

W i n d o w s 大 勝 利 !!

253 :仕様書無しさん:2015/03/26(木) 06:11:59.67
「ファイルサーバー、小型NASは安いのを選べ」 本当にそれでいい?

ttp://www.atmarkit.co.jp/ad/ms/1102windowsnas/1102windowsnas.html


結果は非常に面白い。Windows Storage Server 2008 R2搭載NASは17分28秒でコピーが終了した。
これに対し、Windows Server 2003 R2搭載機では41分21秒と2倍以上の時間が必要だった。
さらにLinux搭載NASでは9時間38分5秒。つまり、Windows Storage Server 2008 R2搭載機に比べ、30倍以上もの時間が掛かったことになる。
Windows Storage Server 2003 R2搭載機と比べても、約14倍の時間が掛かっている。1、2倍ならまだしも、
これだけの開きが出てくると仕事で使う際のストレスがまったく違ってくる。

254 :仕様書無しさん:2015/03/26(木) 06:12:46.12
AWS+Windows環境における大規模ソーシャルゲーム開発/運用の実際
http://gihyo.jp/admin/serial/01/grani/0001?ard=1400553863

> 実は,弊社も立ち上げ時にはLAMP環境でアプリを提供しており,
> 途中でC#+Windows環境に完全リプレースしたのですが,
> アプリ側のロジックはほぼ同じだったにもかかわらず,
> レスポンスタイムで5〜6倍の数値,サーバとしても
> 2〜3倍のリクエストをさばけるようになったため,
> サーバの台数が半分以下になってサーバ代はむしろ安くなった,
> というエピソードがあります。

255 :仕様書無しさん:2015/03/26(木) 06:15:27.61
技術者のスキルなんて適当でいいやって考えで
適当にかき集めて頭数だけ揃えてるから
そもそもPM、PL、SEが下流頼みのゴミだらけだったんだろうし

256 :仕様書無しさん:2015/03/26(木) 08:23:16.16
昔はSEやPMって上級プログラマーの進化形態だったのに、最近プログラムが書けないSE、PMばかりと投入してる言うことは
最近のプログラマーはSEやPMになれるほどのスキルがないということ?

257 :仕様書無しさん:2015/03/26(木) 09:18:22.97
近頃はプログラマーはプログラミングスキルだけあれば他は何もいらない、と本気で勘違いしている馬鹿が多いからな
結果、プログラマーという職種はコミュ力も交渉力もない労働作業者ばかりになってしまい上流がのさばるようになってしまった・・・

258 :仕様書無しさん:2015/03/26(木) 11:52:14.27
というやつが、プログラミングできるのであれば
説得力も有るんだが、何も出来ない奴が偉そうに
語ってるだけなんだよな。

機能を作らなくていいように交渉する前に
機能を作って客を満足させようぜ!

259 :仕様書無しさん:2015/03/26(木) 12:26:28.70
結局上流も下流もどっちもどっち、目糞鼻糞

260 :仕様書無しさん:2015/03/26(木) 12:27:46.96
今時社内サーバーにWindowsを採用していない企業は総じて技術力が低い

261 :仕様書無しさん:2015/03/26(木) 12:28:01.78
Linux(笑)

262 :仕様書無しさん:2015/03/26(木) 12:35:24.81
真のハッカーなら、windowsw!
これは世界的な事実!

263 :仕様書無しさん:2015/03/27(金) 07:16:18.18
>>257
そうだな。一人前のプログラマとして認めてもらうにはプログラミングスキル以外に、
OSやハードの知識も必要だし、各種アルゴリズムに関する知識も必要だよねー
プログラマは言われた通りにプログラム書ければいいと思ってる馬鹿が多すぎる。

264 :仕様書無しさん:2015/03/27(金) 13:43:26.04
技術力の低い会社ほど
うちは技術力が高いと思い込んでるんだよな
あの根拠はなんだろう?

265 :仕様書無しさん:2015/03/27(金) 18:14:39.58
そう考えないと自分の価値が亡くなってしまう
最近、日本の良い所を放送するようになったのと同じなんだろうな

266 :仕様書無しさん:2015/03/27(金) 18:58:06.68
>>263
現実に合わせる心の余裕は欲しい

口だけの老人にはなりたくないものだ

267 :仕様書無しさん:2015/03/27(金) 19:33:47.36
無能残業して時間報酬相場下げるな!
【知的財産と受注料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒

偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
裁判無関心
残業見積
安売競争
利益提供
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死

268 :仕様書無しさん:2015/03/27(金) 23:26:26.26
>>264
思い込んでる所は向上しないから、相対的に低くなるんでは?

269 :仕様書無しさん:2015/03/28(土) 07:40:33.47
高所得者やエリートほど現状の日本に楽観し、
低所得者や落ちこぼれほど現状の日本に悲観するのは何故だろう・・・?

270 :仕様書無しさん:2015/03/28(土) 07:45:40.21
悲観してるのが現実で、楽観してるのは現実が見えてない世間知らずだろ

271 :仕様書無しさん:2015/03/28(土) 08:31:55.77
>>269
底辺が現状の政府、国家に悲観するのは人類の有史始まって以来繰り返してきたことで
別に今始まったことでもってないし。

272 :仕様書無しさん:2015/03/28(土) 08:34:46.52
自分が虐げられている場合、
自分の置かれている現状を他人のせいにしようとするのは一種の本能みたいなものだからな

273 :仕様書無しさん:2015/03/28(土) 08:38:20.11
日本に絶望するくらいならとっとと海外へ移住すればいいのに。
国によっては移住なんてそれ程難しい事でも無いだろうし。

274 :仕様書無しさん:2015/03/28(土) 08:42:58.92
そういや在日って日本に対してあれだけ不満を並べてるのになんで半島へ帰らないんだろうね・・

275 :仕様書無しさん:2015/03/28(土) 09:02:00.01
日本は低所得者から税金社会保険料で持ってく量が多いからな ほかの先進国と比べて
つまり中流下流ほど負担が大きい世の中なのさ
だから上流階級は楽観というか楽なんだよ

276 :仕様書無しさん:2015/03/28(土) 09:25:20.04
つ共産国
極一部の特権階級を除け基本的に国民は全て平等

277 :仕様書無しさん:2015/03/28(土) 11:50:51.96
>>275
普通に所得が多いほうが取られる量は多いぞ?
お前みたいに数字が読めず、ふいんきでものを言うのが多いのが問題なんだろ。

278 :仕様書無しさん:2015/03/28(土) 12:00:45.31
>>277
> 普通に所得が多いほうが取られる量は多いぞ?

マジか? そんな世界・・・知らなかった! (>>275の心の声を代弁)

279 :仕様書無しさん:2015/03/28(土) 12:03:48.97
みんな平等!お金儲けは悪いこと!!

280 :仕様書無しさん:2015/03/28(土) 12:05:14.11
みんな平等!お金儲けは悪いこと!!

281 :仕様書無しさん:2015/03/28(土) 12:12:51.10
>>280
お布施お願いします。

282 :仕様書無しさん:2015/03/28(土) 12:57:24.18
>>278
https://www.nta.go.jp/taxanswer/shotoku/2260.htm
課税される所得金額 税率 控除額
195万円以下 5% 0円
195万円を超え 330万円以下 10% 97,500円
330万円を超え 695万円以下 20% 427,500円
695万円を超え 900万円以下 23% 636,000円
900万円を超え 1,800万円以下 33% 1,536,000円
1,800万円を超え 4,000万円以下 40% 2,796,000円
4,000万円超 45% 4,796,000円

↑を見て「低所得者のほうが持ってく量が多い」と思える頭がヤバイよ。
低所得者は可処分所得のほとんどが生活費で消えるから貯蓄や教育に
回せる金が少なくなるから格差が広がるみたいなのならまだ分からなくは
ないけど。

283 :仕様書無しさん:2015/03/28(土) 13:19:47.16
>>282
健康保険や住宅費やその他が、
一律でかかってくるからね。日本は。

最低150万はそれらがかかる。
だから年収200万位の人は、可処分所得が年10万くらいしかなく
サラ金から借りないと食えない。

世界中でこういう制度は日本だけ。

284 :仕様書無しさん:2015/03/28(土) 13:47:32.29
>>283
え?アメリカみたいに健康保険制度がなくて、貧乏人は病気になったら
死ねって国になったらいいの?

285 :仕様書無しさん:2015/03/28(土) 13:58:49.52
アメリカだと、入院1日で100万超えとかザラだからな

286 :仕様書無しさん:2015/03/28(土) 13:59:45.86
>>277
おれが社会保険料も書いてるのちゃんと読めてる?
お前みたいに日本語すら読めずにものを言うバカが多いのが問題なんだよw

287 :仕様書無しさん:2015/03/28(土) 13:59:54.74
アメリカの富豪は篤志家が多い
日本の富豪はしみったれ

288 :仕様書無しさん:2015/03/28(土) 14:01:03.25
>>283
ちゃんと日本語が読める人がいてよかったw
まだ日本も捨てたもんじゃないな

289 :仕様書無しさん:2015/03/28(土) 14:26:09.11
http://www.nenkin.go.jp/n/www/service/detail.jsp?id=1982
厚生年金保険料の額は、標準報酬月額×保険料率で計算され、
事業主と被保険者で半分ずつ負担します。標準報酬月額等級や
保険料率は、保険料計算の基礎であり、一定期間ごとに見直される
ことになっています。

↑年金も収入で変わるわけで、↓みたいなわけの分からない
日本語を使うのがいるのが問題なんだよな。一律って住宅費も
払わなくていい国があるかよっていう。

>>283
健康保険や住宅費やその他が、一律でかかってくるからね。日本は。

290 :仕様書無しさん:2015/03/28(土) 14:30:31.92
まあ、可哀想だからフォローしておくと利率が変わるレンジは
比較的広いから月額が数千〜1万位アップしても取られる料が
変わらないように見えるから頭の弱いのだと勘違いしたまま
なんだろうけどね。

291 :仕様書無しさん:2015/03/28(土) 15:05:16.23
その計算式で支払いが決まる層は中流以下だよ
標準報酬の上限を超える収入がある人はいくら払うことになるのか調べてごらん?w

292 :仕様書無しさん:2015/03/28(土) 15:05:55.01
ちなみにヒントは「一律」だよw

293 :仕様書無しさん:2015/03/28(土) 15:11:21.68
社会保険制度や失業保険制度は格差の原因なので
他の先進国を見習って全廃すればいいと思うの

294 :仕様書無しさん:2015/03/28(土) 15:13:09.00
あと年金も廃止ね
日本も先進国らしく国民の自己責任意識を高めないと

295 :仕様書無しさん:2015/03/28(土) 15:13:09.23
その代わりに生活保護費には他の先進国に倣って10倍くらい予算つけたらいいと思う

296 :仕様書無しさん:2015/03/28(土) 15:15:18.84
生活保護はアメリカのように現金支給を廃止してプリペイドカード式にすればいい
あと週に何日かの社会貢献活動の義務付けもね

297 :仕様書無しさん:2015/03/28(土) 15:16:23.32
額が上がれば現金でもプリペイドでもいいよ

298 :仕様書無しさん:2015/03/28(土) 15:16:49.69
>>295
イギリスはそれで破綻しかけてるかけどねw

299 :仕様書無しさん:2015/03/28(土) 15:19:27.95
破綻しても何も変わらんのじゃないかい?
ギリシャが破綻したところで国民が大量死したなんて話も聞かないし

300 :仕様書無しさん:2015/03/28(土) 15:21:06.04
社会福祉充実の為消費税を最大20%に引き上げ
勿論生活必需品は税率は低めで

301 :仕様書無しさん:2015/03/28(土) 15:22:12.52
物品税復活 消費税廃止でいいよ

302 :仕様書無しさん:2015/03/28(土) 15:23:01.98
食料品、生活必需品は税率3%
外食、加工品、自動車、娯楽、ネット関連は消費税20%

303 :仕様書無しさん:2015/03/28(土) 15:24:54.96
働けないモノは種の保存のため廃棄処分と言うことでw

304 :仕様書無しさん:2015/03/28(土) 15:26:45.31
小保方春子は働けないモノになりますか?

305 :仕様書無しさん:2015/03/28(土) 15:28:30.79
高所得者=働き者が報われて何が悪い

306 :仕様書無しさん:2015/03/28(土) 15:30:27.33
日本では他の先進国よりも報われてるし日本に生まれてよかったー

307 :仕様書無しさん:2015/03/28(土) 15:30:27.52
無能な低所得者が集まるスレはここですか?

308 :仕様書無しさん:2015/03/28(土) 15:30:54.77
>>299
分かりやすい何かがすぐに出るならギリシャ国民だって
もう少し必死になるだろうが、幸か不幸かすぐに出るわけ
でもないからな。 隣の韓国は1997年に通貨危機でIMFに
お世話になっているが、見かけ上は普通に見えるが、
日本以上に経済格差が酷いわ、女性を売春婦として
大量に輸出してるわで内実はかなり厳しいからなあ。

ギリシャにしたって、破綻したと言っても周りが潰れない
ように必死に留めようとしているから見かけ上はたいした
事のないように見えるだけで、周りが諦めたらどうなるか
なんて誰にも分からないし。

309 :仕様書無しさん:2015/03/28(土) 15:31:05.23
いいえ 技術力が低い会社にありがちなことを挙げるスレです

310 :仕様書無しさん:2015/03/28(土) 15:31:45.58
結局隣の芝生が青く見えるだけなんだよなぁ

311 :仕様書無しさん:2015/03/28(土) 15:33:08.22
そう 金持ちはよりお金持ちになりたい 貧しいものは豊かになりたい

312 :仕様書無しさん:2015/03/28(土) 15:36:39.05
技術力が<低い会社に不満があるなら起業して技術力の高い会社を作ればいいんじゃないの?
株式会社を設立するのに昔ほど金は掛からないし、このスレの住人は技術力が高そうだから余裕じゃん

313 :仕様書無しさん:2015/03/28(土) 15:38:26.05
>>312
独立して起業するも従業員にブラック企業だの技術力の低い会社だのと匿名掲示板で晒されるっとw

314 :仕様書無しさん:2015/03/28(土) 15:40:19.52
ありがちなことを挙げるだけで不満があるとは限らないわけでw

315 :仕様書無しさん:2015/03/28(土) 15:41:48.65
>>312
そして新たなブラック企業の誕生である

316 :仕様書無しさん:2015/03/28(土) 18:17:19.07
■少年法61条改正 署名 change.org キャンペーン
http://blog.goo.ne.jp/shounen_news/e/c3b1eeb42bfcdd59461f733c61cbe79f
おねがいします。

317 :仕様書無しさん:2015/03/28(土) 18:55:14.35
>>312
不満は技術力が低いって事だけじゃないから

318 :仕様書無しさん:2015/03/28(土) 23:26:23.37
それも真理だな
給料が低かったり倫理観が低かったり

319 :仕様書無しさん:2015/03/29(日) 01:09:01.52
技術力の低い人はスキルよりも安い奴隷を求めるけど
技術力の高い人は同程度以上のスキルの人間を求めて、かつ相応の対価を払う。

そういうスキルの人間はそうそう集められないから規模は大きくできないけど
修練切磋琢磨に意欲のある人間ばかりだから居心地は間違いなく良いだろう。
切磋琢磨に考えが至らない意識の低い人間は、仕事を丸投げする。

320 :仕様書無しさん:2015/03/29(日) 08:50:31.23
>切磋琢磨に考えが至らない意識の低い人間は、仕事を丸投げする。
まるでうちの上司みたいw

321 :仕様書無しさん:2015/03/29(日) 11:57:30.84
人生の中でプログラミングなどの興味に強くひかれる期間なんて
ほんの数年だけだよ

程度の差はあれ、いずれ熱は冷める

322 :仕様書無しさん:2015/03/29(日) 13:04:29.06
>>320
多分それが十数年後の君の姿だよ

323 :仕様書無しさん:2015/03/29(日) 13:05:17.84
>>320
心配するな、いずれ貴方もそうなる。

324 :仕様書無しさん:2015/03/29(日) 14:57:08.83
>>321
仕事への情熱が覚めない人は
勝ち組なんだと思う。
ビルゲイツとかリーナスとかね。

325 :仕様書無しさん:2015/03/29(日) 15:01:12.37
職業安定法44条違反
労働基準法6条違反
で提訴された会社

アイピーロジック
SEプランナー
http://www.se-planner.com/

ビジネスインフォメーションテクノロジー
BIT
http://www.b-it.co.jp/

326 :仕様書無しさん:2015/03/29(日) 15:42:46.21
プログラマーのみでやっていけるのも精々40前後まで・・
それまでにPMかリーダーくらいになっていないと厳しいと思う
まぁどちらにせよそれくらいの年齢になると若手のプログラマーに使えないと馬鹿にされるんだろうけどw

327 :仕様書無しさん:2015/03/29(日) 15:44:31.12
結局、現在の自分の上司の姿が将来の自分の姿なんだよなぁ

328 :仕様書無しさん:2015/03/29(日) 16:30:25.88
>>326
例えば1995〜2005年までの10年と、2005〜2015年までの10年で
どれだけの変化があったかを考えていたりします?

前者の10年やそれ以前と後者の10年だと結構違っていたりします。
ここ10年位は看板の掛け替えが主でハードェアの進歩、主にCPUや
ストレージの性能は前の10年に比べたらほぼ足踏みに近い状況
だったと思います。モバイル端末やIoTのハードは進歩しましたが、
ソフトウェア的にはやり直しの感が大きいですし。

インターネットに関しても普及しすぎたためにレガシーが大きすぎて
HTML5の普及は牛歩の歩みですし、javascriptなんて似たような
フレームワークが出ては消えてを繰り返しています。

プログラミングに関しては追いつけない速度での進歩はなかった10年
だと思えます。 もちろんリーダーやマネージャが主で自分で書かない
人は追いつけない状況だとは思いますが。

日本では少子化やITがブラックと必要以上に喧伝されているために
若い人が入りづらい状況でもあり、マとしてガリガリ書ける人が必要な
状況と認識出来ている人は少ないと思います。 手本となれるチャンスが
来ているとも言えますな。

329 :仕様書無しさん:2015/03/29(日) 17:02:19.74
土台が一緒だから錯覚するけど
上にのってるアプリはだいぶ変わったよね

330 :仕様書無しさん:2015/03/29(日) 17:10:31.61
車なんて何十年も前から
全然変わってないし。

331 :仕様書無しさん:2015/03/29(日) 20:16:37.13
>>328
仮想化(汎用機のVMなんか30年前からあった)が
クラウドまで進化したのを見落としてるようでは、
ただのプログラマ止まりだな。

332 :仕様書無しさん:2015/03/29(日) 20:23:20.78
クラウド化されたのは仮想化だけじゃないだろ

333 :仕様書無しさん:2015/03/29(日) 20:25:50.88
>>331
クラウド化でマがやること何か変わったか?
今までインフラ屋に投げていたことが、ブログラマブルに出来るように
なってやることが増えたことは否めないが。
より抽象度の高いレイヤーでの作業が出来るようになって部分もあるが、
AWSとかクラウド固有の問題も出てきてというのもあるし。

334 :仕様書無しさん:2015/03/29(日) 20:29:35.27
plan9とかでもストレージの抽象度を上げてローカルとネットの先で
同じように振る舞うようなものが現れたけど、結局のところローカル
より早くなることはなくあまり意味のないものだったり。

今でもパフォーマンスが必要なDBなんかはベアメタルやオンプレミスで
用意してってのも珍しくないし。

クラウドはツールであって銀の弾丸では無いよね。

335 :仕様書無しさん:2015/03/29(日) 20:30:06.14
だからプログラマどまりだと指摘した通りじゃねーかw

336 :仕様書無しさん:2015/03/29(日) 20:41:15.89
関連性の乏しい話を突発的に出してくるあたりが素人らしいな
プログラミングの素質がなく上流に逃げるしかなかった無能さんだな

337 :仕様書無しさん:2015/03/29(日) 20:45:55.90
そんな無能な上流より薄給なプログラマーってww

338 :仕様書無しさん:2015/03/29(日) 20:53:35.42
>>337
今の50代や40代後半は逃げ切れるかも知れないが、
それより若いとどうなるかは分からんからねえ。
特に上のポジションは枠自体少ないし、中途だと
要求されるハードルは天井知らずなわけだし。

339 :仕様書無しさん:2015/03/29(日) 20:55:55.67
>>337
大丈夫、スキルの厚さがあるから

340 :仕様書無しさん:2015/03/29(日) 21:10:53.07
プログラミングスキルのみで通用するのは精々30代までだよ

341 :仕様書無しさん:2015/03/29(日) 21:11:51.40
>>340
いやリーダー経験位無いと30代でも厳しい

342 :仕様書無しさん:2015/03/29(日) 21:19:23.85
>>340
プログラミングは基礎中の基礎、各工程共通の必須スキルに過ぎない
このスキルを高いレベルで持った人間のみが上流をまともに行える

このスキルを持たない人間はただの営業マン

343 :仕様書無しさん:2015/03/29(日) 21:21:39.78
>>342
プログラミングスキルだけではただの作業員だよ

344 :仕様書無しさん:2015/03/29(日) 21:27:16.95
開発業界にいながらプログラミング能力に問題のある人間は
プログラミングしかできない人間と比べても劣る
声に出してみれば、極めて当たり前の話

345 :仕様書無しさん:2015/03/29(日) 21:32:28.32
開発で確かにプログラミング能力は最低限必要なスキルだが、それはあくまで最低必要なスキルであって
プログラミングスキル「しか」ない人間はそれはただのカタワだよ。

346 :仕様書無しさん:2015/03/29(日) 21:34:05.06
>>344
でも何故かその劣ると言われる人間より薄給ww

347 :仕様書無しさん:2015/03/29(日) 21:34:38.93
プログラミングのスキルすら低い人には、当然スキルの高い人の力なんてわからないよね
上流工程のすべてが君よりもはるかに高い次元でこなせるよ
というより全行程を独りでも高品質に行える
そのくらいのレベルの人になると独立してるかもしれないけど

348 :仕様書無しさん:2015/03/29(日) 21:36:52.23
と薄給な奴隷が申しておりますww

349 :仕様書無しさん:2015/03/29(日) 21:37:37.81
>>345
「しかできない人」ってのは、実は存在しないんだよ。
もしいるのだとしたら誰かに勝手に行動制限を掛けられてるだけだろう。
「できない人」は間違いなくいる。今この場にも。

350 :仕様書無しさん:2015/03/29(日) 21:39:49.69
>>348
君よりは高いと思うからいいよ

351 :仕様書無しさん:2015/03/29(日) 21:41:22.94
仕事が出来る、出来ないの評価は自分自身じゃなく他人が評価するものだけどな
だから評価されない人間は本人がどう思おうが客観的に見で仕事が出来ない人間だと言うこと

352 :仕様書無しさん:2015/03/29(日) 21:42:10.32
>>350
良かったね

353 :仕様書無しさん:2015/03/29(日) 21:43:00.65
プログラミングスキルの低い上司はプログラマーからの評価は最低だろうな

354 :仕様書無しさん:2015/03/29(日) 21:45:22.96
>>352
草生やして口座の見せっこに話を進めないのかよ

355 :仕様書無しさん:2015/03/29(日) 21:47:16.63
>>345
最低必要なスキルすらないのがうじゃうじゃいるのがこの業界じゃん

356 :仕様書無しさん:2015/03/29(日) 22:00:26.27
>>353
360°評価みたいなのを導入している会社はあるけど、
実態はねえ。どこのプロジェクトに行っても下から技術力が
無いって評価されてもどこかに配置出来たり落とせたりと
なった場合はまた別だからねえ。

357 :仕様書無しさん:2015/03/29(日) 22:31:42.84
>>356
技術力がないからって、落ちてこられても邪魔だよw
金勘定と工程資料だけ作ってりゃいいんだよ。

358 :仕様書無しさん:2015/03/29(日) 23:49:05.60
  : : : : : : : /: : : :/: : : / : : : : : : : : : : \
  : /: : : : /: : : :/: : : / : : /: : : : :!: ヽ : : ヽ
  /: : : : /! : : :├‐<__/| : : //|: : | : |: : '.
  : : : : /.:l: : : : !,,,___\ \/N |: : | : |: : :|   _ -, -──‐-、     | _|_   |_L   /
 .: : : :/ヽ|: : : :.|丁「ノi:::}Tミ'     >:L_」: : :| ./ /: : : : : : : : : \   | _|    ̄|  _ノ  (  
 .: : :/'⌒l: : : : | 弋...._/    `チァ:r、/ヽ /  ' ___: : : : : : : : : ヽ  レ(__ノ\  |     \ 
 .: :/{. (|: : : : |           ヒ'_/イ:|/   /:::::::::::::, '´ ゙̄ヽ: : : : : '
 .:/:人 ー|: : : : |         ,  .  '´     |::::::::::::::{:::::::::::::::}: : : : : :| ,―┴┐ −/─   ─┼─ |   ヽ 
 : /: :/:ー|: : : : |      __r‐'了        |:::::::::::::: 、::::::::::ノ: : : : : :| ヽ| 三l_  / __| ヽ   ゝ  |    |
 /: :/ : : |: : : : |    /´ |::::::|        ∨:::::::: '´ ̄: : : : : : : :/ ノ| '又 '  (___ノ\ ヽ_   ヽ/
 : :/ : : /|: : : : |丶、  `ー ヘ_::::\__    \'´ : : : : : : : : : : /
 :/: _xく. |: : : : |   `7:=r 1´: :! ̄::>ヘ、 ̄¨''¬ー- 、 _____, '´
  ̄    |: : : : |  /\:!: | : : !.::./ .二\

359 :仕様書無しさん:2015/03/30(月) 06:31:36.06
上司や指導・教育する人が無能な会社は例外なく、その配下も無能だからな
いちいち現場にいる全員を見なくても、そこの会社の役職付の人や指示出している人を見れば想像つくでしょ
大体、想定内のガッカリ感・失望具合

若い世代見て、この子は2、3年目なのに何も知らないんだなぁ可哀想に…とか思っていたが
上司や指導している人を見れば納得できる無能っぷりが御披露されている

そういう会社でも年配の人で技術力ある人はいるけど、大抵そういう人は教育・指導係ではないから
若い世代に継承される事はないだろうね
最終的には、現場にいる社員全員がまともな作業もできない上に判断能力もない無能だらけになるんだろうな

360 :仕様書無しさん:2015/03/30(月) 09:13:20.03
なんでここの住人は職場で周りは無能だけど自分は有能、という前提なんだろうね
そもそも無能が集まる職場にしか採用されず、しかも社会のゴミが集う2chで管巻いている時点で自分もその無能な人間の1人だということにいい加減気付けよ

361 :仕様書無しさん:2015/03/30(月) 10:38:44.86
人間誰しも自分自身は見えないものさ。

362 :仕様書無しさん:2015/03/30(月) 14:15:56.95
スレタイがそういう内容を指しているし、協力会社目線の意見が多いのは当たり前だと思うけどね
複数の現場を渡り歩いているからA社、B社、C社と比較することができる訳であって
周りが見えていないのはずっと同じ現場にいる社員くらいでしょ

現に文句を記載している人は協力会社目線の書き方だし
ここで、現場や会社に対するクレームのような事を記載している人を協力会社の人だと仮定するならば

会社や現場に対してではなく、その意見を言っている人に対して何故か文句言っている人はどこかの元請け社員ではないか?
という見方の構成図も出来あがる訳だし

何だかんだ言って結構当たっているんじゃないの?
こんなところで嘘ネタ書く意味もないし、大半はどこかの誰かの事実体験談でしょ

そう考えるとダメな会社のクレーム事情を書き込んでいる人がいるとして
そのクレーム事情が自分たちにも当てはまるクレーム事情だとしたら
まるで自分たちの事を言われているように感じて意味の分からない反論を始める元請け社員とかいそうだしね

363 :仕様書無しさん:2015/03/30(月) 14:57:51.89
技術力が低いのはけして社員の技術力が低いわけじゃない
適正のない仕事をやっている場合や、もともと単価が安い業界なのかもしれない

364 :仕様書無しさん:2015/03/30(月) 15:16:30.37
どーせ営業力>技術力なんだからいいんだよ

365 :仕様書無しさん:2015/03/30(月) 20:56:15.24
なんでどっちかの比率を上げるわけ?
技術力も営業力もどっちも高くないと意味ないだろ

366 :仕様書無しさん:2015/03/30(月) 21:54:27.12
どっちか突き抜けてないと商売にならん
ただの派遣会社におちぶれるだけ
規模があれば生き残るかもしれんけどさ

367 :仕様書無しさん:2015/03/30(月) 22:18:20.38
      ,、、、----‐‐‐‐‐--、,
     /           :ヽ
    /              :\
   ./            ,,,,;;::''''' ヽ
  /    ,,,,;;:::::::::::::::       __   ヽ
  |   .  __       '<'●,   |
  |.   '"-ゞ,●> .::            |
  |           ::: :⌒ 、      |
  ヽ.      ;ゝ( ,-、 ,:‐、)      |  へーすごいじゃん
   l..            |  |      |
   |        __,-'ニ|  |ヽ_     |
    ヽ:        ヾニ|  |ン"    /__
    .ヽ:        |  l, へ      ::::ヽ,
     l.:`.         / /  , \  /ヽ  ::\
     `、:::::       |    ̄ ̄\/ ノ    :::ヽ
      |::::::      |      ー‐/ /      ::::\

368 :仕様書無しさん:2015/03/31(火) 22:06:40.80
>>359
そもそも、技術力が低い会社に入った若い子は派遣先の社員から教育を受けるから。
派遣先のレベルに左右される。

369 :仕様書無しさん:2015/04/01(水) 20:27:35.69
くだらないね
車で言うならエンジンが悪いとかタイヤが悪いとか、いやいやオイルのせいだろ?みたいな会話してるようなもんだな

整備師が見れば原因はどうのこうの言い出すが、
言い方をどんなに変えても、まともに走らない時点でポンコツはポンコツに変わりない
最終的には道路が悪いとか言い出すパターンだろこれ

刃物で例えるならナマクラだろ。
知り合いに包丁を借りたとして、切れ味が悪くて、「え?何この包丁!?切れ味悪すぎじゃない?」って言ったら
「元から切れ味悪かったんだけど、研がないまま3年間使っているからね!」
こんなフォローされても全然嬉しくも何の役にも立たないのと同じ。逆に腹立たしくなるだろ

ポンコツやナマクラを使っている奴は頭クルクルパーだし
フォローする人もポンコツやナマクラと同類

370 :仕様書無しさん:2015/04/01(水) 21:01:40.23
3行でたのむ

371 :仕様書無しさん:2015/04/08(水) 23:16:03.00
俺はポンコツ
お前はナマクラ
無能同士、仲良くやろう

372 :仕様書無しさん:2015/04/11(土) 19:59:00.33
負けないために、勝てない勝負は最初からしない

373 :仕様書無しさん:2015/04/11(土) 21:24:53.13
他グループのソフトのバグ指摘したら
自グループのソフトにも同じバグがあった

374 :仕様書無しさん:2015/04/12(日) 16:19:37.40
コードが動いた所(バグもない)で
完成とするやつが多いこと多いこと

コード書くのが嫌いなのかな?
もうこれ以上タイプしたくない。
動いてるんだからいいでしょ!みたいな。

無駄が無いと言える所までコードを
そぎ落としてやっと完成なんだが。

375 :仕様書無しさん:2015/04/12(日) 16:36:04.69
>>374
直すときのコードを書くこと以外のことが嫌だな。

それ以前に終わったら別の仕事入れられて時間なんかあるわけでもなく、
時間を切ってやらんと仕事回らん。

376 :仕様書無しさん:2015/04/12(日) 16:50:49.67
>>375
そういやつって、仕様書も同じように
分かりにくいんでしょうね。

論理構造がめちゃくちゃで章立ててなかったり
関連する情報がことがあちこちに散らばっていたり
ちゃんと書いてあるんだからいいでしょ!みたいな。

そうか下手な仕様書が出来る原因も同じなんだ。
分かりやすくしようという考え方がないから
書いたら終わりにしてしまうわけか。

377 :仕様書無しさん:2015/04/12(日) 17:07:42.86
プログラマなんかは日常的に、
自分が書いてものを読み返しているから
初心者でもない限り、読むときのことを考えて
書くことの重要性を理解している人が多い。
それが結局は時間の短縮につながるし。

一番だめなのは仕様書を書く人と
読む人がわかれているパターンだな。
こういうのは大量に書くだけ書いて、あとはお前が読め。
自分の仕事はやった。俺はもう知らん。ってパターン

それが全体の開発効率を大きく落として
時間を大量に消費する原因なんだが、
視野が狭いから、先のことまで考えられんのよね。

378 :仕様書無しさん:2015/04/12(日) 17:20:45.92
結局技術力って個人の資質以外のなにもんでもないと思う
組織としてどうにかする、つまり教育ってのはほとんど意味ないと思うわ

379 :仕様書無しさん:2015/04/12(日) 17:32:09.32
>>378
それは間違いではないが現実的じゃないんだよ。

個人の資質がなくてダメな人。
それは絶対いるわけで、その人をすぐにやめさせても
問題ない会社ならこの手法は使える。

問題ない会社っていうのは、どんどん優秀な人が
入社するような、知名度が高く人気もある大企業の話。

だけど、世の中は中小企業が99%を締めてるわけで
そういう会社で、大企業と同じことをやるとすぐに人不足になる。

理屈では正しいが現実的には適用できないことがあるんだよ。
君の会社が大企業なのかどうかは知らないけどね。

380 :仕様書無しさん:2015/04/12(日) 18:22:23.04
>>379
属人性をなくせみたいなのが金科玉条の如く語られる昨今ですが、
中小ほど資質のある出来る人を優遇してやっていくしかないんじゃ
無いのとか思える。

381 :仕様書無しさん:2015/04/12(日) 21:22:06.09
つきかった
人月、スケジュール力が低すぎる。

結果→デスマ(土日出勤)になる。

382 :仕様書無しさん:2015/04/12(日) 22:11:59.67
C++言語の使用ができる環境なのに、C言語の使用をお願いしてくること。

…俺は基本的に、開発言語には拘らないのだが、
Cの上位互換であるC++を使えるのに使わず、わざわざCの使用をお願いされて困ってる。
仕方なく従ってC言語で組み込みソフトを開発してるのだが、
組み込み業界ってC++は遠慮されるものなのか?それとも、スレタイの通り?

383 :仕様書無しさん:2015/04/12(日) 22:42:26.23
ROM節約するためじゃない?

384 :仕様書無しさん:2015/04/13(月) 00:19:21.35
組み込みで使われるC言語は制御のためのスクリプトみたいなもんだから、
プログラム言語とは違うという認識でいたほうが良いと思ふ。

385 :仕様書無しさん:2015/04/13(月) 00:59:10.53
>>380
まずは自分が社長になってやってみ?
できたらそう言う資格があるよ

386 :仕様書無しさん:2015/04/13(月) 01:27:32.24
>>385
はい。なりました。
だから言う資格あります。

お前にはないようだがw

387 :仕様書無しさん:2015/04/13(月) 05:23:53.01
社長が2chで文句垂れてるって会社終わってるよね

388 :仕様書無しさん:2015/04/13(月) 05:33:20.65
菅官房長官「名前は出さないが、アップルと匹敵するような企業が準備を進めている」
http://daily.2ch.net/test/read.cgi/newsplus/1428829706/
米アップルが横浜市港北区に大規模な技術開発拠点を建設する計画を進めていることに触れ、
「これを契機に『やはりアジアの拠点は日本にしよう』という優良企業がこれから増えてくる。
名前は出さないが、アップルと匹敵するような企業が準備を進めている」と語った。

389 :仕様書無しさん:2015/04/13(月) 06:05:12.15
プログラマーとして生きていくのなら、>>378 が正しい。

>>379 みたいな認識の人って、要は、自分の現実を変えていくほどには
プログラマーとしての腕に自信のない、いわゆるSEと呼ばれる人でしょ。
そういう人ほど、
>現実的には
とか
>世の中は
とか、言い出すけど、まあ、無視でいい。

390 :仕様書無しさん:2015/04/13(月) 06:33:51.47
>>386
わりーな、残念ながら俺も中小企業のタコ社長だよ
社長なら社長って最初から書いとけ

391 :仕様書無しさん:2015/04/13(月) 09:04:07.31
俺はニートだって全力で叫んでいるおかしな人たち

392 :仕様書無しさん:2015/04/13(月) 10:08:25.36
>>382
それって開発環境としてはC++が存在するだけじゃいの?
ちゃんと組み込み機器にC++のライブラリを入れるだけの容量があるの?
実行環境の事までちゃんと考えてる?

393 :仕様書無しさん:2015/04/14(火) 02:19:41.14
この業界はプログラマとして教育しても芽が出るとすぐにSEにされちゃうから教育のしがいがない
そしてゴミのようなソースを書く人間だけが年をとってもプログラマでいられるから
プログラマはいつまでも若手とできない人間だけで構成されるという負のスパイラルに陥っている

394 :仕様書無しさん:2015/04/14(火) 07:05:51.87
>>392
組込みはよく知らないけど組込み機器に入れるのはバイナリじゃないの?
C++で書いても結局は機械語に変わるだけだと思うけど、C++化しただけで悲観するほどバイナリが肥大化するの?

>>393
久々に見たな、現実と真逆の内容
たとえ書けても読めたもんじゃないソースしか書けない人間はプログラマなんて続けられないよ
適性が無いから、IT業界に居続けるためには上流に逃げるしかない
逃げた奴が上流に行っても大した仕事ができなくて仕様ミスの多いゴミ人間にしかならないけど

395 :仕様書無しさん:2015/04/14(火) 07:10:33.53
>>394
知らないなら黙ってて

396 :仕様書無しさん:2015/04/14(火) 07:11:52.20
>>395
クエスチョンマークが見えない?
煽ってるんじゃなくて質問なんだけど

397 :仕様書無しさん:2015/04/14(火) 07:41:09.65
>>394
組み込みでC++が流行らないのは、メモリの動的確保がいるから。ってのもある。
メモリの動的確保が禁止な事は多いし。
また、細かいオブジェクトをnewしまくって、メモリのフラグメントに頭を悩ませたりする事もしばしば。

398 :仕様書無しさん:2015/04/14(火) 07:53:59.89
>>394
そういう人間って職場のルール通りには動けるけど
仕様決めとか設計とかルール通りにはいかない仕事はミスが多いね。
適性もさることながら圧倒的に経験も不足してる。

何やらせても穴が多かったり
酷くなると職務放棄してテメーの仕事を下流に投げたり。
だから成長しないし僅かな経験も偏ってる。

399 :仕様書無しさん:2015/04/14(火) 08:08:19.54
C++を最適化コンパイラ様が最適化した機械語は
人間が追うには難しすぎる。
structの延長くらいでclassつかってる程度ならいいけど
iteratorあたりでもうすごいことになりはじめる。

400 :仕様書無しさん:2015/04/14(火) 08:26:14.53
>>394
クラスはでかいバイナリが生成されるから小さいROMを圧迫する
次からは人の技術疑う前に自分の技術を疑うんだな

401 :仕様書無しさん:2015/04/14(火) 08:58:48.32
>>394
C++がCと違う一番大きな部分は「クラス」なわけだが
C++で用意されているクラスを利用するためには使っているクラスのライブラリが必要で
クラスライブラリってのは普通に「大きい」んだよ
外部ライブラリにするならそれが必要だし内部にライブラリを埋め込むならバイナリが大きくなる
組み込みとか以前にちょっと調べれば分かる事なんだが

402 :仕様書無しさん:2015/04/14(火) 09:06:47.35
このようにstdすら小さく自作できないレベルの労害が
C++の導入を妨げているのです。
おそらくC++を理解できない馬鹿だからCに執着しているだけなんでしょうけど。
stdを自前でコンパクトに作れる技術があるところは
とっくにC++に移行しています。

403 :仕様書無しさん:2015/04/14(火) 12:36:54.71
>>402
組み込みマだけど、
cpp使う理由がないからcを使う

メモリが潤沢ならcppでもいいけど、
8ビットマイコンならcしかない

組み込みは基本的にブラックボックスを
嫌うからcppは馴染まないな

404 :仕様書無しさん:2015/04/14(火) 21:19:46.37
>>397
確かに動的にあれこれできることがC++のメリットだし
それが無いとインスタンスとかのルールが面倒になるな、納得

>>400
人の技術なんていつ疑ったよ?

>>401
C++の言語自体とクラスライブラリって関係なくね?
使わないでもC++で書けるだろ
使わないと俺には組めないという意味ならアホすぎるが

405 :仕様書無しさん:2015/04/14(火) 21:26:13.04
>>404
バイナリ語るってことはアセンブラ読み書き出来るんだろうな?

406 :仕様書無しさん:2015/04/14(火) 21:31:10.62
>>405
最近はめっきり触ってないがDOS時代とかPentiumとかは
グラフィック周りをガリガリ書いてた
マイコンは知らん

407 :仕様書無しさん:2015/04/14(火) 21:41:43.64
組込みの人間ってCで書いてアセンブラで確認してアセンブラで直す
そんなことやってる奴ばっかりなの?

俺の中のアセンブラってのは、Cソースの中に埋め込んで
部分的高速化って感じなんだが

408 :仕様書無しさん:2015/04/14(火) 21:43:27.91
>>402
いやならべつのとこ行けよ。
そんな能力ないから居座って愚痴言ってるんだろう?
世間一般では、君のことを老害といいます。

409 :仕様書無しさん:2015/04/14(火) 22:00:16.34
>>408
いちいち引っかかるなよ老害

410 :仕様書無しさん:2015/04/14(火) 22:01:05.16
>>407
そんな金持ちの道楽的な発想とは
根本から目的が違うよね。
一回電子工作してみたら?

411 :仕様書無しさん:2015/04/14(火) 22:12:25.08
>>410
mbedならちょっとやってたよ
RTCから日時取って7segに表示する程度ならできる

412 :仕様書無しさん:2015/04/14(火) 22:13:12.22
ちなみにmbedはC++

413 :仕様書無しさん:2015/04/14(火) 22:14:08.52
>>407
最近はアセンブラで書くことは無いよ
ただし、意識はしてないと危険

windowsで組み込み機器のモニターツールや
ファーム書き換えツールを作る時はvb.net使ってる

あれはあれでいいものだ

414 :仕様書無しさん:2015/04/14(火) 22:18:47.65
組み込みはromもramも制限厳しいから
C++のような無駄な言語は使わないよ

そうしないと管理できないほど巨大な製品なら別だけど

led1個より小さい電流で高速計算と通信ができる
マイコンのスバラシさよ

415 :仕様書無しさん:2015/04/14(火) 22:30:44.97
クローズドな環境で非力なマイコンと日々せせこましく戦ってるわけか

416 :仕様書無しさん:2015/04/15(水) 03:15:35.79
組み込みは徐々に技術者減ってコボル化しつつあるな
規模は小さいが受け口あれば重宝される
今やスマホやJAVAが脚光浴びてC++も仕事が減ってく一方だしな

417 :仕様書無しさん:2015/04/15(水) 07:49:02.08
>>415
動かしてる感あって楽しいよ

418 :仕様書無しさん:2015/04/15(水) 07:51:34.53
組み込みは指が飛んだりするから嫌だ

419 :仕様書無しさん:2015/04/15(水) 14:55:43.54
>>407
基本的にはアセンブラは確認しないけど、どうしてもROMは16KBに納めて!とか言うときは確認しながら削る。
8bitの案件だとROMサイズとの戦いになる事は多い。

420 :382:2015/04/18(土) 22:10:03.68
一週間死ぬほど忙しくてレスできんかった。すまぬ。
うーん…ここのレスと上司の反応見ると、組み込み業界ってC++は不人気なのか…。
一度デバイスドライバを自作すれば、
class FlashROM flashROM( io(ピン番号) );
flashROM->erase();
flashROM->write( 書き込み先アドレス , 書き込みたいデータ );

みたいに直感的にわかりやすいコードが書けるし、
継承を使いこなせばマイコンの変更による移植もすごく楽。
将来的にもいいかなーって思ったんだが…ぐぬぬ。

ROM/RAM自体はマイコン内臓のだけで1Mbyte/128kbyteと、かなり余裕あるし(しかも、外付けメモリ搭載予定)、
SDカード読み書き・USB・RS-232C・マイコン→FPGA経由で映像出力
等色んな事をマイコンにやらせようとしているからC++で書いた方がいいと思ったんだ...。
(具体的に何がしたいのかは特定怖いので秘密)

くどくて申し訳ないけど、組み込みでC++よく使う会社ってあんまりない?

421 :仕様書無しさん:2015/04/19(日) 01:32:31.98
>>420
今はC#が主流だよ

422 :仕様書無しさん:2015/04/19(日) 02:27:26.35
>>420
なんかずれてる気がする。いまやろうとしてる事がC++である必要性を感じないなぁ…
もっと上位層ならC++もありだろうけど。

423 :仕様書無しさん:2015/04/19(日) 03:44:44.00
>>420
わかんなくもないけど、C++はオブジェクト指向が
出来る言語じゃなくてオブジェクト指向がし易い言語だぞ。

C言語はオブジェクト指向ができない言語じゃなくて
オブジェクト指向をするのに工夫が必要な言語だぞ。

別にコードの使い回しならC言語でもできるし、
flashROM_erase();
flashROM_write( 書き込み先アドレス , 書き込みたいデータ );
わかりやすさなら何も変わらない。

使いまわしするならば、メモリが小さくて外付けメモリも
ない環境を基準にするべきじゃないのか?

組み込みならテンプレート禁止、
例外も禁止かもしれないレベルなのだから
使うメリットが少ないだろ。

424 :仕様書無しさん:2015/04/19(日) 06:55:15.94
その時代の限界というわけでもない低性能のハードを選定して
そのハードの性能をギリギリまで使うこと自体設計ミスの部類に入りそうな

425 :仕様書無しさん:2015/04/19(日) 06:56:07.81
いうなれば、ただのマゾヒスト

426 :仕様書無しさん:2015/04/19(日) 15:35:22.54
>>420
別にメソッドにする意味が無いだろそれ

flashRW.hに

typedef{
u16 blockNumber;
u8 buffer[64];
}FlashData__t;

flashRW.cに

U8 initFlash(void);
U8 flashErase(U16 blockNumer);
U8 flashWrite(FlashData__t* writedata);
U8 flashRead(FlashData__t* readdata);

こんな感じかなぁ

427 :仕様書無しさん:2015/04/19(日) 15:37:35.07
>>424
お前さんはマイコン何円で基板作ってるの?
こっちはマイコン50円($0.5)で高いとか言われてるのに

それでもアセンブラで書けとか言われなくなったのは
非常に有り難いことです

428 :仕様書無しさん:2015/04/19(日) 15:45:32.61
LispでCコードジェネレータ。

429 :仕様書無しさん:2015/04/19(日) 19:06:04.38
>>427
限界にチャレンジする無駄な人件費の「もと」が十分に取れるロット数なわけ?

430 :仕様書無しさん:2015/04/20(月) 05:22:19.91
>>429
毎回変えるよりは安いよ

431 :仕様書無しさん:2015/04/20(月) 06:03:22.23
毎回変えるって何を?

432 :仕様書無しさん:2015/04/20(月) 21:53:07.30
>>431
マイコンを

433 :仕様書無しさん:2015/04/21(火) 00:28:21.35
限界にチャレンジすれば同じマイコンを使い続けられるってこと?

434 :仕様書無しさん:2015/04/21(火) 00:37:29.53
>>433
複数製品で同じマイコン使って
仕入値を下げてる

435 :仕様書無しさん:2015/04/21(火) 06:07:56.85
仕入れ値の話なら低スペックのCPUじゃなくてもよくね?
開発に無駄な時間を要してたら浮かした金なんて人件費であっさり飛ぶだろ

436 :仕様書無しさん:2015/04/21(火) 09:49:14.32
ARM SOC単価2400円以下のものは使ったことがない。
50円マイコンなんて、何100均にデジタル時計でも卸してんの?w

437 :仕様書無しさん:2015/04/21(火) 12:16:24.59
>>436
富豪プログラマばかりだなぁ

438 :仕様書無しさん:2015/04/21(火) 12:18:33.82
>>436
時計ならマイコン使うまでもないし
50円でも相当高機能だよ
通信もモーター制御も電圧計測もできる
普通にCで開発するよ

馬鹿にしすぎ

439 :仕様書無しさん:2015/04/21(火) 13:27:34.74
組み込みは暗くてオタク臭いからどっか行って

440 :仕様書無しさん:2015/04/21(火) 13:51:15.57
>>438
おまえ100均のデジタル時計を馬鹿にしているだろ。
最近のは温度計湿度計は当たり前、睡眠状態を検知して眠りが浅いときに
起こしてくれる機能なんてのもついてたりするんだぞ。

441 :仕様書無しさん:2015/04/21(火) 16:38:33.36
> 睡眠状態を検知して眠りが浅いときに
> 起こしてくれる

はためいわくだな。
一晩に何回起こすんだ?

442 :仕様書無しさん:2015/04/21(火) 16:46:05.52


年寄りは放っておいても起きるけどな

443 :仕様書無しさん:2015/04/21(火) 20:26:28.06
安いマイコンに拘ってるのはダイソーに卸す製品を作ってるのか

444 :仕様書無しさん:2015/04/21(火) 21:01:42.54
>>441
ここまで頭が悪いと生きているの大変でしょ?w

445 :仕様書無しさん:2015/04/21(火) 21:14:19.20
>>444
恨む
http://blog-imgs-57.fc2.com/n/i/c/nichiero794/Nichiero140206_H92_020-s.jpg

446 :仕様書無しさん:2015/04/21(火) 21:34:19.22
キックオフがやたらと長くて無意味な資料を下手なプレゼンで聞かされる

447 :仕様書無しさん:2015/04/21(火) 21:51:32.44
>>446
それなら毎回、キックオフって何?って聞いてくる社員がいる会社だろw

448 :仕様書無しさん:2015/04/21(火) 22:47:10.15
>>444
それはぜんぜん違うな(笑)

449 :仕様書無しさん:2015/04/22(水) 01:41:15.61
>>440
マジかよごめんな

450 :仕様書無しさん:2015/04/22(水) 08:33:40.58
119番トラブル次々 東京消防庁、日立に賠償請求検討
http://daily.2ch.net/test/read.cgi/newsplus/1429659058/
い19番通報が4時間近くつながりにくくなるトラブルがあり、
東京消防庁は、通報を受ける装置の設定ミスが原因だったと発表した。

451 :仕様書無しさん:2015/04/23(木) 07:30:44.15
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
裁判無関心
無料追加
残業見積
労働違反
利益提供
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
貧困
非婚
離婚
鬱病
早死

452 :仕様書無しさん:2015/04/30(木) 03:22:05.93
電話連絡がおも

453 :仕様書無しさん:2015/04/30(木) 08:46:26.78
>>1
連休は基本、無いもの

454 :仕様書無しさん:2015/04/30(木) 08:55:03.84
うーむ、いま恐ろしいことに気が付いた。

トヨタのいろいろな部署に研究、開発職として
長いこと派遣で行ってたが、ライン工を除いて
トヨタの社員は>>1そのままだ。

結局、トヨタ本体の仕事は派遣や契約社員が
実務を全部やってくれるし、製造、生産は
子会社が全てやってくれる。

トヨタ系の研究者というのは、研究をせよと
指示するだけが仕事。
実際の研究は、派遣、契約社員、下請けが行う。

トヨタ本体の研究、開発関係の仕事はむちゃ楽だ。
パワポでお絵かきして能書きこいてればよい。
>>1に書いてあることと同じ。

455 :仕様書無しさん:2015/04/30(木) 09:57:35.65
共有フォルダに「IDパスワード.doc」

456 :仕様書無しさん:2015/04/30(木) 10:28:17.66
マイクロソフト、新ブラウザーの名称は「エッジ」 IEの後継
http://daily.2ch.net/test/read.cgi/newsplus/1430352678/

457 :仕様書無しさん:2015/04/30(木) 10:53:00.47
>>454
奴隷が基盤を支えているのは人類の有史以来続けていたことだろ?

458 :仕様書無しさん:2015/04/30(木) 19:46:15.48
まじかよ大手の研究開発も実質は下請けがやってんのか?
ちょっとそれは信じられないなぁ

459 :仕様書無しさん:2015/04/30(木) 22:35:25.76
>>458
年度末になると駆け込みで大量に研究開発の仕事が来るよw

460 :仕様書無しさん:2015/05/01(金) 05:09:56.60
>>459
同じ様な感じです。
トヨタは分科会が2月下旬頃ですから、
その前あたりが納期になってます。
12月から2月頃はまじ忙しいです。
トヨタ社員は呑み会とパーティに忙しい季節ですが(笑

461 :仕様書無しさん:2015/05/01(金) 06:09:42.38
>>458
下請けやってたけど、論文は書くけどコードは書かないというところは多いよ。
国際標準を決める会議に出るけど、その際のデモ実装は下請けとかも。
あと多いのは「日常生活に組み込むAR」みたいなテーマ(役人から降りてきてるっぽい)から、
展示会でデモンストレーションする内容を考えて実装するとか。

462 :仕様書無しさん:2015/05/01(金) 10:17:03.65
>>460
パナ社員だけど
外注の金無いから自分でアプリケーションノート
見ながら組んでるよ

とてつもなく泥臭い

463 :仕様書無しさん:2015/05/03(日) 16:54:50.25
バブル時代の技術力の低い会社のマは殆どDQNだったなw

464 :仕様書無しさん:2015/05/03(日) 18:49:42.99
>>458
研究開発ってのが、プロダクトを作る作業のことだったら、
大手企業の人は金勘定しかしてないところがほとんどじゃね?

465 :仕様書無しさん:2015/05/03(日) 23:34:26.64
>>464
役所廻りも重要な仕事。

466 :仕様書無しさん:2015/05/05(火) 04:36:24.95
ここの人はみんな、保守系底辺派遣PGなのかなぁw?
頑張って綺麗なコード書いて!

467 :仕様書無しさん:2015/05/05(火) 08:02:50.60
>>465
それは営業の仕事だべ。

468 :仕様書無しさん:2015/05/05(火) 08:43:33.69
>>467
そう?
うちは営業に任せる訳にいかない話の方が多いけど。

469 :仕様書無しさん:2015/05/05(火) 11:39:37.96
営業にまかせておくと
とんでもな話しになってたりするからな。

470 :仕様書無しさん:2015/05/05(火) 12:16:55.52
ただのあいさつ回りでとんでもない話になるのか。
会社全体が腐ってそうだな。

はっ、まさにスレタイ?

471 :仕様書無しさん:2015/05/05(火) 16:58:03.24
>>469
そらそうよw
お客さんにすり寄ってなんでも受けてくるからねw

472 :仕様書無しさん:2015/05/05(火) 18:24:51.08
顧客の要望ならまだしも自分で仕様盛るのが楽しくなって空回りしてる奴は困るわ

473 :仕様書無しさん:2015/05/05(火) 23:04:53.66
>>469
そういう理由も或るけど、非公式の情報交換のメリットが大きい。
官僚は現実を知りたがってるし、こっちも再来年度予算の重点配分予想くらいは必要。

474 :仕様書無しさん:2015/05/13(水) 02:28:35.88
マは営業を受けるだけで何もしなくていいから楽だと軽蔑している
営業はマをいつも社内勤務で楽だと軽蔑している

475 :仕様書無しさん:2015/05/14(木) 23:10:09.20
営業は話すことしか能がない

476 :仕様書無しさん:2015/05/26(火) 21:44:51.22
test

477 :仕様書無しさん:2015/05/26(火) 22:47:06.10
>>475
営業が話すことしか脳が無いなら、プログラマーが営業を兼ねたらいいのでは?

478 :仕様書無しさん:2015/05/26(火) 23:15:42.76
>>477
じゃあ逆に営業がプログラマを兼ねるのかい?
それこそできっこないだろうw

479 :仕様書無しさん:2015/05/26(火) 23:19:55.62
営業は営業で顔だけ売ってきたらいいんじゃないの?

480 :仕様書無しさん:2015/05/27(水) 00:00:44.75
>>477
そしたらお前でもできる営業の仕事がなくなっちゃうじゃないか。

481 :仕様書無しさん:2015/05/27(水) 00:34:39.46
>>480
だから営業しか出来ない人間は不要、
プログラマーが営業をやれば無能営業がやらかす無茶苦茶な案件や工数で仕事を請け負う事もなくなる

482 :仕様書無しさん:2015/05/27(水) 01:50:34.90
>>481
まともな営業と組めるレベルにないプログラマは自力でやるしかないだろうな

483 :仕様書無しさん:2015/05/27(水) 05:56:22.67
海外のプログラマーは営業も普通にこなせるもんな

484 :仕様書無しさん:2015/05/27(水) 06:24:48.03
海外のどこの会社よ?
物作りながら営業とか非合理なこと普通に考えてもやらん

もっとも、日本のITの営業は、営業の仕事の5割程度しかやってないけどな。
開発できない人間も自分のスキル不足を仕事放棄(丸投げ)という形で
全て下流に負担を背負わせてるから5割程度。
日本のプログラマーは働き過ぎなうえに偏見で待遇も悪いから壊れる人が海外より桁違いに多い。

485 :仕様書無しさん:2015/05/27(水) 09:12:19.07
>>483
主語がデカすぎ

486 :仕様書無しさん:2015/05/27(水) 12:30:43.71
仕事取ったら営業はしばらく必要ないだろ。アホか?プログラマって池沼多いよな

487 :仕様書無しさん:2015/05/27(水) 15:16:24.96
>>486
お前の会社は一度にひとつの案件しかやんないのか
それに営業と言ってもいろいろあるでしょ
請負やら派遣しかしない会社なら仕事を取ってくるぐらいしかやることないのかもしれないけど

488 :仕様書無しさん:2015/05/27(水) 21:04:09.19
営業の仕事は簡単なんだよ。
数週間から数ヶ月程度あればマスターできる。
簡単だからプログラマもそれぐらいできれと言われる。

でもプログラマの仕事は難しいんだよね。
数年あってもマスターできない。

489 :仕様書無しさん:2015/05/27(水) 21:06:01.78
確かにここ数年はマスターベーションしかしてません

490 :仕様書無しさん:2015/05/27(水) 21:10:38.70
なぜかマ板にビッタリ張り付いてプログラマーを貶してる営業マン

491 :仕様書無しさん:2015/05/27(水) 21:15:35.00
営業の仕事がなくて暇なんだよきっと

492 :仕様書無しさん:2015/05/27(水) 21:23:24.11
たいして働いてない営業マンの給料まで稼いでるプログラマ

493 :仕様書無しさん:2015/05/27(水) 22:14:05.02
>>481
やってみてダメだった時に営業のせいにできなくなるじゃないか。

494 :仕様書無しさん:2015/05/27(水) 22:15:52.05
>>486
こういう営業がいるから、ちょっとしたトラブルでも大事になるんだよな。

495 :仕様書無しさん:2015/05/29(金) 03:11:20.97
トヨタはあんな糞デザインカー、コストカットカー作ってよくもボッタクリ
できるよな。今までは国内の下請け苛めて高品質の製品を納入させていたが、
こけたら致命的だろ。

こけないと思ってるだろうけど、そのうち中国や韓国の部品を納入して
信用落とすぜ。

見てろ。今のうちだけだぜ。早く潰れろ。こんな糞会社。社会の公器
どころか社会の寄生虫、ゴミ

今は「中国の車は中国で作る」
と言ってるけど、そのうち、中国や韓国、東南アジアで作った部品を横流しする
んだろw

今は、偉そうにしてるみたいだが、優秀な技術をもった下請けが

496 :仕様書無しさん:2015/05/29(金) 03:12:12.75
下の部分はゴミ

497 :仕様書無しさん:2015/05/29(金) 07:49:18.17
>>495
売れてる=大勢が求めているものを提供してる、だけだが?
なんか、民主に投票しといて、政治家は云々とか抜かしてる奴みたいだねぇ。

498 :仕様書無しさん:2015/05/31(日) 12:36:53.89
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
裁判無関心
学習不足
労働違反
残業見積
無料追加
利益提供
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
貧困
非婚
離婚
鬱病
早死

499 :仕様書無しさん:2015/05/31(日) 19:15:41.87
SI受注SEは残業断れよ!

生涯収入低下スパイラル

実態派遣作業残業

情報処理学習不足

情報処理能力低下

生涯収入低下

500 :仕様書無しさん:2015/06/03(水) 06:23:48.56
武蔵小杉駅西口善仁和寺本俸

501 :仕様書無しさん:2015/06/22(月) 17:48:52.56
ニトリ公式通販サイトがダウン、復旧の目処たたず →「楽天で買って」と異例の呼びかけ

ニトリの公式通販サイト「ニトリネット」が、6月22日午後3時45分現在ダウンしています。
サイトのトップページでは、「現状復旧の目処がたっておりません」として、楽天店での
購入を呼びかけています。
ニトリネットは6月17日にリニューアルを実施。新サイトでは「配送計画を自動化した」と
していましたが、リリース直後に一部プログラムエラーが発生。
17日中に復旧作業が始まり、現在までメンテナンスが続いています。
ネットでは週末をまたいでも復旧していないことから、トレンドに「リニューアル失敗」が入るなど、
心配するユーザーが多く見受けられます。ニトリは、「楽天店」「Yahoo!店」では購入できるとしつつ、
「お客様には多大なるご迷惑をおかけしておりますこと、深くお詫び申し上げます」と謝罪しています。
http://headlines.yahoo.co.jp/hl?a=20150622-00000055-it_nlab-sci

502 :仕様書無しさん:2015/06/22(月) 18:12:10.07
システムダウン異常、ニトリ♪

503 :仕様書無しさん:2015/06/22(月) 20:11:14.58
システムの運用に慣れてないところは大きいものを不可逆でリリースしたがるんだよな
切り戻し含めてのリリースだろうに

504 :仕様書無しさん:2015/06/22(月) 20:32:18.91
>>502
システム異常ニトリでいいだろ
センスねえんだよハゲ

505 :仕様書無しさん:2015/06/22(月) 21:50:22.70
楽天に
販売移譲、ニトリ

506 :仕様書無しさん:2015/06/22(月) 22:50:36.79
ニトリのシステムって内製なの?

507 :仕様書無しさん:2015/06/22(月) 23:30:26.55
>>503
決済機能とか社外サービスを使ってると
単純に自鯖を戻しただけではどうにもならないことも

508 :仕様書無しさん:2015/06/25(木) 20:43:01.79
まさか認識して残業してるの?
・SI受注SEは実態派遣
・職務は顧客費用削減
・雇用放棄で使い捨て

509 :仕様書無しさん:2015/06/25(木) 21:10:42.10
>>506
いま流行りの内製のマイクロサービスらしいが

510 :仕様書無しさん:2015/06/27(土) 08:20:56.93
制度改正で偽装請負問題は悪化するだろうな。

・裁判しない奴多すぎ
・裁判無関心多すぎ
・原告応援少なすぎ
・原告負担高すぎ

これだったら人売り屋を目指すべき。

511 :在日特権:2015/06/27(土) 08:29:31.07
新聞購読を止めて、月3000〜4000円、年間36000〜48000円の節約

新聞にそのような金を払う価値はない

ただでさえ要らない
なぜなら新聞は国民の方を向いておらず、広告主のための報道しかしないからだ

それに金を払って購読することは自らの首を絞める自殺行為に等しい

512 :仕様書無しさん:2015/06/27(土) 14:18:26.20
★傘が目に刺さり男性重体、口論した同僚を逮捕
http://www.yomiuri.co.jp/national/20150627-OYT1T50044.html
警視庁丸の内署は27日、東京都足立区千住元町、システムエンジニア
福西恭志容疑者(54)を傷害容疑で現行犯逮捕したと発表した。
同署幹部によると、福西容疑者は26日午後11時45分頃、千代田区の
JR東京駅前の路上で、同僚男性(55)ともみ合いになった際、持っていた
ビニール傘で男性の左目にけがを負わせた疑い。
目に刺さった傘が脳を傷つけたとみられ、男性は意識不明の重体。
調べに対し、福西容疑者は「仕事のことで口論し、傘でたたいた」と供述しているという

★傘が目に刺さり…意識不明 同僚と酒飲み、口論の末
http://headlines.yahoo.co.jp/videonews/ann?a=20150627-00000007-ann-soci
JR東京駅の近くの路上で、会社の同僚の目を傘の先で刺したとして54歳の男が
逮捕されました。刺された男性は意識不明の重体です。
システムエンジニアの福西恭志容疑者は、26日午後11時45分ごろ、JR東京駅の
近くの路上で、55歳の同僚男性の目を傘の先で刺した疑いが持たれています。
傘の先は脳まで達していて、男性は病院に搬送されましたが、意識不明の重体です。
警視庁によりますと、2人は別の同僚と一緒に酒を飲んだ帰りで、仕事のことで口論
になり、その後、もみ合いになりました。
取り調べに対して、「傘を持った手で殴りました」と容疑を認めているということです。

513 :仕様書無しさん:2015/06/27(土) 19:04:02.99
(54)と(55)の口論てなんだろ?
晩飯かな?

514 :仕様書無しさん:2015/06/27(土) 20:15:47.97
痴情のもつれだよ

515 :仕様書無しさん:2015/06/27(土) 22:11:16.86
こんなこと情報漏洩とかあると困るから職場内でやってほしいな

516 :仕様書無しさん:2015/06/27(土) 23:24:14.85
>>513
ニュースでは仕事の話って言ってた

517 :仕様書無しさん:2015/06/28(日) 02:41:31.89
オンナの従業員の割合が多い
高いところは1割居ない
低い所は3割以上もいる

518 :仕様書無しさん:2015/06/28(日) 02:43:09.11
>>515
揉み愛って書いてあるしな

519 :仕様書無しさん:2015/06/28(日) 07:46:24.38
7/9が近づいて焦ってるのかも。

520 :仕様書無しさん:2015/06/30(火) 01:15:43.08
>>518
何が漏れてるんですかねぇ、、、

521 :仕様書無しさん:2015/07/01(水) 16:21:09.95
「この品質テストやっておいて」
「わかりました」

「テストが終わりました」
「ごくろうさま、問題なかった?」
「はい」

「一つ不合格になるテストがあるよね」
「えっ!?」

この時点で仕事に対するやる気、理解度、注意力、信頼度を全て失うんだよね
だからあなたは次は呼ばれないし契約してもらえないんだよ

522 :仕様書無しさん:2015/07/01(水) 17:35:09.04
>>521
「テストやっておいて」
という指示に対しては問題ないけどな

523 :仕様書無しさん:2015/07/01(水) 21:51:35.28
>>521
誰がやっても同じ結果にならないのはテスト仕様書が悪い

524 :仕様書無しさん:2015/07/01(水) 22:01:28.17
というか、テスト結果に問題あったかどうか確認するのは
テスト依頼された人間の仕事じゃないだろ…w

525 :仕様書無しさん:2015/07/01(水) 22:34:59.26
「一つ不合格になるテストがあるよね」
「一つだけなわけがないだろw」

526 :仕様書無しさん:2015/07/02(木) 00:02:45.09
>>521
ただの嫌がらせかよ


おまえみたいな奴いらないから死んで

527 :仕様書無しさん:2015/07/02(木) 08:44:06.38
>>526
お前みたいな指示待ちの無能な給料泥棒こそ社会から消えて

528 :仕様書無しさん:2015/07/02(木) 09:51:31.00
NGになるテストはよくいれておくわ。
外注が自社でやります、なんて目の届かないところでテストやらせると
何もしないでOKつけてくるからな。

529 :仕様書無しさん:2015/07/02(木) 12:23:26.64
なんという無駄な労力。そんな暇あったら一つでもテスト通せよ。

530 :仕様書無しさん:2015/07/02(木) 13:05:55.04
>>529
テスト通せないバカだから嫌がらせしてるんじゃん。

531 :仕様書無しさん:2015/07/02(木) 13:57:09.80
話噛み合ってねぇーwww

532 :仕様書無しさん:2015/07/02(木) 15:24:39.53
>>529
テストの想定結果をたまたまミスって書くだけじゃん。
どこに労力がかかるの?

533 :仕様書無しさん:2015/07/02(木) 18:08:27.20
NTTコミュニケーション受託開発裁判情報
追加報酬および損害賠償請求事件
【裁判官】
矢尾渉裁判長
【被 告】
[1次受グローバルウェイ]
・契約外作業追加
・方式不一致指示で作業困難
・期限強要で原告健康障害
・威力業務妨害でNTT問い合わせ阻止
[2次受ビジネスインフォメーションテクノロジー]
訴訟代理人弁護士 東京多摩法律事務所
小澤和彦・伊藤瞳・志賀野歩人・河原 麻子
↓指示強要・無料追加は常識と主張
・報酬を中間搾取
・原告に解約指示
・警察までついてきて原告相談妨害
・関係者に連絡しない旨の署名を強要
[3次受アイピーロジック]
訴訟代理人弁護士 ホライズンパートナーズ法律事務所
荒井里佳
↓報酬搾取不払い・誓約強要を正当化
・請負でなく委託だから瑕疵なしと騙した
・警察までついてきて原告相談妨害
・関係者に連絡したら数千万円払わせると脅迫
・関係者に連絡しない旨の署名を強要
・交代要員費用を原告に要求
・営業費用を原告に要求
・報酬不払い
3社とも原告に指示したことを認めました。
【お問い合わせ】
legal20150108@yahoo.co.jp

534 :仕様書無しさん:2015/07/04(土) 05:48:37.98
テスト駆動開発が最強って話ですね

535 :仕様書無しさん:2015/07/04(土) 11:23:07.94
うん。下手にこじらせてしまった会社は、コードを修正するたびに
大量に人を動員するして人海戦術でテスト仕様書通りに全ての
テストパターンを実行することがプロの仕事だと思ってるw
スクリーンショットを手動で取ることが仕事だと思ってるw
この方法だと、テストにコストがかかりまくるのは言うまでもない話。

自称プロさんは、テストで一つでもバグが見つかったら全部やり直すつもり?w
バグを全て退治できればいいけどそんなことはありえなくて、
でバグが見つかるたびに全部のテストをやり直す?w

そして最後にはテストのコストがかかるから
コードを修正するなと言い始める。

おおよそプロとはよべないテストをしているのが原因なのにね。

536 :仕様書無しさん:2015/07/04(土) 11:33:29.59
>>535
メインフレーム系の開発はそんな感じだよ
勘定系や交通管制等のバグ一つで人が死ぬようなシステムも多いからにバグは一つも出ないようにするのが基本

537 :仕様書無しさん:2015/07/04(土) 11:48:52.13
>>536
昔はメインフレーム関係の開発でバグを出した開発担当者が自殺したという話はよく耳にしたw
最近はどうか知らないが・・・

538 :仕様書無しさん:2015/07/04(土) 11:59:09.37
>>535
俺の職場の悪口を言うな!

改行いれても文句言われるのは
納得いかないけどな

539 :仕様書無しさん:2015/07/04(土) 13:30:06.32
テストの自動化してなくて、ソフトの設計もクソだったら、コードを変更してはいけない。
そういうソフトは決まってデグレするから、コードは追加するだけにする。
自分がミスする可能性を減らし、爆弾を次の人に渡せ。
で、逃げろ。

540 :仕様書無しさん:2015/07/04(土) 13:47:56.11
>>538
すぐに辞めたほうがいいよその会社

541 :仕様書無しさん:2015/07/04(土) 13:51:09.66
>>540
辞めたら行き先ないよ

542 :仕様書無しさん:2015/07/04(土) 15:18:25.77
>>536
スクリーンショットはないんじゃないか?

543 :仕様書無しさん:2015/07/04(土) 16:04:43.56
>>536
> バグは一つも出ないようにするのが基本

Q. バグは一つも出ないようにするにはどうするか

人間が完璧にテストします!
ロボットのように精密にテストして見落としなんかしません!
さらに何人も同じテストをやります。
人件費は度外視です。
根性です!根性!
プロなので疲れていてもミスしません!


まあ、これが馬鹿なやり方なんだよね。
できるわけがないことをやろうとしている。
口で言わなきゃそれがわからないんだもん。

間違いをせずに同じことを繰り返すのが得意なコンピュータを
ソフトウェア開発会社が使わないなんて、どんなマヌケなジョークだよw

テストはコンピュータを使って自動的に繰り返せるようにする。
出来ないところでも頑張って、自動テスト可能なようにしていく。
そうやって人間がやることを減らしていかないと、無理に決まってるんだろ。

自動化すればコード修正するたびに全テストを行えるが、
人間がそれ出来んのか?

544 :仕様書無しさん:2015/07/04(土) 16:08:37.03
>>542
> スクリーンショットはないんじゃないか?
場所によってはいるらしいよw
ちゃんとテストをしたという証拠らしいw

開発会社「システム開発完了しました」
顧客「ちゃんとテストはしたのかね?」
開発会社「はい、これが証拠のスクリーンショットです」
顧客「うむ。ちゃんと動作しているようだな。」
開発会社「では、ここにハンコを」

数日後

顧客「バグってるぞ!動かないじゃないか!」
開発会社「スクリーンショットみてハンコ押しましたよね?」


こういうことに使われるらしいw

545 :仕様書無しさん:2015/07/04(土) 16:12:41.96
>>544
勘定系や交通管制だよ?

546 :仕様書無しさん:2015/07/04(土) 16:23:22.99
295 名前:仕様書無しさん[] 投稿日:2015/06/27(土) 22:19:23.31
>>286
処理を書き換える予定がないなら関数を分ける必要はないのじゃないか。
関数分けると結局このインスタンス変数どこで使われてんだよってことになるよ。
あっちこっち見てるうちに前に見たとこ忘れるし。開発してる段階なら
記憶してるからいいだろうけど、保守で何年も付き合っていくとなると
読みやすいのが一番。

俺はSIerで働いているけど自動化テストは重要視されてない。
納品物としてテストのエビデンスをとらなければいけないから
一つ一つテストしてスクリーンショット貼ってる。

547 :仕様書無しさん:2015/07/04(土) 16:23:27.55
勘定系だったら数値があっているかどうかの証拠写真。

交通管制はしらん。管理画面ぐらいあるだろ?
それの写真。

548 :仕様書無しさん:2015/07/04(土) 16:31:07.22
一回しか使われないから関数にしないとかいうのも馬鹿げてるよなw

一回しか使わなくても、そのコードは何回も読むだろう?
将来も含めて一回しか読まないなら別に複雑でもいいけどさ、
バグってる可能性もあるし、将来も読まないなんてコードは
使い捨てぐらいのコードしかありえない。

で、ほぼ全てのコードは何回も読むという前提にすると可読性を良くする必要がある。
そのために小さな関数に分ける。ただ関数化しても可読性が高くならない例もあって
それは間違った関数化をしてるのが原因。関数化すればなんでもいいわけじゃない。

つまり再利用して生産性を上げるために関数に分けるのではなくて、
可読性を高くするために関数に分けるんだよ。
関数にするのが目的なんじゃなくて可読性を高くするためにの手段。

これに気づいてない人が多すぎるね。

549 :仕様書無しさん:2015/07/04(土) 16:35:56.55
>>548
関数が長いからって新しく作るのはアホ。
1回の手続きや機能でまとめるもの。

550 :仕様書無しさん:2015/07/04(土) 16:44:38.90
>>544
インフラや制御系はそうな

551 :仕様書無しさん:2015/07/04(土) 16:47:46.65
>>549
条件が足りない。

1回の手続きかつ、行数で最大でも
50行以内でまとめなきゃいけない。

長ければ、長いほど、何をやってるのか
わからなくなるんのは言うまでもないだろう?

1関数50行ででまとめるには、どうしても
内部の細々とした処理は別の関数に分けないといけない。

552 :仕様書無しさん:2015/07/04(土) 16:49:05.39
>>551
コードブロックで展開すりゃいいじゃん

553 :仕様書無しさん:2015/07/04(土) 16:49:10.49
可読性の為にやたらと関数分割を行うと、副作用をもつ関数が大量生産される罠

554 :仕様書無しさん:2015/07/04(土) 16:53:39.22
>>551
それに匿名関数とか外出しにしないで内部に閉じ込めておく方法もあるし

555 :仕様書無しさん:2015/07/04(土) 16:54:54.62
>>552
>>554
それじゃ可読性が高くなってない。

>>553
副作用を持たない関数を大量せサンスレばよいだけ。

556 :仕様書無しさん:2015/07/04(土) 16:58:26.79
>>555
わかってるよ
だから「やたらと」「罠」って書いてあるじゃんね

557 :仕様書無しさん:2015/07/04(土) 18:04:23.14
>>547
なんでわざわざスクリーンに?
本当に勘定系さわったことあるの?

558 :仕様書無しさん:2015/07/04(土) 18:32:36.64
>>555
ある機能が複数の手順から成り、
決まった順序で実行しないと意味を成さない、独特な(汎用性のない)手順の場合、

あえて関数分割しないで、
/********* ○○処理 *********/
みたいにコメントでブロック分割した方が
追い易いし、他から間違った手順で呼び方される心配もなく、安全だけどね。

559 :仕様書無しさん:2015/07/04(土) 18:37:23.04
「バグは存在して当たり前」というのはオープン系特有の考え方だよな・・・

560 :仕様書無しさん:2015/07/04(土) 18:42:39.93
>>559
オープン系は信頼性よりも利便性や効率が優先されるからね。
なので信頼性や安定性が重視される勘定系や企業の基幹系は未だにメインフレームが幅を利かせてる。

561 :仕様書無しさん:2015/07/04(土) 18:44:48.99
オープン系は信頼性が低い、という風評がついたのは全てWindowsのせい

562 :仕様書無しさん:2015/07/04(土) 18:50:42.08
オープン系はバグがあっても責務を負わせられないからね。
構造的に「バグは存在して当たり前」になってしまう。

563 :仕様書無しさん:2015/07/04(土) 19:09:31.92
>>558
それ関数の分割の仕方を間違えてるw

長い処理を単純にぶった切ったって
見やすくなるわけ無いだろw.
責任を分割しろって話。

その「○○処理」の中から、責任を分けられる部分を
抜き出して関数化しろって話。

分かりにくいから、もうちょっと具体的に説明るわ。
以下の様なコードがあった時な、

function main() {
  // ○処理
      :
      :
      :
      :

  //△処理
      :
      :
      :
      :

  // □処理
      :
      :
      :
      :
}

564 :仕様書無しさん:2015/07/04(土) 19:09:47.79
>>558
○○処理を関数化した上で
その関数を特定の手順で呼び出す関数を書くよ。

565 :563:2015/07/04(土) 19:12:17.73
>>558
このようにしろとは"言ってない"んだよ。
これだと"何をやるかは具体的な関数の中身を見ないとわからない"から
関数に分ける意味が無いし、あっちこっちにジャンプしなくちゃいけないから
これは間違ったやり方。

function main() {
  ○処理()
  △処理()
  □処理()
}

function ○処理() {
      :
      :
      :
      :
}

function △処理() {
      :
      :
      :
      :
}

function □処理() {
      :
      :
      :
      :
}

566 :563:2015/07/04(土) 19:16:50.53
>>558
正しくはこのようにやる。(関数呼びだしにより:が減った)

function main() {
  // ○処理
      :

  //△処理
      :

  // □処理
      :
}

○処理、△処理、□処理 の中から別の責任に分離できるコードを
分離(殆どの場合別のファイルになる)して
そっちに投げるんだよ。こうやってコードを減らすの。

※例えば汎用関数モジュール
function 汎用関数() {
}

※例えばモデルモジュール
function モデルクラス() {
}

※例えばAPIモジュール
function 外部API() {
}

567 :558:2015/07/04(土) 20:02:18.50
>>563
> 長い処理を単純にぶった切ったって
> 見やすくなるわけ無いだろw.

あたりまえだ、誰が長い処理を単純にぶった切れなんて書いてるw

> 責任を分割しろって話。
> その「○○処理」の中から、責任を分けられる部分を
> 抜き出して関数化しろって話。

クラスなら責任で分割しろというのは分かるが、
今は関数の話だ、機能で分割すべし。
明確な機能として分けられる部分を関数化しろって話だ。

568 :558:2015/07/04(土) 20:04:25.35
>>565-566
長い。
てか、おまえが>>565のような分割はするなって言ってる話と、>>558は同じだ。
一つの機能に汎用性のない(単体では機能定義できない)独特の手順が3つある場合、
わざわざ手順を関数化するな(コメントでブロックを作ればいい)って話だ。

関数は単体で意味を持つ機能単位で切り出すべき。
俺は「機能」おまえは「責任」という概念を使ってるが大筋の主張は同じだ。

569 :仕様書無しさん:2015/07/04(土) 20:23:37.90
行数か50以内とかいうのもイミフ。
そりゃコードは短いに越したことはないが

570 :仕様書無しさん:2015/07/04(土) 20:25:36.17
>>568
その言い分ならクラスでいう所のプライベートメソッドも必要ないな。

571 :仕様書無しさん:2015/07/04(土) 20:31:42.28
>>568が関数を公開するかどうかの自由があることに気付けば
関数の内部をどのように整理するかという議論に進めるのだが?

572 :仕様書無しさん:2015/07/04(土) 20:34:27.23
>>571
進んでどうぞ。
筋違いなこと言い出したら全力で叩くけどw

573 :仕様書無しさん:2015/07/04(土) 20:38:13.96
関数が長すぎると頭に入らないから
処理を細かく関数化してラップするんだろ。
他の場所で使われるかどうかは、問題ではない。
適切にラベル(関数名)をつけてざっくり読めるようにする事が重要だ。

574 :仕様書無しさん:2015/07/04(土) 20:42:27.46
処理の共通化というのは疎結合の視点だが
これは抽象化の視点だわな。

575 :仕様書無しさん:2015/07/04(土) 20:44:05.30
>>573
コメントでええやん。
メソッドを分割する = プログラムを複雑化させる
これわかってる?

576 :仕様書無しさん:2015/07/04(土) 20:55:13.00
>メソッドを分割する = プログラムを複雑化させる
???

577 :仕様書無しさん:2015/07/04(土) 20:56:50.16
ここから〜の処理だと説明するくらいなら
関数化すればいいじゃないの
それをしないのは関数名を考えるのが面倒くさいとか
関数を作るのが面倒くさいとか
まあ怠慢が原因だろ。

578 :仕様書無しさん:2015/07/04(土) 21:03:52.53
>>577
だからコメント書けば仕舞いだろ。
関数分けて仕事した気になってんじゃねえぞw
関数の数 = プログラムの複雑度

579 :仕様書無しさん:2015/07/04(土) 21:03:55.79
>>575の言い分では
メインメソッド一本のみで、処理を都度コピペして
変数名がぶつからないよう細心の注意を払って行うプログラミングが
もっとも簡単なプログラムだそうだ。

580 :仕様書無しさん:2015/07/04(土) 21:06:34.34
>>579
変数は使いまわせるから変数の数も減らすことができる。
つまり、関数を減らす = プログラムの複雑度を低下させる

581 :仕様書無しさん:2015/07/04(土) 21:09:49.12
>>578
コメントの後ろに処理がつらつらと書かれている以上
プログラマの脳みそのスタック領域に情報が積まれていくんだよね。

あ、コメントを読んでソースを見ないってなら、話は別だよ?

582 :仕様書無しさん:2015/07/04(土) 21:10:37.19
>>580
あ、変数名も使い回すんだ。
そういうスタイルw

583 :仕様書無しさん:2015/07/04(土) 21:11:09.76
>>581
ざっくり読めるようにする事が重要

584 :仕様書無しさん:2015/07/04(土) 21:11:13.65
>>580は人間をやめてコンピュータになれば良いと思う。

585 :仕様書無しさん:2015/07/04(土) 21:11:53.49
共通関数化は古代技術
オブジェクト指向も過去の技術
今はすべて副作用なしの関数記述
もちろん可読性なんて関係ないから。

586 :仕様書無しさん:2015/07/04(土) 21:12:23.92
>>582
変数を共通化する = 抽象化されたきれいなコード

587 :仕様書無しさん:2015/07/04(土) 21:13:37.52
変数全部staticで確保すればいいんじゃない?

588 :仕様書無しさん:2015/07/04(土) 21:13:38.95
>>583
そうだね、ざっくり読めるのが重要だよね。
だから関数化しましょうって言ってるんだよ。
難しいことじゃなくて、普段○○処理って書いてる○○を
関数名にすればいいんだよ。

589 :仕様書無しさん:2015/07/04(土) 21:17:03.20
>>588
コメントでええやんか。
関数を分割するってことは状態を引き継がなければならないってこと。
一つの状態を複数の箇所で管理するってこと。
関数の分割 = プログラムの複雑化
と心得よ。

ベテランの開発者なら同意するはず。

2015-05-11(月) 品質の文脈でコメント代わりのメソッドが安易に受け入れられない理由
http://d.hatena.ne.jp/nowokay/20150511


反対するのはにわかのみと心得よ。

590 :仕様書無しさん:2015/07/04(土) 21:18:10.12
>>587
いいとは思えないな。
グローバル変数的なものを使うべきじゃない。
関数分割厨はこれだから・・・。

591 :仕様書無しさん:2015/07/04(土) 21:19:38.81
>>589
君は同じ関数内で別々の処理をすることで
前の処理の状態を延々と引き摺っていることに気付いているかな?

592 :仕様書無しさん:2015/07/04(土) 21:22:12.42
お前らどっかの誰かが書いたえくすとりいむぷろぐらみんぐとか読んで
感化されて関数を分割って言ってるだけだろ。経験不足が痛いほど伝わってくるわ。
こちとら技術大国日本のIT業界しかも品質が絶対の銀行業務で10年以上経験があって
その経験に基づいて関数を分割するべきじゃないと言ってんだぞ。俺の言葉の重さを知れ。

593 :仕様書無しさん:2015/07/04(土) 21:23:13.79
>>592
馬鹿のふりしてるんならやめてくれ
毎度たちが悪いぞ

594 :仕様書無しさん:2015/07/04(土) 21:24:05.97
関数をサブルーチン代わりに使っている奴は総じて低能

595 :仕様書無しさん:2015/07/04(土) 21:26:58.39
>>591
別々の処理ではない。
一つの機能を達成する一連の処理だ。
そこで必要な状態はそこに閉じ込めて外に漏らさないことが大事だ。
そうやってプログラムは単純なままにセキュアに保たれるんだ。

お前のようなやつが日本年金機構のセキュリティ事故を招いたんじゃないでしょうか!?

596 :仕様書無しさん:2015/07/04(土) 21:28:18.55
>>594
ですよねー。言ってやってくださいよ旦那。

597 :仕様書無しさん:2015/07/04(土) 21:29:29.04
>>595
その一連の処理とは?
前の処理で使った変数を全て後ろの処理で使わないといけないのかな?
すると後半の処理では何百個の変数が絡み合うことになるのか。
すごいな。

598 :仕様書無しさん:2015/07/04(土) 21:33:43.52
コボルとかだと関数を宣言するまえに長い呪文を唱えないといけないとか
そういう制約があるのかなあ
仮にあったとしても、言語の表現力がプアな事を
メタな議論で持ち出されても困る。

599 :仕様書無しさん:2015/07/04(土) 21:33:44.20
>>597
何百個も使えへんよ。
使えるところでは使えばいいし、
使いたくないところでは使わなければいいし。
そんなのケースバイケースだって聞くまでもなくわかるよね。

ループ処理って知ってる?
変数を使い回すことで処理を簡潔に記述することができる略記方のことだよ。
かの有名なプログラマ、エドガー・ダイクストラも
ループ処理を使うよう提言してたくらい現代のプログラムにはなくては
ならないものだ。そういうのを駆使すれば現代のプログラムは複雑度を下げることができるわけ。

600 :仕様書無しさん:2015/07/04(土) 21:37:56.70
>>598
それは議論を追えてない。関数を分割するときに状態をどうやって引き継ぐのか
という高度な議論だった。コボルの話なんてしてないし現代の銀行業務系プログラムは
いまはJavaが中心だよね。Javaとオブジェクト指向とLinux。俺はこれで何年も飯食ってる。

601 :仕様書無しさん:2015/07/04(土) 21:39:49.06
>>599
聞くまでもなく判るし、>>597は皮肉で言ったんだよ。

一連の処理といいつつ、各々の処理に必要な情報は、それぞれ違うんだろ?
>>589では状態を引き継ぐ際に、間違った変数を渡してバグを作りこむ心配をしている割に
同じスコープ内で変数を使い回して、間違った変数を使ってバグを作りこむ矛盾に皮肉を言っているの。

602 :仕様書無しさん:2015/07/04(土) 21:42:50.49
この辺は疎結合の話かな

603 :仕様書無しさん:2015/07/04(土) 21:49:15.99
>>601
皮肉だとするならそれは全くの見当違いだって認識してほしい。
関数を分割することによる複雑度の急激な上昇に比べれば
とるに足らないことだ。それくらい文脈でわかるだろ。
極端なことばかり口にしてると現実的なものの見方が分からなくなるぞ。
現実的に関数をわけないことが最適解だというのが俺の経験から
導き出された答えです。俺も若いころは無茶したよ。多態性などのオブジェクト指向技術を
駆使して関数が5行以上だったら即分割してたね。そこまでやったが結局分割しない方が
良いってわかったね。皮肉をいう暇があるなら俺が言うことを実践しろよ。やってから言え。

604 :仕様書無しさん:2015/07/04(土) 21:50:09.35
ループなんか大して重要じゃないよ
プログラムの複雑度を下げる為には、ELSE節が非常に有効に働く

605 :仕様書無しさん:2015/07/04(土) 21:51:14.59
も、もしかして君はあの「staticおじさん」なの?そうなの?

606 :仕様書無しさん:2015/07/04(土) 21:53:18.31
>>603
ごめんなさい。
あなたのレスでは全く納得できない。
納得できる論理がない。

607 :仕様書無しさん:2015/07/04(土) 21:56:12.22
結局自分のやってることがよく判ってないから
そういう終わり方になるんだよな。

608 :仕様書無しさん:2015/07/04(土) 22:02:11.10
>>605
俺はstaticおじさんではないがstaticおじさんが言ってることには
賛同できるところがある。.NETのフレームワークや標準ライブラリは
高機能だからWebアプリケーションのビジネスロジックを組むときに
クラスを定義する必要は基本的にないし状態も必要ない。
だからstaticメソッド中心にプログラムを実装する。ということだろ。
マイクロソフトのコンサルタントやってる赤間信幸も自社のWebアプリケーションに
関する書籍のなかで同じことを述べている。あながち間違いではないってことだな。

609 :仕様書無しさん:2015/07/04(土) 22:04:14.29
あいつはstaticおじさんだからというくだらないレッテル張りで
論理の欠片もなく批判的なことを書いている関数分割厨が憐れで仕方ない。
涙が止まらない。誰か俺の涙を止めてくれ。

610 :仕様書無しさん:2015/07/04(土) 22:06:50.90
>>608
奇遇だね。俺もstaticおじさんは問題があれど叩かれ過ぎだと思ってたよ。
プライベート変数は本質的にグローバル変数と同じ問題を抱えているのだが
staticおじさんは無意識にそれを感じていたようだったね。

611 :仕様書無しさん:2015/07/04(土) 22:08:08.61
突き詰めると関数型プログラミングに移行せよという話になるのだけど
オブジェクト指向が判らないおじさんでは無茶な話なのだった。

612 :仕様書無しさん:2015/07/04(土) 22:14:22.95
この素晴らしき狂った世界をキャンバスに書き留めるのには関数型プログラミングは些か純情すぎるのさ

613 :仕様書無しさん:2015/07/04(土) 22:16:23.46
いわゆるクローンを作らないクラスの定義の話だと思うが

俺はvb.netでmoduleを使う奴を絶対に許さない!!

いわゆる静的なメソッドを作りたければ、public shared function hoge() as boolean
と書きたまえ!

614 :仕様書無しさん:2015/07/04(土) 22:28:31.56
>>606
あるテーブルに500の列があるとする。
そのテーブルのレコードを作成するとき500の列に値を設定する必要がある。
設定する値は10の条件によって決まる。金額による条件で決定される値もあれば
日付によって決定される値もある。この場合500の列に値を設定してSQLを
発行する処理は一つの関数に書くべきだ。ここまでは納得できるな?

615 :仕様書無しさん:2015/07/04(土) 22:30:24.83
>>613
はい。

616 :仕様書無しさん:2015/07/04(土) 22:32:05.12
>>614
それは納得できない

617 :仕様書無しさん:2015/07/04(土) 22:38:36.79
DBに500列定義出来たっけ

618 :仕様書無しさん:2015/07/04(土) 22:49:28.35
>>606
俺も初心者のころはそうやってたな。
経験していけば分かると思うから頑張りなよ

619 :仕様書無しさん:2015/07/04(土) 22:50:15.04
>>616
納得しないことに合理的な理由があるのか?

>>617
余裕だよ。1000位までは大抵対応してる。

620 :仕様書無しさん:2015/07/04(土) 22:54:24.58
>>603
随分と壮大な釣りだな

621 :仕様書無しさん:2015/07/04(土) 23:01:28.01
>>614
いいよ、続けて

622 :仕様書無しさん:2015/07/04(土) 23:03:04.33
>>620
釣りじゃないが?真実だが?
『ThoughtWorksアンソロジー』という本があってだな
それにオブジェクト指向エクササイズという章があるんだよ。
極端なオブジェクト指向も悪くないぜというイカしたことが
書いてあって若き頃の吾輩はすっかりどっぷりはまっちまったわけ。
完全に間違ってたけどな。

http://www.amazon.co.jp/dp/487311389X
このリンクをクリックして注文してくれ。Amazonにお金が入る。

623 :仕様書無しさん:2015/07/04(土) 23:03:34.49
>>621
よくない。納得できるかどうかをまず言えよ。納得できるな?

624 :仕様書無しさん:2015/07/04(土) 23:04:24.45
>>623
納得できるよ

625 :仕様書無しさん:2015/07/04(土) 23:09:09.72
>>624
納得できるなら関数を分割するべきじゃないってわかるな?

626 :仕様書無しさん:2015/07/04(土) 23:13:39.36
>>625
いーえ?

627 :仕様書無しさん:2015/07/04(土) 23:17:30.74
>>626
えぇ!?

628 :仕様書無しさん:2015/07/04(土) 23:18:51.74
いやいや、そこからなぜ関数に分割しないほうがいいか、説明しなさいよ。

629 :仕様書無しさん:2015/07/04(土) 23:19:04.61
>>622
どう考えても釣りだと思うけど

君の言う複雑度とは何か教えてくれる?
多分、一般的な意味と違うよね

630 :仕様書無しさん:2015/07/04(土) 23:25:34.84
>>629
どれだけプログラムが分かりにくいかってことだ。
関数が分割されているとあっち見たりこっち見たりしなければ
処理がわからないし挙句の果てに関数が分割されてることで思いもよらない
ところから参照されていたりする。気づいたときにはもう手遅れだ。
一度リリースしたプログラムは互換性維持という名の元に腐ったコードを抱え込むことになる。
この腐敗の原因は関数分割にある。汚れているのは関数なんです。
ビッチな関数より清楚な関数が良いだろ。そういうことだ。

631 :仕様書無しさん:2015/07/04(土) 23:26:00.43
>>614
10の条件ってどんなのだ?

10の条件を入力したら、
1つの答えを返す関数を作ればいいんじゃないのか?
そうすればテストも簡単だろう。

SQLに代入するべき全ての値が答えがでたら、
SQLを組み立てる関数に投げて、そこから帰ってきたSQLを
データーベースを読み書きする関数に投げれば良いんじゃないのか?

質問が抽象すぎてよくわからん。

632 :仕様書無しさん:2015/07/04(土) 23:28:17.64
>>630
> 関数が分割されているとあっち見たりこっち見たりしなければ
> 処理がわからないし

そもそもそれが間違いなんだよねw

例えば、printf()関数の中身を見たりするかい?
こんなものは「中身を満たなくてもわかる」
だろ?

複雑なのは、長いコードを読まないといけないからなんだよ。
であれば、長いコードを読まなくてもわかるようにすればシンプルになる。

中身を見なくてもやっている内容がわかる関数を
作ることが、可読性を高くするのに必要なことなんだよ。

633 :仕様書無しさん:2015/07/04(土) 23:31:06.27
訂正しなくてもわかると思うけど、
「中身を見なくてもわかる」
な。

可読性が高いコードは、関数の中をみる必要がなくなっている。

634 :仕様書無しさん:2015/07/04(土) 23:31:59.11
>>630

>挙句の果てに関数が分割されてることで思いもよらないところから参照されていたりする

それは関数の公開方法に問題があるのであって
関数を分割するかどうかとは違うお話ですよ。

635 :仕様書無しさん:2015/07/04(土) 23:32:39.54
>>631
・金額がこれこれだったらこの列にはこの値を設定する
・日付がこれこれだったらこの列にはこの値を設定する
というような条件が10個あるってことだ。

列を間違って書いているかもしれないのだから
テストの時には条件も値もチェックしなければならない。
関数を分けたところでテストが減るわけじゃない。

むしろ関数を分けたことによってプログラムの複雑度は増すんだよ。
なぜならば他の処理で間違ってその関数が呼ばれるかもしれないからだ。
関数を統一するっていうのがセキュアで信頼性の高い現実的な方策だっていうのは分かってもらえたものだと思う。

636 :仕様書無しさん:2015/07/04(土) 23:34:10.95
>>635
> ・金額がこれこれだったらこの列にはこの値を設定する
> ・日付がこれこれだったらこの列にはこの値を設定する

じゃあ、その単語を英語にすればいいんだよ?

この列 = 計算処理(金額)
この列 = 計算処理(日付)

な? 条件が10個であれば
10行で終わりだろう。

637 :仕様書無しさん:2015/07/04(土) 23:34:16.14
>>634
あのないくらprivateであっても同じクラス内からは呼べるわけよ?
関数分割した時点でビッチなんだ。その辺の理解してれば公開方法とか関係ない。
分割してるかどうかがすべて。

638 :仕様書無しさん:2015/07/04(土) 23:36:35.70
>>636
条件によって列が特定されるわけじゃねえよ。
列の値が条件によって決まるわけよ?
列の数が500で条件がの数が10なんだから条件ごとに
平均50の列の値が決まるわけよ。そこんとこわかってる?

639 :仕様書無しさん:2015/07/04(土) 23:36:55.87
>>637
だから言語のプアな表現力をメタな議論に持ち出されても困るって

640 :仕様書無しさん:2015/07/04(土) 23:37:07.67
>>635
> 関数を分けたところでテストが減るわけじゃない。
減るよ。


それぞれがifで2つにわかれるとして
条件が10個あれば2の10乗で1,024パターンだ。

だが、それぞれの関数にしたら、
2×10個で20個だ。

だから一塊にして考えたらダメなんだよ。
複座うtなものは、小さく分割してその単位でテストできるようにする。

641 :仕様書無しさん:2015/07/04(土) 23:39:27.56
>>638
データクラスを一つ用意して
・金額によるデータ設定
・日付によるデータ設定
といった関数を並べて、値を設定していけば良いんじゃないかな。
最後に出来上がったデータクラスを元にDBに格納すればよい。

642 :仕様書無しさん:2015/07/04(土) 23:41:15.17
>>638
> 条件によって列が特定されるわけじゃねえよ。
> 列の値が条件によって決まるわけよ?

おい、嘘をつく無いよ。
絶対にそうなるとは限らんだろ?

どうしても分割できない所は仕方ないが、
「なるべく分割すること」が重要なんだよ。

お前が言ってるのは、分割できないことがあるから
考えるのは辞めだ。全部まとめてやろうぜって言ってるにすぎん。
それじゃ複雑になってテストも大変になるだろ。

それはプロの仕事じゃない。


問題が複雑なのはわかってる。だから可能な限り分割して
それぞれを単純なモジュールに分割するのが重要なんだ。

こちとら複雑なものを単純な形に変えるためには
どうすればいいかを考えてるんだぞ?
それがプロの仕事ってもんだ。

643 :仕様書無しさん:2015/07/04(土) 23:42:55.80
>>637
同じクラス内から呼べるのが問題なら
名前空間なりクラス内クラスなり、解決方法は色々あるでしょ。

644 :仕様書無しさん:2015/07/04(土) 23:44:18.15
10の条件で500の項目にデータを入れる
SQLって言ったって、ひつの関数にする必要はないしな。

例えばとあるライブラリは、
項目名とそれに対応する値の連想配列を渡して
insertメソッドを呼び出せば、SQLを組み立てて発行してくれる。
O/Rマッパーもそんな感じ。

これで少なくともその長ったらしい関数から、
SQLを組み立てる処理は汎用化できるたわけだ。

645 :仕様書無しさん:2015/07/05(日) 00:02:06.83
技術力が低い会社にありがちなことスレにふさわしい、
低レベルでかつ無価値な議論w

646 :仕様書無しさん:2015/07/05(日) 00:05:39.13
お前らふざけんなよ。ちょっと待ってろいま牛乳飲んでるんだ。

647 :仕様書無しさん:2015/07/05(日) 00:27:46.41
>>646
なんで牛乳とか飲んでるんだよwww 牛乳吹いたwww

648 :仕様書無しさん:2015/07/05(日) 00:36:47.43
>>632
ではinsertという名前でデータを挿入する関数をひとつ
こしらえれば中身を見なくてもすむようになるよね。
その関数を分割してしまったらどうだろう。
中身を見なくて関数が複数存在することになるね。
どちらがわかりやすいかは一目瞭然関数がひとつの時だよね。

649 :仕様書無しさん:2015/07/05(日) 00:37:51.17
>>639
現実見ろよprivateなメソッドがひとつのメソッドからしか
呼び出せない実装なんてできないだろうが。メタな議論
などという金科玉条のような金玉ひっさげて議論から逃げようとするな。
真正面からかかってこい。

650 :仕様書無しさん:2015/07/05(日) 00:40:49.22
>>640
何言うてんねん。条件だけテストしても列を間違えている
可能性があるだろ。だからテストするとしたら列の数だけ
テストが必要になる。条件通りに列の値が設定されるか
確認するだけじゃないか。

651 :仕様書無しさん:2015/07/05(日) 00:43:13.42
>>641
まじかよ。データオブジェクトを作って
別の関数にそのデータオブジェクトを渡して
データオブジェクトを受け取って
また別の関数にデータオブジェクトを渡して
データオブジェクトを受け取ってってやるわけ?
ひとつの関数で設定する方がよっぽどわかりやすいだろ。
データ引きずり回して値設定するだけの関数作るのかよ。ありえなくね。
スパゲッチィにも程があるだろ。

652 :仕様書無しさん:2015/07/05(日) 00:43:47.85
>>630
これまじで言ってるなら技術力低すぎるっていうか
そもそも根本的にプログラミングの仕方がわかってない

653 :仕様書無しさん:2015/07/05(日) 00:47:31.20
>>642
お前が言うプロという言葉に説得力が感じられない。
特定のテーブルにレコードを挿入する関数なんだからそのテーブルに
レコードを作るときにはその関数が呼ばれるんだよ。
複数の関数が共通の処理を必要とするからという理由で
関数をわけるのは100歩譲って仕方ないと思うが単純な形に
するために分割ってありえないだろ。しかもそれをプロの仕事とか
ありえないだろ。関数分割して客から金を巻き上げてる詐欺師だろ。詐欺師の仕事だよ。この詐欺師が!

654 :仕様書無しさん:2015/07/05(日) 00:49:41.43
>>652
プログラミングの仕方をわかってないのはそちらの方だ。
プログラミングというものを知っているベテランなら俺の意見に賛同するはずだが。
現にこの人はわかってるぞ。

2015-05-11(月) 品質の文脈でコメント代わりのメソッドが安易に受け入れられない理由
http://d.hatena.ne.jp/nowokay/20150511

655 :仕様書無しさん:2015/07/05(日) 00:52:35.47
>>643
おーおーそうやってプログラムが複雑になっていくのか。
日本ITプログラミング業界の闇を見た。
関数を分割しなきゃいいのだよ。単純明快な答えがすぐそばにあるじゃないか。
簡単なやり方を取らずに難解な答えを選び出してプログラムの複雑度をあげ
さも難しいことをやっているように見せかける。もはや目的と手段が逆転してるじゃないか。

656 :仕様書無しさん:2015/07/05(日) 01:29:37.45
何このスレ怖い

657 :仕様書無しさん:2015/07/05(日) 01:33:37.15
>>654
いやお前だよ

マジで無能だと自分が無能なために間違えた前提立ててることにすら気づかないのか?

釣りであることを願うばかりだ…

658 :仕様書無しさん:2015/07/05(日) 02:09:36.96
文体からして、ピアニストのようにキーボードで旋律を奏でる人だろ?
とりあえず俺は応援してる

659 :仕様書無しさん:2015/07/05(日) 02:19:33.48
ソースレビューしてて、リズムが悪いとか不協和音がどうこうとかいうタイプの変人か。

660 :仕様書無しさん:2015/07/05(日) 02:22:04.28
>>648
何言ってるんだ?

関数を二つに分けるってことは、
それぞれの関数ではやってる内容が
シンプルになるってことだぞ?

分けられるものであれば、分けたほうがいいに決まってるだろ。

お前発想が逆なんだよ。

シンプルっていうのは、中身をシンプルにしろってことだ。
仕事を頼む立場で「あとはまかせた」がシンプルって話をしてるんじゃないんだぞ。
俺らが作ってるのは、中身。使う側の話じゃない。

661 :仕様書無しさん:2015/07/05(日) 02:26:24.91
>>650
> 何言うてんねん。条件だけテストしても列を間違えている

なら「条件だけのテスト」とは別に「列を間違えてないかのテスト」をやればいい。

これは二つを複合して、複雑にしたもののテストよりも
単純な物二つに分けて、単体でテストしているから
シンプルになる。

662 :仕様書無しさん:2015/07/05(日) 02:30:55.24
あなたのコードの保守頼まれたんで見たらいちいちジャンプさせられて可読性悪いんですけど。

で、関数のドキュメントみたら、○○の処理でだけ使われる。って書いてあって、じゃあ中に入れておけよって思いました。

663 :仕様書無しさん:2015/07/05(日) 02:32:41.20
>>661
別々にテストしても組み合わせ間違ってる可能性があるんだから
結合テストで洗いださにゃならんでしょうが。
じゃあ最初から分割することなく結合してテストすれば
別々にテストする手間が省けて完成度も高くて信頼性も高いプログラムが作れるよね。

664 :仕様書無しさん:2015/07/05(日) 02:38:58.92
>>660

>>632 を読んで欲しい。
>例えば、printf()関数の中身を見たりするかい?
>こんなものは「中身を満たなくてもわかる」
>だろ?

これはprintfというスペシャルな関数がひとつ存在したから
こそ達成できたことなんだよ。インターフェースによって
複雑さを隠蔽し使いやすさをもたらした恒例だ。

レコードを挿入するたったひとつの関数があればユーザーは迷わない。
ここで言うユーザーっていうのは関数を呼び出す側のことな。
アプリケーションを使う人じゃない。プログラムを書く人のことだ。
そういう人に対しても関数を統一することがメリットをもたらすってことだ。
関数を分割してたらどれを呼び出していいのかわからなくなるだろうが。
結局中身を覗かなければいけなくなる。そんなの瑣末なことなのに。時間の無駄。

665 :仕様書無しさん:2015/07/05(日) 02:43:13.86
作った本人は、この中は見なくていいよーって作ってるんだろうけどさ、後任は一応見るからさ。

そういう意識で仕事して痛い目あってるから。

666 :仕様書無しさん:2015/07/05(日) 02:55:07.98
サブルーチンで分割しておかないと、
デバッガで追うのがめんどい。

667 :仕様書無しさん:2015/07/05(日) 03:13:58.03
>>663
> 別々にテストしても組み合わせ間違ってる可能性があるんだから
> 結合テストで洗いださにゃならんでしょうが。

だからなんだよ?

バグっていうのは単体テストで多くのものを検出するほうが
効率がいいって知らないのか?

よりちいさいくシンプルなものをテストするんだよ。

お前の理屈じゃ統合テストをすれば
個々のテストは不要って言ってるのと同じ。

668 :仕様書無しさん:2015/07/05(日) 03:21:41.87
>>664
「結局中身を覗かなければいけなくなる。」という状態に
してしまってるのが、ダメな関数のわけかたをしてるって言ってるんだよ。
それは>>565-566で俺が説明したじゃん。

このやり方で分けると、「中身を覗かなければいけなくなる」から
ダメな例だって。そのダメな例をお前は俺が指摘したあとで
言ってるだけだよ。一歩遅れてるぞw

まずな、長い関数を二つに分割する。
そうすると、全体から見れば、関数を呼び出す分
複雑になるのは確かなんだよ。

だが、それと同時に関数一つづつを見るとシンプルになってるんだよ。
この二つは矛盾してない。同時に発生する事象。

その上で、全体が複雑になったとしても、小さく分割して
小さい単位でテストしたほうが良いって話をしてるの。

もちろん「中身を覗かなければいけなくなる」ような関数に分けても意味は無い。
だから「中身を覗かなくていい」ような関数に分ける必要がある。
正確に言うならば「中身を一度検証すれば、問題が発生しない限り忘れていい」ことを
「中身を覗かなくていい」と言ってるからね。

「小さい単位で検証して、問題がない限り除く必要がない関数」を作れば
お前の言うような(というか俺が先に言ったw)中身を覗かなければ
いけなくなることが無くなるの

669 :仕様書無しさん:2015/07/05(日) 03:24:26.52
>>665
> 後任は一応見るからさ

だからこそ小さく分けておくんだよな。

複雑で長い関数があると
関数内グローバル変数とでも言うような、
長い関数の中のどこで書き換えられている変わらない!
状態になるから。

670 :仕様書無しさん:2015/07/05(日) 03:31:21.82
>>668
insertって関数がひとつあれば中身を覗く必要なんかないだろ。
insert呼びだせば済む話なんだから。たとえ覗く必要があったとしても
ひとつの関数で完結してれば見る場所も少なくてすぐに把握できるだろ。

insertに関する関数が複数あったら問題だよ。それぞれが
どういう役割を果たしているのか把握しなければならないから
中身を覗かなければいけないよね。どれを呼び出していいかわからないものね。
これが関数分割の弊害なんだよ。

関数が統一されていれば覗かなくていんだよ。それが優れたインターフェースに
よるプログラム設計というものなんだよ。

671 :仕様書無しさん:2015/07/05(日) 03:35:46.09
>>667
統合テストは実際のユースケースに基づいて実施するから
単体テストで洗い出す境界チェックなんかは行わないだろ。
統合テストを持ち出すのは極論だしナンセンス。

672 :仕様書無しさん:2015/07/05(日) 03:36:10.99
>>670
お前insertするっていうだけで
何をどうinsertするのかわかるのか?

insertします。

はい。答えてみてください。
私は何をどこにinsertしたのでしょう?w

673 :仕様書無しさん:2015/07/05(日) 03:37:28.67
>>672
設計書みればわかるしデータ型でもわかるよね。
馬鹿なの?w

674 :仕様書無しさん:2015/07/05(日) 03:38:54.00
ダメな関数のわけかたに、
「責任」ではなく「機能」で分割するってのが有るんだよね。

責任、例えば商品データに関する責任とか
顧客データに関する責任に分けて分割していれば、

商品データのinsertなら、商品データの追加だってわかるし
顧客データのinsertなら、顧客データの追加だってわかる。

>>670は機能で分割したために
insert機能で何を追加するのかわからない上に、
insert機能の中で、if データタイプ == 商品 then とか if データタイプ == 顧客 then
みたいなコードで複雑になってるのが目に見えるねw

675 :仕様書無しさん:2015/07/05(日) 03:40:26.20
>>673
すまんwレス遅れた
お前より先に書いておくべきだった。

そうかやっぱりデータ型で処理を分岐させてるのかーw
だからお前の書く関数は、処理があっちこっちに飛ぶんだよ。

あっちこっちに飛ばない書き方をスレば
最初に一回だけ分岐させれば、あとは一直線。

お前の書くコードは、同じ条件でなんども処理を分岐させてるだろ?

676 :仕様書無しさん:2015/07/05(日) 03:40:46.84
>>674
あるテーブルにレコードを作成する関数って言ってるんだから
特定のテーブルに対するinsertのことだぞ。都合のいいように考えるな。

677 :仕様書無しさん:2015/07/05(日) 03:41:30.11
>>675
いいえ別に。

678 :仕様書無しさん:2015/07/05(日) 03:43:26.68
>>671
誰がいつ境界チェック限定の話したの?

それ以外は「単体テスト」で洗い出すだろ?

それ以外の多くの物が単体テストで見つけられるというのは
それが出来ないような作り方にしてしまってどうするんだよ?って
話をしてるんだが。

お前が言ってるのは、単体テストで洗い出せないものがあるから
全部結合テストで洗い出すようにします。
単体テストをしなくてすんだ。よかったね!って言ってるにすぎん。

679 :仕様書無しさん:2015/07/05(日) 03:44:16.37
>>677
現にinsertでデータ型見て分岐するって言ったじゃんw
自分が言ったことを忘れんなよ

680 :仕様書無しさん:2015/07/05(日) 03:47:01.30
>>676

>>670
> insertって関数がひとつあれば中身を覗く必要なんかないだろ。



> あるテーブルにレコードを作成する関数って言ってるんだから
テーブルごとにinsert関数があるんだぞ。


言ってることが矛盾してるぞw

681 :仕様書無しさん:2015/07/05(日) 03:49:06.52
>>678
単体テストの統合テストの粒度の違いを示すために
一例として俺が境界チェックと言った。

関数分割しなかったら単体テストでできるよね。
関数分割するから結合テストに先延ばしにされるんだよ。

>>679
何をinsertするのかわからないっていってたから
insert関数のシグニチャ見ればわかるよねってことだよ。
忘れてなんかないよ。

682 :仕様書無しさん:2015/07/05(日) 03:50:13.81
>>680
矛盾してないだろ。すべてのテーブルをひとつの関数で処理するって
思ってたの?それはそちらの理解力のなさが原因だ。俺は絶対に悪くない。

683 :仕様書無しさん:2015/07/05(日) 03:54:47.94
矛盾するってことは解釈がおかしいと考えて
矛盾しない解釈を選択するっていうのが理解力だと我輩は思うぞ。

684 :仕様書無しさん:2015/07/05(日) 03:56:18.31
>>526
仕事に対するやる気とか注意力とかに依存するのも馬鹿かと。

685 :仕様書無しさん:2015/07/05(日) 03:57:57.59
>>532
外注使ってテストしてるところ。

686 :仕様書無しさん:2015/07/05(日) 03:57:57.91
>>684
> 関数分割しなかったら単体テストでできるよね。
できねーよw

687 :仕様書無しさん:2015/07/05(日) 03:58:53.75
>>681
> 何をinsertするのかわからないっていってたから
> insert関数のシグニチャ見ればわかるよねってことだよ。

insert関数のシグニチャごとに
別関数を作るって話か?

一つのinsert関数の話をしたんだろ?
オーバーライドが出来ない言語では、
データ型を見てやっぱり処理を分岐させるんじゃんw

688 :仕様書無しさん:2015/07/05(日) 04:00:04.79
>>684
> 仕事に対するやる気とか注意力とかに依存するのも馬鹿かと。

たかが一関数5000行のコードだろ。
それぐらいやる気も注意力もいらん。
根性さえあればできる。

689 :仕様書無しさん:2015/07/05(日) 04:03:41.66
>>686
なんでだ?やる気ないのか?
入力値変えて結果確認するだけだろうが。
契約切られたいのか?やれや。

690 :仕様書無しさん:2015/07/05(日) 04:04:57.80
全部main関数一つに書いたのだから
このテストが単体テストです。
とか思っていそうw

単体テストは、各モジュールを小さく分けて
"結合前" の状態を作ることで、できるテストなんだよ。

単体テストができるものを、単体にしないのは
怠慢でしか無い。

単体テストは重要です。

691 :仕様書無しさん:2015/07/05(日) 04:05:24.12
>>687
あるテーブルにインサートするってボタンが
画面にあります。ユーザーはそのボタンを押下します。
それによってあるテーブルにインサートする処理が行われます。
以上がマニュアルから抜粋した機能だ。処理の分岐はボタン押下の時点で
行われているから気にしなくていい。気にしなくて結構だ。

692 :仕様書無しさん:2015/07/05(日) 04:07:31.88
>>689
> 入力値変えて結果確認するだけだろうが。

それができないんだよ。
なにせ結合されてしまってるから、
10個の入力値で単純な2分岐が10個あるだけでも
1024パターンにもなってしまう。

3分岐なら59,049パターン
4分岐なら1,048,576パターン
10分岐なら10,000,000,000パターンだね。

時間がいくらあってもできない。

693 :仕様書無しさん:2015/07/05(日) 04:08:37.52
>>690
単体テストは関数ごとに行うテストなんだから
insert関数への入力を変えてテストしたならそれは立派な単体テストだ。
分割する必要のないところを分割するのが勤勉だとは俺は思わない。
むしろプログラムに対する無知という意味でそれこそが怠慢だ。

694 :仕様書無しさん:2015/07/05(日) 04:08:42.07
>>691
俺らは中身を作ってるんだ。
使う側のシンプルの話をしてるんじゃない。
その時点でお前は”作ってない”ことがバレバレなんだよw

695 :仕様書無しさん:2015/07/05(日) 04:09:31.75
>>693
> 単体テストは関数ごとに行うテストなんだから
> insert関数への入力を変えてテストしたならそれは立派な単体テストだ。

その理屈で言えば、結合したものを本当に
1つの関数に結合すれば、単体テストになるってことだよな?w

696 :仕様書無しさん:2015/07/05(日) 04:11:05.31
単体テストっていうのは
処理が単体じゃなくて、
責任の内容が単体って意味だべ?

>>693
お前がやってるのは「結合しちゃってるテスト」だよ。

697 :仕様書無しさん:2015/07/05(日) 04:12:31.13
>>692
時間がいくらあってもできないものはやらないよ。
なぜならばできないからねwすべての組み合わせをテストするなんて
やる必要もないよね。

それぞれの列に着目してその列に対する条件を変えて
テストすることはできるよね?じゃあテストできるってことだ。

698 :仕様書無しさん:2015/07/05(日) 04:15:20.55
>>694
俺らってなんだよ数の力に頼ってんじゃねえよw
議論の場においては俺とお前それ以外に必要ない。
俺はお前しか眼中にないしお前は俺だけみてればいい。

今回俺が議論しているシステムが実際にそういう作りなんだから
テーブルで分岐することは考えなくて結構だということを言っているんだ。
考えてくれなくて構わないんだ。

699 :仕様書無しさん:2015/07/05(日) 04:16:35.69
>>566
それは正しくない。
なぜなら、長くメンテナンスされていると○処理と△処理と□処理の間に
無駄な結合が生じるから。コメントを書いておけば他人もその通りに
コーディングしてくれると信じているのならよほどの馬鹿だ。
従って、以下のようにすべき。

function main() {
  // 処理全体で使う変数はここで定義

  // ○処理
  {
   // ○処理の中だけで使う変数はここで定義
      :
  }

  //△処理
  {
   // △処理の中だけで使う変数はここで定義
      :
  }

  // □処理
  {
   // □処理の中だけで使う変数はここで定義
      :
  }
}
が正解。

700 :仕様書無しさん:2015/07/05(日) 04:17:52.56
>>695
そうなるな。俺はやらないけどな。そういう極端なことは大嫌いだしナンセンスだ。

>>696
そんな造語を語られても俺様どうしていいかわからない。
余計な分割をしてないだけの立派な単体テストだろ。

701 :仕様書無しさん:2015/07/05(日) 04:18:28.55
>>699
大正解だ。もっと言ってやってくれ。

702 :仕様書無しさん:2015/07/05(日) 07:02:38.74
>>551
ひたすら小分けしてかえって可読性とコード量を犠牲にしてる本末転倒な
素人プログラマーの書いたコードをよく目にする。
関数化するということは無駄なI/O設計も増えるわけで
中にはグローバル変数で逃げる奴も多数。
だからかえって可読性も落ちるしバグもかなり多い。
何よりデバッグし難い。

50行ルールって大昔のコード書かない奴が作った悪習慣の一つだろう。

703 :仕様書無しさん:2015/07/05(日) 07:32:14.84
そこまで単純化できるなら
ジェネレータ作るから書法なんか関係ないわ。

704 :仕様書無しさん:2015/07/05(日) 07:43:55.79
なんで○処理と△処理と□処理を無理矢理一つの関数に押し込めなあかんねんw

705 :仕様書無しさん:2015/07/05(日) 07:46:15.87
3秒ルールはありだろ

706 :仕様書無しさん:2015/07/05(日) 08:05:07.58
>>704
1カ所でしか使うことのないロジックをわざわざ関数分割したとして
情報のI/Oに膨大な引数や専用の構造体、ポインタや参照を必要としたら
それだけで充分すぎるほどの複雑化と言えるだろう。

引数を簡素化するために1ロジックでしか使わないローカル変数を
メンバ変数やグローバル変数なんかに展開したら初期化系の不備や
無関係な関数からの参照が可能になる(後でコードを読んだ奴が
このメンバ変数は全体として使われると勘違いするのは避けるべき)

707 :仕様書無しさん:2015/07/05(日) 08:15:08.49
同じコードが連続しても分割しないバカコードを料理名で喩えて「スパゲティ」と呼ぶなら
無駄な分割で複雑化に貢献してるバカコードを「肉そぼろ」とでも呼んでおくか

708 :仕様書無しさん:2015/07/05(日) 08:25:41.88
おっさんずっと起きてたのか?中の人が変わってるのか?

709 :仕様書無しさん:2015/07/05(日) 08:51:02.89
>>658
このおっさんに5,6回やられてる
俺馬鹿なのかな

710 :仕様書無しさん:2015/07/05(日) 09:28:23.81
>>709
分割ちゃうわ。はなから別のもんを一つにしてるだけや。

711 :仕様書無しさん:2015/07/05(日) 10:15:48.56
技術力が低い会社にありがちな事というと、

1関数が100行以上あるのがあたりまえで、
分岐のブロックが作業モニタの1画面に納まり切ってなくて、
試験でおかしな動作が当たり前のようにあちこちで出てきて、
上から下から左から右までコードで埋め尽くされた画面を上下にスクロールさせながら
納期が近いから毎日遅くまで残業して眺め続けていて、
そんな最中に「レスポンスが遅すぎる」とかいうかなりクリティカルな問題点の指摘までされて、
本当に泥沼の様になりながら改修をしてるんだけど、

飲み会とかでは、まるで自分は人並み以上に出来ているといった自信満々の態度で
コーディングの作法について持論を展開してくれたりするかな。

712 :仕様書無しさん:2015/07/05(日) 10:24:35.12
>>702

>ひたすら小分けしてかえって可読性とコード量を犠牲にしてる本末転倒な
>素人プログラマーの書いたコードをよく目にする。

のは事実で、それはダメなコーディングなんだけど、
だからって正しく小分けにする事を否定する理由にはならないし、

>50行ルールって大昔のコード書かない奴が作った悪習慣の一つだろう。

こんなこと言ってるところをみると多分目くそ鼻くそな人だろうなと思う。

713 :仕様書無しさん:2015/07/05(日) 10:48:19.44
>>676

>あるテーブルにレコードを作成する関数って言ってるんだから
>特定のテーブルに対するinsertのことだぞ。

ん? テーブル毎にinsert関数があるの? DAO的な…
もしそうなら今時そんなクソ設計しちゃダメなんじゃないかな?

714 :仕様書無しさん:2015/07/05(日) 10:57:59.37
話がややこしくなってるのは、分割する事そのものしか頭にないために、
無駄で余計にメンテナンスのしにくい分割をする奴がいるからなんでしょ?

「今日は銀行に行ってお金を振り込んだ後、スーパーで特売のサンマを3匹買ってくる」

という処理に対して、

「車を運転する」というクラスやメソッドを作ればいいのに、
「銀行まで車を運転する」「銀行からスーパーまで車を運転する」「スーパーから家まで車を運転する」
っていうクラスやメソッドを作っちゃうやつが実際にいる。
抽象化の意味を解ってない奴。

だからテーブル毎insertを行うクラスやメソッドをつくっちゃって、
山のようなファイルが出来上がるって事が実際にあちこちで起こっている。

715 :仕様書無しさん:2015/07/05(日) 11:41:39.52
>>714
ちょっと問題見誤ってるよ。
これは抽象化じゃなくて、手続きの分け方だよ。

1.車でスーパーに行ってカレー粉、にんじん、たまねぎ、肉を買う。
2.家に帰ってカレーを作る

こうゆう汎用的ではない一連の行動を関数で分けるのか1つにして、コードブロックやコメントで分けるのかといった問題。

716 :仕様書無しさん:2015/07/05(日) 11:46:39.51
関数を分けるとその処理で使う共通の変数を引数、グローバル変数にしなければいけないため、関数でなくコードブロックでスコープを定義する。

717 :仕様書無しさん:2015/07/05(日) 12:14:47.71
>>699
○△□とか使ってる時点で、おまえプログラマじゃないだろw

718 :仕様書無しさん:2015/07/05(日) 12:25:51.37
>>715
一連の行動と言う事は、アトミックではない別々の行動の連なりだろ。
いくらなんでも、それをひとかたまりの処理に実装しようというのはキチガイすぎる。

719 :仕様書無しさん:2015/07/05(日) 12:31:49.58
プログラマならコードで会話しろよ

720 :仕様書無しさん:2015/07/05(日) 12:35:14.78
>>671
>単体テストで洗い出す境界チェックなんかは行わないだろ。

やるよ、やってよ、だいじだよ。

721 :仕様書無しさん:2015/07/05(日) 12:37:14.23
>>674
関数(function)って機能だろうがよw
半端にOOかじるとこうなるの?

722 :仕様書無しさん:2015/07/05(日) 12:37:45.05
>>715が何を言っているのかよくわからんのは、

僕が酔っぱらったからなのか、
>715の例がおかしいのか

どちらなんだろう? >>718を見るとやはり後者のように見えるが…

723 :仕様書無しさん:2015/07/05(日) 12:43:48.55
>>714
同じ形のテーブルなら車と同じだろうけど、
本当に全て同じなの?

724 :仕様書無しさん:2015/07/05(日) 12:54:22.45
>>718
>1.車でスーパーに行って...
>2.家に帰ってカレーを作る

これがアトミックではない別々の行動の連なりだろ?

>ひとかたまりの処理に実装しようというのはキチガイすぎる。

どこかでひとかたまりにする必要はあるよね。
そしたら

>関数で分けるのか1つにして、コードブロックやコメントで分けるのか

こういうはなしじゃん。

>>722は昼間から酔っぱらってるダメ人間

725 :仕様書無しさん:2015/07/05(日) 13:04:26.14
>>714
> 「車を運転する」というクラスやメソッドを作ればいいのに、
> 「銀行まで車を運転する」「銀行からスーパーまで車を運転する」「スーパーから家まで車を運転する」
> っていうクラスやメソッドを作っちゃうやつが実際にいる。

「車を運転する」というメソッドは作るよ。
その上で「銀行まで車を運転する」というメソッドも作る。


「車を運転する」というのは汎用メソッドで、
さらに"ビジネスロジック"として「銀行まで車を運転する」というメソッドも必要。

「車を運転する」メソッドだけで、
どんな場所にも対応できるようにすると、
それは複雑なものになってしまう。

726 :仕様書無しさん:2015/07/05(日) 13:07:32.56
「銀行まで車を運転する」というメソッドを作るのは無駄だと思うかもしれないが、
「車を運転する」という汎用メソッドを内部で呼び出すので、
作るのは差分だけでいい。

そうすると、銀行に対する責任を持ったモジュールに分離できる。

こうすることで、銀行が変わった時も、
このモジュールだけ変更すれば良くなる。

727 :仕様書無しさん:2015/07/05(日) 13:12:29.48
>>713
> ん? テーブル毎にinsert関数があるの? DAO的な…

テーブルごとにinsertが有るのと、DAOが何の関係があんの

そもそもテーブル毎に作るんじゃなくて対象ごとに作る。
内部がデータベースであるか、ファイルであるかすら
そのクラスの利用者側からは分からない。

Bank.insert(params);

こうすることで、内部の実装を隠蔽できる。

銀行毎に必要なパラメータは違うのだから、
どれもinsertとするからといって、insertにまとめてはいけない。

これのBank.insert()はデータベースへの"insert"ではない。
対象に対するinsertであり。対象毎にパラメータは違うし、
内部の実装も違う可能性がある。

> もしそうなら今時そんなクソ設計しちゃダメなんじゃないかな?
いまどきのフレームワークで、テーブル(モジュール)毎に
insertがないものを教えてくれ。

728 :仕様書無しさん:2015/07/05(日) 13:13:51.33
もういいや
おまえら自分のgithub晒せや
話はそれからだ

729 :仕様書無しさん:2015/07/05(日) 13:16:41.27
初心者がよく間違える分割の仕方の一つとして

対象(責任)ごとに分割するのではなく、
機能ごとに分割するって言うのが有る。

全部insertという機能だから、全部まとめたほうがいいんじゃね?
⇒ insertモジュールができて、その中でいろんな対象に対するinsertが書かれる。

関数を共通化したほうがいいんじゃね?
⇒ insertXXX()、insertYYY() ではなく、全部insert()一つになる。
⇒ そしてinsertの中で、if data_type == XXX、if data_type ==YYY というコードでいっぱいになる。
⇒ さらに特定のデータの時だけ、例外的な処理が入ると、そのためのコードが・・・と複雑になる。

これが機能毎に間違った分割をした場合に発生する問題。
責任毎に分割していれば、このようなことはなくなる。

730 :仕様書無しさん:2015/07/05(日) 13:24:24.57
あ、そうそう。例がアレだったからそれに合わせたけど、
本来は
Bank.運転()
なんて書き方はしないぞw

本来は
車.運転(場所)
が正しい。

銀行毎に、運転があるのではなく、
この場合の責任は、車だ。

731 :仕様書無しさん:2015/07/05(日) 13:26:27.65
車.運転();
飛行機.運転();
船.運転();

車データ.insert();
飛行機データ.insert();
船データ.insert();


対象(責任)毎にinsertは存在する。
一つにまとめたりしない。

732 :仕様書無しさん:2015/07/05(日) 13:29:20.83
>>729
⇒ insertXXX()、insertYYY() ができる。
⇒ それらを呼ぶ処理が、if data_type == XXX insertXXX()、if data_type ==YYY insertYYY() というコードでいっぱいになる。
⇒ さらに特定のデータの時だけ、例外的な処理が入ると、そのためのコードをあちこち修正しなければならない。

>責任毎に分割していれば、このようなことはなくなる。

こういう視野の狭い人は、別のところで破綻するよね。

733 :仕様書無しさん:2015/07/05(日) 13:30:32.21
>>732
いやw それでレスの内容はどうしたよ?w

734 :仕様書無しさん:2015/07/05(日) 13:31:30.13
視野の狭い人は、別のところで破綻するっていってるだろ!

その理由ぐらい、自分で探せ!

735 :仕様書無しさん:2015/07/05(日) 13:32:27.14
はいはい。言えることがなにもないんですねw

736 :仕様書無しさん:2015/07/05(日) 13:43:50.52
>>726 >>729
責任て言葉好きだねえ。
「銀行に対する責任を持ったモジュール」って何のことだよw正体不明感がハンパないわ。

正しくは「車」という対象を「銀行まで運転する」という機能だろ。
当然「車」を「銀行まで運転する」と「バイク」を「銀行まで運転する」は別機能だ。
そういう明確に機能定義できる内容を関数化すればいいんじゃないのかい?

銀行に対する責任てなによ?おまえは日銀総裁かよ

737 :仕様書無しさん:2015/07/05(日) 13:46:24.16
責任て言葉好きだねえ。

はい。プログラミングで重要な原則の一つですからね。

SOLIDの原則: Part1 - 単一責任の原則(Single Responsibility Principle)
http://code.tutsplus.com/ja/tutorials/solid-part-1-the-single-responsibility-principle--net-36074


まさか知らないってことはないでしょう?w

738 :仕様書無しさん:2015/07/05(日) 13:47:57.06
ここからSRPの話に持っていけばいいのか?
ここなんかわかりやすいと思うよ。

■[オブジェクト指向設計原則]単一責任の原則(SRP
http://d.hatena.ne.jp/asakichy/20090124/1232793592
クラスを変更する理由は1つより多く存在してはならない。

どういうこと?

変更理由が2つあるということは、責任(役割)も2つあるということ。
そんなジェネラリストなクラスを許さない、という原則。
ところで、

「単一責任」って、クラスを作る上で一見当たり前に見える。
責任(役割)をそのまま責任ではなく、変更理由としているところがポイント。
この見る角度を変えるところがこの原則の運用の大切な所。

739 :仕様書無しさん:2015/07/05(日) 13:53:01.17
プログラマが知るべき97のこと/エッセイ一覧/単一責任原則
http://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E5%8D%98%E4%B8%80%E8%B2%AC%E4%BB%BB%E5%8E%9F%E5%89%87

> 「変更する理由が同じものは集める、変更する理由が違うものは分ける。」
> 良いデザインの基本原則を1つあげるとすればこれでしょう。
>
> この原則は「単一責任原則 (Single Responsibility Principle :SR P)」と呼ばれています。
> これはつまり、1つのサブシステムやモジュール、クラス、関数などに、
> 変更する理由が2つ以上あるようではいけない、ということです。1つ典型的な例をあげましょう。
> ビジネス ルール、レポート、データベースに関わるメソッドを持つクラスの例です。

> calculatePayメソッドには、給与計算に関わるビジネスルールが変わる度に、変更を加える必要があります。
> reportHoursメソッドには、レポートのフォーマットが変わる度に、変更を加える必要があります
> saveメソッドには、DBAがデータベーススキーマを変更する度に、変更を加える必要があります。
> 3つも変更理由があるEmployeeクラスは、非常に不安定な存在と言えます。
> 3つの理由のうちいずれかがあれば変更されてしまうからです。


これはクラスの例だけど、insert関数一つにまとめるともっとひどくて、
銀行スキーマが変われば、insert関数を変更する
顧客スキーマが変われば、insert関数を変更する

なんてことはやったらだめなんだ。

もちろん一つのファイル(モジュール)に変更する理由が複数あるのもよくない。 👀
Rock54: Caution(BBR-MD5:aea3fcc442ae669623a40c8bff7a82c4)


740 :仕様書無しさん:2015/07/05(日) 13:54:33.78
>>736
> 銀行に対する責任てなによ?おまえは日銀総裁かよ

まさか「責任」という専門用語があるということすら
しらない程度の人間だったとは・・・

これではっきりしたね。技術レベル的にw

741 :仕様書無しさん:2015/07/05(日) 13:55:59.91
仕様不明のソースを単体テストしてと言われて
とりあえずC1カバレッジ100%にしたけど、
テストとしてどう思う?

742 :仕様書無しさん:2015/07/05(日) 13:58:02.20
>>741
テストがどうかを判断する方法は、
テストコードを読むこと。

テストコードが読めない以上
判断できない。

どうもさ、この業界の一部の人間って
コードを読むことをしないよね?

バグを探すのにコードを読まないで
色々操作して、あれ?さっきおかしくなったんですよ。
とか言ってる奴が多い。

743 :仕様書無しさん:2015/07/05(日) 13:59:59.45
>>737-740
クラス、オブジェクト、的な意味で「責任」て言葉を使うなら、それは「車」であり「バイク」でしょうよ。
「銀行に対する責任」って何?
ギリシャのデフォルトに対して、地方銀行が経営破綻とかしないよう管理するのか?

これではっきりした
おまえのは無理して知ってる言葉を使ったが、正しい概念的が伴ってない典型だ。
つまりズレてる。ということが言いたかったが伝わらなくて残念だ。

744 :仕様書無しさん:2015/07/05(日) 14:00:11.49
>>723

ん? その差異を吸収するために普通はエンティティを用いるじゃない。
言ってることわからないのかな?

745 :仕様書無しさん:2015/07/05(日) 14:01:30.95
>>734
> 「銀行に対する責任」って何?

例えば、ATMであれば、各銀行の情報を持っていて、
その銀行データに関する責任でしょう?

746 :仕様書無しさん:2015/07/05(日) 14:02:30.81
>>734じゃなくて>>743

あとお前が「責任」という用語を知らなかったからって、
俺の方を無知にしようとする戦略に切り替えたって無駄だよw
やり方があからさまでワロタw

747 :仕様書無しさん:2015/07/05(日) 14:02:50.86
>>742
テストはcpptestだから
変数とスタブ設定して
関数呼ぶだけ

748 :仕様書無しさん:2015/07/05(日) 14:04:07.59
>>727

まだそんなコード書いてるのか…

DBにinsertする機能だけに絞って考えるのが分かり易いけど、
insertする処理はどのテーブルもほとんど一緒でしょ?

違うのはエンティティだけ。

だから、エンティティだけ切り離して、それを元に動的にコードを生成する。
今時のO/Rマッパーは普通そうなってるでしょ?
そういう共通の部分は基底クラスに包含されているから、
あちこちにそのテーブル専用のinsertメソッドができるなんていう
古臭いつくりはしてないはずだよ。

749 :仕様書無しさん:2015/07/05(日) 14:05:04.52
>>747
誰がテストのやり方の話を聞いた?

そのやり方で、
どのような「テスト」をしたかを聞いてるんだよ。

どのようなテスト = テストコード だ。

750 :仕様書無しさん:2015/07/05(日) 14:07:10.83
>>731のはヤバいなぁ…

オブジェクト思考がわかってないのかな?

各クラスがinsertメソッドを継承してるってことと、
各クラスにinsertメソッドがあるってことは別の事だけどなぁ…

751 :仕様書無しさん:2015/07/05(日) 14:07:15.75
>>749
単体テストツールつかったことある?

カバレッジをC1で通すなら
中の分岐を真偽全部検証したら
OKだよ

752 :仕様書無しさん:2015/07/05(日) 14:09:22.37
思考しちゃった…

753 :仕様書無しさん:2015/07/05(日) 14:09:49.65
>>745-746
お前自身、ATMの話をしてたかい?
車で銀行まで行くことに対して話してたんじゃないのかい?
わかりやすい前提のすり替え、ごまかしだねえw

「責任」などという一般用語を、特定の意味で使うなら正しい概念で使わなければ意味は通じない。
そういうのは相手の知識の問題じゃなく、
おまえが持ってる概念がズレてるため話が噛み合わないってのが問題だ。
勉強しろよw

754 :仕様書無しさん:2015/07/05(日) 14:11:14.91
>>748
> まだそんなコード書いてるのか…
全てのフレームワークがそういうコードを書くようになってますからね?
あなたは、いま何を使ってるんですか?

> DBにinsertする機能だけに絞って考えるのが分かり易いけど、
> insertする処理はどのテーブルもほとんど一緒でしょ?

データベース操作に対する責任と、テーブルに対する責任が混ざってますよ?w
同じ「insert」だから勘違いしてるんでしょうね。
SQL(実装)のINSRET文に依存してしまって、抽象的に考えられないのかな。

データベース操作のinsertとは別の名前にした方がいいんじゃないですか?
テーブル(対象)に対する操作はcreateにすればわかりやすい。

データベースへの操作はinsert()。
O/Rマッパーという用語だけは知っているようですから、
モデルといいましょうか? モデルの操作はcreate()
実際にモデルごとにcreate()ありますからね。

そうすれば、モデルごとにcreate()があって、その中でデータベースを
使っているならば、insert()を行うって考えればわかりやすいでしょう?
モデルはデータベースを使うことは必須ではなくて、
実装がファイルになっても、モデルにあるメソッドはcreate();
実装がファイルだとinsertではなくてwrite()でしょうね。

755 :仕様書無しさん:2015/07/05(日) 14:11:19.64
技術力が低いとこういう無毛な論争にハッテンしがち

756 :仕様書無しさん:2015/07/05(日) 14:12:54.73
>>751
だからなんなんだよ?
俺はテストがどうかの話をしてるの。

(C1を満たしているテストの)
テストとしてどう思う?
って聞かれたから、

テストコードを見ないとわからないって答えてるの。

757 :仕様書無しさん:2015/07/05(日) 14:13:07.86
>>754

何が言いたいのか最初からよくわかりません。

>全てのフレームワークがそういうコードを書くようになってますからね?

って何でしょう?
気持ちを落ち着けてから書いていただけますか? 別に喧嘩しているわけではないので。

758 :仕様書無しさん:2015/07/05(日) 14:13:37.75
>>750
> 各クラスにinsertメソッドがあるってことは別の事だけどなぁ…

まーた、理由を言わずに、
「俺のほうが正しいんです!」というレスかよ。
そんなに見ても何の説得力もないぞw

759 :仕様書無しさん:2015/07/05(日) 14:14:43.61
>>757
だから、今普通の書き方をしているのに

まだそんなコードってどういう意味ですか?って
聞いてるんですが?

あなたの書くコードが古いんじゃないですか?

760 :仕様書無しさん:2015/07/05(日) 14:16:08.07
今だとRais、Django、CakePHP(かなり古いバージョン)、あたりを
使ったことあるけど、どれもモデル毎に
insertメソッドが有るよ。

761 :仕様書無しさん:2015/07/05(日) 14:16:35.33
>だから、今普通の書き方をしているのに
>まだそんなコードってどういう意味ですか?って
>聞いてるんですが?

という趣旨の質問が、

>全てのフレームワークがそういうコードを書くようになってますからね?

なんですか? 本当に何を言っているのか分からない人だな…

762 :仕様書無しさん:2015/07/05(日) 14:18:15.58
>760

それ、単純に継承してるだけじゃないんですか?
モデル内にコードを生成してるんですか?

763 :仕様書無しさん:2015/07/05(日) 14:23:12.10
>まーた、理由を言わずに、
>「俺のほうが正しいんです!」というレスかよ。

だって継承すればコードは基底クラス1か所にあるわけですから
テストはそこを通せばいいだけですが、
全部のモデルクラスに実装してたら、
その全てでテストしなければならないでしょう?

何かおかしな事でもありますか?

>そんなに見ても何の説得力もないぞw

助詞が変になるほど興奮しないでいいと思うんですけど…
別に喧嘩してるわけじゃないんだし。

764 :仕様書無しさん:2015/07/05(日) 14:27:40.48
>>754

>データベース操作のinsertとは別の名前にした方がいいんじゃないですか?
>テーブル(対象)に対する操作はcreateにすればわかりやすい。

ほう、それはまた何故でしょう?

insert()メソッドを作ると不都合な事があるのでしょうか?
また、create()にすると分かりやすい理由とは何でしょう?

765 :仕様書無しさん:2015/07/05(日) 14:28:36.64
>>706
うーん、まず関数化するときにI/Oに膨大なパラメータが必要な時点で失敗してると思うんだよね。
それって結局、関数化してなくても膨大な変数を扱わないといけないってことでしょ。
バグの温床だよね。
正直見たくないよね。
動いてるのならそっとしておくよね。

766 :仕様書無しさん:2015/07/05(日) 14:29:35.18
>>717
それは元のレス書いたやつに言ってくれ。

767 :仕様書無しさん:2015/07/05(日) 14:37:03.61
どうでもいい事かもしれないんですが、
どうしてプログラマーって、自分と考え方が違う人にあうと
すぐ頭に血がのぼってぶち切れするんでしょう?

768 :仕様書無しさん:2015/07/05(日) 14:38:35.43
>>767
ソンナコトナイヨ

769 :仕様書無しさん:2015/07/05(日) 14:40:02.42
>>756
ならレスしなくて結構です
もっともやっとした回答でいいのに
つっかかられると困ります

770 :仕様書無しさん:2015/07/05(日) 14:41:16.73
>>715
1. goToSuperMarketAndBuyCarrayPowderAndCarrotAndOnionAndBeaf();
2. returnToHomeAndMakeCurry();
というような関数分割しか頭に浮かばないのなら頭が悪い。

関数分割するとしたら以下のような感じだろう。
1. goTo(SuperMarket);
2. buy([carryPowder, carrot, onion, beaf]);
3. returnToHome();
4. makeCurry([carryPowder, carrot, onion, beaf]);
それぞれの関数の責務も明らかだし、単体テストもしやすい。

771 :仕様書無しさん:2015/07/05(日) 14:44:18.99
>>768
ソウナライインデスガ

772 :仕様書無しさん:2015/07/05(日) 14:49:31.27
>>767
それは、ネコが動くものに飛びつくのと同じです。
そうやって訓練してないといざというとき狩りができなくなるという本能からです。

ど素人の無茶振り提案やバカ設計を押し切られてしまわないよう、
ぶち切れる訓練をするという本能的が備わっているのです。

773 :仕様書無しさん:2015/07/05(日) 14:51:43.42
>>770

僕が想定していたのは

function exec(){
goToBank();
goToMall();
returnToHome();
}

で、各メソッド内で、doDrive();メソッドを呼ぶという処理です。

これであれば、行く順番が変わったとしても、メソッド呼び出しの順番を入れ替えるだけですし、
仮にバスで移動することになったらdoDrive()を修正するか別のメソッドを呼び出すだけです。

ですが、goToBankByCar()、goToMallByCar()、returnToHomeByCar()というメソッドを作ったら、
バスで行くことになった場合の修正範囲は3倍に膨れ上がります。
勿論、そんな関数を作っている場合は大抵その処理がメソッドに密接に絡み合っているので、
3倍どころでは済まなくなるでしょう。

それで、いつからカレーを作ることに…? たしかサンマを買うはずだったのですが…

774 :仕様書無しさん:2015/07/05(日) 14:54:20.57
おまいらそんな事よりギリシャ助ける方法考えてやれよ

775 :仕様書無しさん:2015/07/05(日) 14:56:51.82
因みに、僕は一般的には引数はDTOオブジェクト1つです。
列挙型の場合、引き数が増えたり減ったりすると、修正が面倒ですから。

776 :仕様書無しさん:2015/07/05(日) 14:57:20.05
>>774
それはお任せします。

777 :仕様書無しさん:2015/07/05(日) 14:57:29.28
>>770
だからそういう汎用関数はあるんだって前提だろ。

その関数の一連の流れをどうするかって話、頭悪いなぁ

778 :仕様書無しさん:2015/07/05(日) 15:00:15.68
はたから見ると、

>だからそういう汎用関数はあるんだって前提

なのに、

1. goToSuperMarketAndBuyCarrayPowderAndCarrotAndOnionAndBeaf();
2. returnToHomeAndMakeCurry();

こうなってしまうような例をあげる方が頭が悪いように見えます。

779 :仕様書無しさん:2015/07/05(日) 15:01:01.36
>>777
もしgoToとかbuyのような汎用関数がなくても、
goToSuperMarket()という関数作らずに
goTo(place)という関数にするかなぁ

780 :仕様書無しさん:2015/07/05(日) 15:01:15.74
お前ら休日だってのに、よくこんな低レベルな会話に付き合えるな…
頭悪すぎて解説してやる気が1ミリも起きないんだが

781 :仕様書無しさん:2015/07/05(日) 15:02:48.88
>>778
だからそういうのを関数で外出しにしないでコードブロックとかでやれって話だっつってんだろ

782 :仕様書無しさん:2015/07/05(日) 15:03:32.08
>>780

多分あなたもミイラになるだけなので、そのまま帰った方がいいですよ。
解説しても、多分誰も聞かないと思います。

783 :779:2015/07/05(日) 15:03:53.86
あ、ラッパーとしてgoToSuperMarket()を作ることはあるかもしれないけど
内部で goTo(SuperMarket);を呼び出すね。

784 :仕様書無しさん:2015/07/05(日) 15:04:44.35
goTo(SuperMarket)
.and().buy({
CurryPowder,
Carrot,
Onion,
Beef
})
.and().goTo(Home)
.and().make({
Curry
});

785 :仕様書無しさん:2015/07/05(日) 15:04:51.45
>>768
やっぱりぶち切れしそうな人ばっかりなんですけど…

786 :仕様書無しさん:2015/07/05(日) 15:05:03.98
>>774
働かない高給取りはマの敵だろ?

787 :仕様書無しさん:2015/07/05(日) 15:05:53.04
>>781
コードブロックで分けるにしても
1.車でスーパーに行ってカレー粉、にんじん、たまねぎ、肉を買う。
2.家に帰ってカレーを作る
というわけ方はちょっとない。

788 :仕様書無しさん:2015/07/05(日) 15:06:54.37
>>784

ワンライナー降臨

789 :仕様書無しさん:2015/07/05(日) 15:07:06.76
>>785
俺はチガウケド
プログラマは冷たい人多かも

790 :仕様書無しさん:2015/07/05(日) 15:07:24.42
>>786
無能な働き者は敵だけど、有能な怠け者は味方だよ。

791 :仕様書無しさん:2015/07/05(日) 15:07:44.71
>>787

はい、その通りです。

ですから僕も、例が悪い、何が言いたいのかよくわからないと申し上げました。

792 :仕様書無しさん:2015/07/05(日) 15:08:54.74
>>790
彼等が稼ぐなら良いのだけど…

793 :仕様書無しさん:2015/07/05(日) 15:11:29.92
>>787
じゃあ、1 と2を1つにしてAとしていいよ。
てか、なんでもいんだよ。
で、Bの流れを作る。肉じゃがでもなんでもいいよ。野生の豚を狩りに行って材料調達してもいいよ。

で、 A Bをカレー作るよ 肉じゃが作るよメソッドとして関数を作るのかどうかだよ。

794 :仕様書無しさん:2015/07/05(日) 15:14:22.19
今度はABに置き換えてきたか…
なんか、三村と田中のドリームマッチのコントじみてきたな…

795 :仕様書無しさん:2015/07/05(日) 15:18:24.67
>>793
関数作る派だね。
少なくともカレーを作るよ、肉じゃが作るよは外だしできるし
カレーを作るメソッドの中に車を運転する処理が入り込むことも予防できるし
少なくとも材料さえあればカレーを作れるのは保証できる。

796 :仕様書無しさん:2015/07/05(日) 15:30:15.53
>>795
問題点分かってなさそうなので消えて

797 :仕様書無しさん:2015/07/05(日) 15:30:29.57
なんか、何を言ってるのかよくわからなかったから
まともに読まなかったんだけど、

>データベースへの操作はinsert()。
>O/Rマッパーという用語だけは知っているようですから、
>モデルといいましょうか? モデルの操作はcreate()
>実際にモデルごとにcreate()ありますからね。

これは一体何だろう? まさか、DB操作する物がモデルだと思っているのだろうか?

冷静に>>754を読んでみても、本当に何を言いたいのか全く分からないな…

798 :仕様書無しさん:2015/07/05(日) 15:31:54.32
>>796

分かっていないと思う理由を説明できないなら、
消えるのは貴方の方だと思うんですけど。

消えるべきか判断できる材料を提示した方がいいんじゃないですか?

799 :仕様書無しさん:2015/07/05(日) 15:35:58.34
SmallTalkのお下がりを有難がって主張するマ

800 :仕様書無しさん:2015/07/05(日) 15:44:47.56
>>798
ある初期化処理でおおまかにステップ1から5までの手続きをします。

各ステップはその手続き内でしか行われません。

今、各ステップで使う変数などが同階層で定義されているので、スコープを定義し、コードを整理したいです。すべてのステップで共通の変数などもあります。

どのようにスコープを定義しますか。

801 :仕様書無しさん:2015/07/05(日) 15:51:04.55
>>800

どうも今一つ、おっしゃりたいことが分からないのですが、

恐らく、イニシャライズするクラスを作成して、
ステップ1〜5をファンクションに分け、
mainになるメソッドを定義して、そのmainメソッドの中で順次1〜5のファンクションを呼びます。

共通の変数はメンバ変数にするのではないでしょうか?

それがお二人が言い争っている事に関係しますか?

802 :仕様書無しさん:2015/07/05(日) 15:51:16.00
>>800
関数内で関数を定義し、関数を変数に格納します。
そして最後に、関数を格納した変数を順番に呼び出します。

803 :仕様書無しさん:2015/07/05(日) 15:52:54.09
めんどくさいから548から読み返して

804 :仕様書無しさん:2015/07/05(日) 15:57:27.89
>>548読み返して見ましたが
>>803>>796>>800なら、
尚更何が言いたいのかさっぱりわからないですね。

自分の頭の中だけで生きてる変な人なのかな?

805 :仕様書無しさん:2015/07/05(日) 16:01:24.59
ちなみに、>>548は初めてみましたが、これは一側面でしか過ぎないですね。

関数分けするのは
再利用性、可読性、テストの単純化、メンテナンス性の向上、コードの記述時間の短縮、等々、

様々な理由で行われます。

806 :仕様書無しさん:2015/07/05(日) 16:06:16.17
おまいらにはトップダウンの思考しかないのか?

807 :仕様書無しさん:2015/07/05(日) 16:09:47.98
また意味の分からない事を言いだす人が現れたよ…

技術力が低い会社にありがちなことって、
まともな会話が出来ずに勝手に怒り狂って去っていくプログラマがいるってことじゃないかな…?

808 :仕様書無しさん:2015/07/05(日) 16:52:22.24
単純にコードは小さければいい最程良い。
一関数20行以下が普通。

809 :仕様書無しさん:2015/07/05(日) 16:57:43.13
そして究極に洗練されたコードともなると、
すべての関数が1行となるわけですな。

810 :仕様書無しさん:2015/07/05(日) 17:14:46.37
>>808

はい、その通りです。

>>809

寝言は寝てから言いましょう。

811 :仕様書無しさん:2015/07/05(日) 17:31:45.64
>>738
>変更理由が2つあるということは、責任(役割)も2つあるということ。

役割==functionだろ。
責任!=関数って、もはや自分で使ってる言葉の意味を理解してない...

812 :仕様書無しさん:2015/07/05(日) 17:31:47.18
おやまあ、なんという自己矛盾を抱えたレスですこと

813 :仕様書無しさん:2015/07/05(日) 17:33:17.77
割り込まれてしまいましたが、>>812>>810宛てですよ

814 :仕様書無しさん:2015/07/05(日) 17:33:54.17
>>786
ギリシャにだって幼女はいるんですよ?

815 :仕様書無しさん:2015/07/05(日) 17:34:33.79
関数って用語が気持ちが悪い

技術力が低い=英語力が低い

英語の書籍やマニュアルを読まない(読めない)

読むのは奇天烈な翻訳本ばかり

関数w

816 :仕様書無しさん:2015/07/05(日) 17:36:10.64
>>814
「俺の嫁がギリシャ人美少女なわけがない」

817 :仕様書無しさん:2015/07/05(日) 17:36:36.38
>>809
それをキリスト教的に言うと
光あれ
なんだろうね。

818 :仕様書無しさん:2015/07/05(日) 17:40:20.57
>>815
関数は日本語化された用語としてプログラマなら誰でも使うものだが

責任って用語の方がよっぽど気持ち悪いと思われてる

819 :仕様書無しさん:2015/07/05(日) 17:44:48.94
>>811
役割はroleだろ?
何を言ってるんだ?

820 :仕様書無しさん:2015/07/05(日) 17:45:28.74
funcitonなら機能だよなぁ。

821 :仕様書無しさん:2015/07/05(日) 17:48:05.50
気持ち悪いと思われようが、
SOLIDの原則のSはSingle responsibilityであり
responsibilityを日本語に直せば、責任、責務といった意味になる。

822 :仕様書無しさん:2015/07/05(日) 17:50:12.13
>>813

そう思っているの、貴方だけみたいです。

823 :仕様書無しさん:2015/07/05(日) 17:51:34.97
>>818
「責任」なんて全然気持ち悪くないよ
be responsible forって英語がプログラミングの話題に頻出であることを知らない人にとったら違和感あるかも知れんけどw

824 :仕様書無しさん:2015/07/05(日) 17:52:09.39
>>811
> 役割==functionだろ。

プークスクスw

お前の役割は道化師なんだから、
道化師としての責任を果たしなさいw

825 :仕様書無しさん:2015/07/05(日) 17:54:40.07
>>821

そういう、直訳がどうだとか言いだす人、単純に頭が固いと思います。

826 :仕様書無しさん:2015/07/05(日) 17:56:07.27
>>825
え? 直訳がダメだったらなんなの?
誤訳が正しいというつもり?w

827 :仕様書無しさん:2015/07/05(日) 17:56:55.90
>>826

普通の人は意訳じゃないですか?

828 :仕様書無しさん:2015/07/05(日) 17:57:15.31
>>825

お前のfunctionは道化師だぞ。
ちゃんとわかってるなw

829 :仕様書無しさん:2015/07/05(日) 17:57:46.29
>>827
役割=functionは
どう考えても誤訳だって言ってるんだが?

830 :仕様書無しさん:2015/07/05(日) 17:57:53.53
如何にも0か1かのプログラマーらしいレスで、ちょっと吹き出しました。

831 :仕様書無しさん:2015/07/05(日) 17:59:22.08
>>829

実際の挙動を考えると、そんなに間違っているようにも思えませんが。

832 :仕様書無しさん:2015/07/05(日) 17:59:23.06
0か1じゃない、間を取って0.2もある。
ということで、23452345が正解だ!
みたいな意味不明な話するなよ。

みんな明らかに誤訳だっていってんの

833 :仕様書無しさん:2015/07/05(日) 18:00:28.07
>>821>>826>>829
責任なんて用語単体では、文脈上の補足もなしではあまり通じない
一方functionの場合はそのへん考えられており、日本語で機能と訳すとややこしいから関数と訳すように慣習化されてる

834 :仕様書無しさん:2015/07/05(日) 18:00:30.92
>>832


明らかに誤訳だと思う理由は何でしょう?
みんなとはここで急にわいてきたレスの方(々)のことでしょうか?

835 :仕様書無しさん:2015/07/05(日) 18:02:56.38
>>823
この業界で一般的に使われてるのは「責務」ですね
責任でもわからないことはないけど

836 :仕様書無しさん:2015/07/05(日) 18:03:21.95
僕も>>833と同じような考え方ですので、
明らかに誤訳だと思うのならその理由を知りたいですね。

837 :仕様書無しさん:2015/07/05(日) 18:03:54.56
>>831
いや、完全に間違い。

責任(responsibility)と
関数(function)はぜんぜん違う概念。

初心者がよくやる間違いで、
責任で分けないで関数で分けてしまうというものが有る。

関数でモジュールを分けてしまうと、例えば全ての
insertXXXを集めたinsert関数専用モジュールが出来てしまう。

そうすると全く無関係であるはずの、商品スキーマを変えた時と
顧客スキーマーをかいえた時、の両方で同じモジュールを
修正することになってしまう。

同じことがupdate関数専用モジュール、delete関数専用モジュールにも
当てはまり、ある感心事に関するコードがあちらこちらに散らばってしまう。
これは責任と関数の区別がついていないから。

838 :仕様書無しさん:2015/07/05(日) 18:05:13.80
>>835
ぐぐったけど、
単一責任の原則って言葉はよく聞くが、
単一責務の原則という訳は少ないよ。

839 :仕様書無しさん:2015/07/05(日) 18:05:49.70
>>836
> 明らかに誤訳だと思うのならその理由を知りたいですね。

翻訳のプロにでも頼んだら?

役割は関数ですよね!って

840 :仕様書無しさん:2015/07/05(日) 18:06:33.64
functionが関数と訳されてるのは、明らかに数学から持ってきたものでしょ。
ここにいる人たちは
y = f(x)
とか見たことないの?

841 :仕様書無しさん:2015/07/05(日) 18:07:40.03
>>837

おっしゃっていることは分からなくもないんですが、
それが、責任と関数の区別の違いからくるものだとは思えないですが…

なんか話がすり替わっているような…

842 :仕様書無しさん:2015/07/05(日) 18:07:45.58
>>835
その話題俺も興味ある。
単一責務原則といわれるように責務という言葉は使われるけども
関数を設計するときに責任という言葉はあまり使われない。

責務は責任をもって果たさなければならない「仕事」に焦点を
あてているのに対して責任は責めを負ってなされなければ
ならない「状況」に焦点をあてているのだ。と考えたのだけどどう思う?

843 :仕様書無しさん:2015/07/05(日) 18:09:21.42
>>839

あなたに翻訳者が必要で、

>functionは関数ですよね!

でないと意味が通らないです。

844 :仕様書無しさん:2015/07/05(日) 18:09:57.81
ウィキペディアに載ってないことはわかんないんだよ。
分かってやれよ。

845 :仕様書無しさん:2015/07/05(日) 18:11:25.39
どちらかというと役割はクラスの方じゃないかな。
関数は責務。任意の数の責務をあるまとまりで
くくったものが役割。

接続オブジェクトは接続するものとしての役割を演じるために
接続する責務と切断する責務を持つ。みたいな。

846 :仕様書無しさん:2015/07/05(日) 18:12:30.01
ていうか、誰かが責任だとか言い出したからこんな事になってるっぽいですけど、

そういう話でしたっけ?

読み返してみても、そこは話の焦点ではないように思うんですけど…

847 :仕様書無しさん:2015/07/05(日) 18:15:49.04
そりゃまぁ、役割を分担する者は、責任を持ちますよねぇ、普通は…

848 :仕様書無しさん:2015/07/05(日) 18:16:24.94
>>846
話は広がりを持ってなんぼのもんでしょうが!!
そういえば話の展開の仕方って分類としてはいくつくらいあるんだろうな。
順接・逆説・敷衍・演繹・虎牙破斬とか思いつくだけでもいろいろありそうだけど
それをちゃんと分類したものってあるのかね。

849 :仕様書無しさん:2015/07/05(日) 18:17:40.35
あー、もしかして、特定派遣とかで派遣されている人ばっかりだから、
自分は過失責任のみです、他は知りませんって言って
役割だけ引き受けて責任を放棄する人ばっかりってことなのかな?

850 :仕様書無しさん:2015/07/05(日) 18:18:39.99
>>848

広がることは一向に構わないんですが、ただ逸れて行っているだけのような…

851 :仕様書無しさん:2015/07/05(日) 18:21:15.52
>>850
まあね。話がハッサンしてしまって真面目系モヒカン頭に図らずもなってしまうことってあるよ。
よしじゃあ話を戻そう。あとは頼む。

852 :仕様書無しさん:2015/07/05(日) 18:23:07.73
真面目系はモヒカン頭にしないと思うんですが?
誤訳じゃないですか?

853 :仕様書無しさん:2015/07/05(日) 18:23:14.18
僕たちが永遠に奴隷な理由が良くわかるスレ

854 :仕様書無しさん:2015/07/05(日) 18:23:46.90
戻すとなるとまぁ、

----------------------------------------------------
715 :仕様書無しさん:2015/07/05(日) 11:41:39.52
>>714
ちょっと問題見誤ってるよ。
これは抽象化じゃなくて、手続きの分け方だよ。

1.車でスーパーに行ってカレー粉、にんじん、たまねぎ、肉を買う。
2.家に帰ってカレーを作る

こうゆう汎用的ではない一連の行動を関数で分けるのか1つにして、コードブロックやコメントで分けるのかといった問題。
----------------------------------------------------

これ、どうなの?って話になるのかな…

855 :仕様書無しさん:2015/07/05(日) 18:25:09.24
>>852
誤訳じゃない。これが証拠だ。
https://pbs.twimg.com/media/BuCs50AIIAApqt5.jpg

856 :仕様書無しさん:2015/07/05(日) 18:29:54.63
>>855
そんな服装の人を真面目系というのは無理がありますね。
あなたの真面目系の概念が一般と違うのではありませんか?

857 :仕様書無しさん:2015/07/05(日) 18:37:03.77
>>854
なぜスーパーに行って材料を買わなければならないのか。
それはお家の冷蔵庫に材料がないからだ。
お家の冷蔵庫に材料があったとするならスーパーに材料を
買いに行かなくてもカレーは作れる。
カレーを作ることとスーパーに行って材料を入手することは分けるべきだ。
たまたまお家の冷蔵庫に材料がなかったという偶然の産物をさも当然のように
考えてカレーを作るロジックにそれを組み込むなどとは硬直した設計としか言いようがない。
そういう柔軟性のなさはよろしくないと吾輩思う。

858 :仕様書無しさん:2015/07/05(日) 18:39:27.93
>>857

多分、話の流れは見えていらっしゃらないようですが、
多分正解です。

そのために、必要な関数を作って機能を分けておくんです。

859 :仕様書無しさん:2015/07/05(日) 18:40:32.52
つまりこう。

Sub Main()
 Dim Material = GetMaterial()
 CookCurry(Material)
End Sub

Function GetMaterial()
 ...
End Function

Sub CookCurry(Material material)
 ...
End Sub

860 :仕様書無しさん:2015/07/05(日) 18:47:00.41
関係ないけどsubは嫌い
モジュールも嫌い

関数が成功したかどうか、または
関数の出力をリターンしろと思う

861 :仕様書無しさん:2015/07/05(日) 18:51:18.58
VB厨が現れたぞ

862 :仕様書無しさん:2015/07/05(日) 18:53:27.22
>>860
どこの老害老人だよ。
カレーを作るっていう関数なんだから
カレーを作れなかったら例外を投げてしかるべきだ。
ラーメン屋に行ってラーメン注文してラーメン作れないって
状況考えろよ。どう考えても例外だろうが。
CookCurryの中でカレーをデータベースに入れてるから
戻り値は必要ない。

863 :仕様書無しさん:2015/07/05(日) 18:54:45.84
>842
> 単一責務原則といわれるように責務という言葉は使われるけども
Google検索からすると逆でしたね。


"単一責任の原則"
約 3,400 件 (0.29 秒)

"単一責務の原則"
約 314 件 (0.24 秒)

864 :仕様書無しさん:2015/07/05(日) 18:59:14.80
>>863
googleで検索されるようなひ弱なページ書くやつって
知ったかぶりの自称情強だからな。俺のようなリアルインフォメーションストロンガーとは
認識の違いがあってもしかたがない。何度もいうが俺は銀行業務系のプログラマを10年以上
やってるんだ。google検索の冷たい検索結果と俺の熱いハートどっちが信頼できるかってことだ。

865 :仕様書無しさん:2015/07/05(日) 19:01:28.24
世の中で書かれたことって所詮誰かが
人間が言ったことでしか無いからな。

人間が言ってないことは書かれていない。
つまり書かれていないことにこそ真実があるのだよ。

俺の意見は書かれていない。だから俺の意見が正しい。
ググって見つけたものは全て間違いだ。
Wikipedに書いてあるものもみんな間違いだ。
確率的に正しいかもしれないという余地もない。

書いてあることは全て間違いだ。

866 :仕様書無しさん:2015/07/05(日) 19:04:44.64
>>865
それは言い過ぎだ。真実は極論の中ではなく中間くらいにあるもんだぞ。
もっとバランス力を持つべきだ。バランス力がこれからのIT業界生き抜いていくためのキーワードだ。

867 :仕様書無しさん:2015/07/05(日) 19:04:54.14
wikipediaとお前
どっちを信じるかと言ったら
wikipediaの方を信じるわw

868 :仕様書無しさん:2015/07/05(日) 19:06:10.02
>>864>>865
俺はお前らの熱いハートを信頼するぜブラザー

869 :仕様書無しさん:2015/07/05(日) 19:06:53.14
wikipediaに地球は太陽の周りを回っていると
書いてあっても、そうではない。

なぜならwikipediaに書いてあることが全て正しいとは
限らないからだ。

正しくない可能性があるのなら、
それは間違いである。
間違いであることの証明も不要。

俺が間違いだと言ったら
wikipediaになんて書いてあっても間違いだ。

870 :仕様書無しさん:2015/07/05(日) 19:10:23.88
熱いハートってwせいぜい火照ったハートくらいだろw

871 :仕様書無しさん:2015/07/05(日) 19:12:48.60
>>869
やっぱりお前は信頼しないぜ
レスが対話形式で進まない奴は信頼しないことにしてるぜ

872 :仕様書無しさん:2015/07/05(日) 19:18:36.13
>>870
薄い本読んだら精液かかって「熱い!」とリアクションすることがあるだろうが。
「生ぬるい!」と正直に現実的な感想言っても読者の心は揺さぶれないだろうが。
俺の熱いハートっていうのはそういう意味だ。精液と同じ扱いでいいと言ってるわけじゃないぞ。
そういう思いが詰まった熱いハートだってことだ。

873 :仕様書無しさん:2015/07/05(日) 19:18:40.95
迷探偵コカン
真実はいつも迷宮入り!


コカン「刑事さん、実はその人は犯人じゃない」
刑事「なんだって?それでは一体誰が?」

コカン「考えてもみなさい。刑事さんが犯人だと言ってあたったことがあるかね?
当たらないことだってある。真実とはもっとあやふやなものだ。
よって犯人は他にいる。これが私の推理だよ」

刑事「えと、それで誰が犯人なんでしょう?」
コカン「真実はいつも迷宮入り!」

874 :仕様書無しさん:2015/07/05(日) 19:25:16.10
>>872
いやだからw
お前はそこまで強い気持ちを持ってないだろ?って言ってんだよ。
何で比喩の説明してんだよw

875 :仕様書無しさん:2015/07/05(日) 19:30:28.86
>>874
なんでそんなこと言うんですかぁ?(癒し系)

876 :仕様書無しさん:2015/07/05(日) 19:33:13.15
口で

877 :仕様書無しさん:2015/07/05(日) 19:36:18.67
>>874
精液は熱いよ!!

878 :仕様書無しさん:2015/07/05(日) 19:37:04.08
つーか役割=functionは無いだろw

879 :仕様書無しさん:2015/07/05(日) 19:37:56.10
>>876
黙れクソビッチ。

>>877
黙れスペルマ野郎。

さてじゃあそろそろこの週末の議論をまとめようと思うが
関数を統一することによってプログラムの複雑度が下がり
テスタビリティを高めることができるから関数を分割するべきではない。
ってことでいいな。

880 :仕様書無しさん:2015/07/05(日) 19:41:29.60
このようにすべての議論で負けた奴は
誰かも支持されてないことを
無理やり貫き通そうとする癖がある

そういう人のために、このAAがある

881 :仕様書無しさん:2015/07/05(日) 19:43:08.25
単一責任の原則という言葉を知ることが出来たのは
収穫だったな。

882 :仕様書無しさん:2015/07/05(日) 19:44:12.71
>>878
functionというキーワードを考えればJavaScriptのことを
述べているのは明白だ。JavaScriptではfunctionは第一級オブジェクトだ。
焼酎で言うなら獺祭レベルだ。役割=functionも十分成り立つだろ。

883 :仕様書無しさん:2015/07/05(日) 19:45:42.77
SOLIDの原則も忘れないでね!

http://www.infoq.com/jp/news/2013/09/solid-principles-revisited

SOLIDとは5つの設計原則の頭字語である。氏の簡潔な説明を借りれば:

・単一責務の原則(Single Responsibility Principle)
すべてのオブジェクトは唯一の責務を持たなければならない。
すなわち,実行することはただひとつでなければならない。

・開放/閉鎖の原則(Open-Closed Principle)
クラスは拡張に対しては開いて(Open),修正に対しては
閉じて(Close)いなければならない。

・Liskovの置換原則(Liskov Substitution Principle)
派生クラスは親クラスの置換として使用可能でなければならない。
なおかつ,同じ振る舞いをしなければならない。

・インターフェイス分離の原則(Interface Segregation Principle)
使用しないインターフェースへの依存をクライアントに強制してはならない。

・依存関係逆転の原則(Dependency Inversion Principle)
具体的な実装よりも抽象に依存するべきである。これはコードの分離に有効だ。

884 :仕様書無しさん:2015/07/05(日) 19:46:29.31
>>>882
> functionというキーワードを考えればJavaScriptのことを
> 述べているのは明白だ。

それはfunctionという言葉で
JavaScriptしか思いつかない
君の話?

885 :仕様書無しさん:2015/07/05(日) 19:50:38.38
>>883
氏って誰よ?
それ考えた人か?偉いんか?

886 :仕様書無しさん:2015/07/05(日) 19:51:02.07
>>884
俺の話であり議論している人間すべてにかかわる話でもある。
JavaScriptは今一番メジャな言語であり誰もが予想することができる。
だからこそJavaScriptという名称を省略することができた。
他のマイナな言語が念頭にあるなら他の人間はそれを予想することが
できないことが予想されるべきで当然そうであるならばその言語名を
併記したことだろう。それがなかったという事実がJavaScriptを示している。

887 :仕様書無しさん:2015/07/05(日) 19:54:47.85
>>885
書いた人間の立場より書いてあることの中身の方が大事だろ。
権威に従ってプログラム書くより自らの経験でベストプラクティスにたどり着くべきだ。
そのとっかかりとしてこういう考え方があるっていうのは大事だと思うぞ。

888 :仕様書無しさん:2015/07/05(日) 19:54:58.83
あぁ、今度は話をJavaScirptにすり替えようとしてるのね。
あからさま過ぎてワロタw

889 :仕様書無しさん:2015/07/05(日) 19:56:46.19
>>885
お前よりは確実に偉いんで、
いくらここで反論しても
説得力無いだろうなw

890 :仕様書無しさん:2015/07/05(日) 19:58:43.22
>>888
JavaScriptじゃあよほど都合が悪いようだな。
JavaScript以外の言語を知っている自らの知識をひけらかす機会を奪われて悔しいか。
お前の悔しさが俺には心地いい。ご飯が進むわ。あと牛乳も。

891 :仕様書無しさん:2015/07/05(日) 20:00:46.75
>>889
まあ待て >>885 がビル・ゲイツである可能性もゼロではないだろ。
ビルはフットワークが軽いからな。こんなところに!?なんてことも十分考えられるだろ。
慎重にレスしていこう(提案)

892 :仕様書無しさん:2015/07/05(日) 20:00:59.12
>>887
では、どこの馬の骨かわかんないやつが書いたブログの造語借りてきて、
ここで偉そうに講釈垂れようと思いますがいいですか?

893 :仕様書無しさん:2015/07/05(日) 20:01:03.98
今はSOLID原則の話なw

894 :仕様書無しさん:2015/07/05(日) 20:01:52.31
>>892
どこの馬の骨かわかんないやつが書いたブログでも、
その言葉自体が有名な人が言っている言葉であれば
問題ないよ。どうぞ。

895 :仕様書無しさん:2015/07/05(日) 20:04:43.03
>>892
良いと思うぞ。SOLID原則は業界では割合浸透してる言葉だから
説得力もあるが全然浸透してない言葉借りてきても説得力持たせるのが難しい。
そこはプレゼン力が問われるところだな。やってみるだけの価値はあると思うぞ。

896 :仕様書無しさん:2015/07/05(日) 20:08:20.44
wikipediaにのってることは、間違いもあるから
全て間違いである。という言葉で説得できなかったんだが?

897 :仕様書無しさん:2015/07/05(日) 20:10:47.02
>>894-895
いえ、もちろんその馬の骨しか使っていない「造語」です。

書いた人間の立場より書いてあることの中身の方が大事だからいいっすよね?
"SOLID原則"でググっても7,240 件 しか出てこないし、書いた人は誰かわからない同じ馬の骨仲間っすもんね。

898 :仕様書無しさん:2015/07/05(日) 20:14:40.78
>>897
聞くひまあるならさっさとやれや。ぐずってんじゃねえぞおら。

899 :仕様書無しさん:2015/07/05(日) 20:15:00.95
> "SOLID原則"でググっても7,240 件 しか出てこないし

多いじゃないか?

900 :仕様書無しさん:2015/07/05(日) 20:16:06.86
> "SOLID原則"でググっても7,240 件 しか出てこないし、
間違えました

SOLID原則
約 384,000 件 (0.27 秒)
https://www.google.com/webhp?espv=2&ie=UTF-8#q=SOLID%E5%8E%9F%E5%89%87

でした。

901 :仕様書無しさん:2015/07/05(日) 20:18:48.65
日本語のwikipediaにないから、そんな用語はないって
思っちゃってるんでしょ?w
https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

902 :仕様書無しさん:2015/07/05(日) 20:22:17.10
>>900
そりゃ、そういう検索の仕方だと
全然別の意味のSOLIDと原則というキーワードでヒットしたのがほとんどだからね。

>>901
Wikipediaなど結構マイナーな流行語だって載ってるわな。
それでも日本語のwikipediaには無いみたいだが。

903 :仕様書無しさん:2015/07/05(日) 20:25:25.30
> 全然別の意味のSOLIDと原則というキーワードでヒットしたのがほとんどだからね。

全然関係ない言葉が見つからないんだが?

904 :仕様書無しさん:2015/07/05(日) 20:28:11.32
>>903
せめて検索結果の10ページ目以降ぐらいから見てみよう

905 :903:2015/07/05(日) 20:28:16.54
嘘だと思うなら羅列しようか? 1件も飛ばさずに書いたよ

オブジェクト指向設計原則 - Strategic Choice - はてなダイアリ
C# で SOLID の原則に違反する危険性
.NETにおけるSOLID設計原則とデザインパターン - InfoQ
【書評】C#実践開発手法 ?デザインパターンとSOLID原則に
Amazon.co.jp: C#実践開発手法 (マイクロソフト公式解説
オブジェクト指向設計の原則がよく分かるかも知れない画像 - 涙 ..
SOLID (object-oriented design) - Wikipedia, the free ...
SOLIDの原則: Part1 - 単一責任の原則(Single Responsibility
一生涯プログラマ : オブジェクト指向プログラミングデザインル
何かのときにすっと出したい、プログラミングに関する法則・原
C#実践開発手法〜デザインパターンとSOLID原則による ...
C#実践開発手法 デザインパターンとSOLID原則 ... - 日経ストア
SOLID原則 | Eglab | 開発者ブログ
TypeScript実践プログラミング - Google ブック検索結果
【書評】C#実践開発手法 デザインパターンとSOLID原則によ
C#実践開発手法 デザインパターンとSOLID原則による ... - HMV
C#実践開発手法 デザインパターンとSOLID原則による ...
C#実践開発手法 デザインパターンとSOLID原則による ...
依存性反転の原則について : アシアルブログ
SOLID原則を突き詰めれば、関数型プログラミングがかなり魅
転送コム | C#実践開発手法 〜デザインパターンとSOLID原則 ...
コード書けないSE様にSOLID設計原則を聞いてみた - 2ちゃんね
組み込みアジャイルコーチ James Grenning さんインタビュー .
『C#実践開発手法』を監訳 - Re:WorkStyle
コード SOLID 原則の2chスレ1件 | 2ch検索
Kenji Hiranabe on Twitter: "これはいい資料。SOLID原則の ...
SOLID CSS - en.ja Article
要求の変化に適応できる現場 - Build Insider
FRP with オブジェクト指向他 - Learn Reactive Extensions
C#実践開発手法 - 楽天ブックス - 楽天市場

906 :仕様書無しさん:2015/07/05(日) 20:28:27.92
ググる事も満足に出来ないプログラマーって冗談だろ?

907 :仕様書無しさん:2015/07/05(日) 20:30:28.96
6ページまで

C#実践開発手法 - 楽天ブックス - 楽天市場
PHP製タスク指向Webフレームワーク/CharcoalPHP
物件導向程式設計五大原則:SOLID ≪ Hitripod
JP IT Tech: JavaScriptのためのSOLID設計原則
SOLID, オブジェクト指向設計の原則, Pattern Oriented Software
C# 洋書ブックガイド | OPC Diary
大江戸Ruby会議01で発表してきました - UKSTUDIO
パターン、原則などのメモ - miso_soup3 Blog
SOLID原則 - Rock 的系統開發雜記 - Blogger
『「メソッドに対してテストをするな」という話題について』
みくみくまうすについて&Unity で使えるコーディングノウハウ (
07 | 5月 | 2015 | kekyoの丼
C#実践開発手法 / ホール,ゲーリー・マクリーン【著】〈Hall
C#実践開発手法 〜デザインパターンとSOLID原則による ...
程序員該有的藝術氣質?SOLID原則-民初思韻網
Cソースで守ってほしいこと。 | tocsworld
SOLID原則 - オークションとネットショップの価格比較 Aucomp!!
"SOLID原則… SIMPLE OLD LIE INS..." from チューリング ...
書籍『C#実践開発手法』を監訳しました。まもなく発売!:IT
『C#実践開発手法』レビュー - プログラミング C# - 翔ソフトウェ
アジャイルソフトウェア開発の奥義を読んだ - 転職した
solidの求人 - 東京都千代田区 | careerjet.jp
O'Reilly Japan - テスト駆動開発による組み込みプログラミング
良い設計の指針 (SOLID 原則) と対照的な悪い設計の頭文字を .
PHPカンファレンス2013 モデルとの向き合い方:ドメイン駆動
DDDのリポジトリの外部依存とオブジェクト指向の原則の適用
【書評】C#実践開発手法 ?デザインパターンとSOLID原則による
TDDの暗黒面
大江戸Ruby会議 - SlideShare
テスト駆動開発は設計技法である〜組み込みアジャイルコーチ ...

908 :仕様書無しさん:2015/07/05(日) 20:32:55.33
>>883
お前はこぴぺしかできないのか?
自分の頭で考えることあんの?

909 :仕様書無しさん:2015/07/05(日) 20:33:54.69
>>712
50行に縛られてる時点でダメなコーディングと言ってるんだよ

910 :仕様書無しさん:2015/07/05(日) 20:34:12.15
>>905>>907
人の話聞いてます?それとも荒らし?
最初の方ではそりゃ一致度は高いでしょう。
しかし384,000 件のうち後半のほとんどは別の意味でヒットしてます。(検索の仕組みわかってますか?)
せめて10ページ目以降から見ろといったのはそういう意味です。

911 :仕様書無しさん:2015/07/05(日) 20:34:20.34
>>904 10ページからだね? 確かに30件中5件ぐらい無関係なのがあったよ。

六大設計原則快速記憶SOLID _人人IT網 - 人人IT网
SOLID 設計原則In C# 代碼實現- 數碼維基
原則 - 日本辞典
単一責任の原則(SRP)-StrategicChoice - Newvo
SOLID BASS ポータブルヘッドホン ブラック ATH-WS55X BK
SOLID BASS Bluetooth ワイヤレスステレオヘッドセット ATH ...
SOLID BASS iPod iPhone iPad専用インナーイヤーヘッドホン ...
Webアプリケーションエンジニア(加盟店向けシステム) 日本 ..
エイ出版の通販サイト【パーク】 - 日本最大級の通販サイト(商
Strategic Choice
Test Driven Development for Embedded C 読書会 第6回 ...
{$smarty.session.myApp.title}
C言語とオブジェクト指向で学ぶアジャイルな設計 - 九州大学
NET Interview Prep Lite - AndroWire
bluewidz nota: 2014-12
「アダプティブコード」でビジネスのリズムにソフトウエア開
C#実践開発手法 デザインパターンとSOLID原則による ...
Solid Organ Transplantに伴う不明熱FUO - 感染症診療の原則
日経BP社商品一覧 1ページ目・リリース順順 BOOK WALKER ...
SBヒューマンキャピタル株式会社(転職エージェント)・Web
コード書けないSE様にSOLID設計原則を聞いてみた ... - トップ
システムエンジニア(アプリ設計/WEB・オープン・モバイル
【Webアプリケーションエンジニア/株式会社ぐるなび(正社員
正社員 / 東京都千代田区有楽町
タグ「development」を検索 - はてなブックマーク
Yuya Saito: SOLID CSSを紹介したので、SOLID JavaScriptも
オブジェクト指向のSOLID | s_imanishi (input, memo, think);
C# のベスト プラクティス - C# で SOLID の原則に違反する危
SOLID CABLES Elph Speaker Cables 2SP Combo - デジマー
SOLIDの原則: Part1 - 単一責任の原則(Single Responsibility...

912 :仕様書無しさん:2015/07/05(日) 20:36:14.42
>>765
プログラム書いたことマジでないだろ

913 :仕様書無しさん:2015/07/05(日) 20:38:23.96
>>911
な?無関係なの出てきただろ。
その調子で進んでいくと、どんどん無関係なのの割合が増えてくる。

それともう一つわかってますか?
意地になってベタベタとそういうアホなことやってるから馬鹿にされるんだぞ。

914 :仕様書無しさん:2015/07/05(日) 20:40:19.69
視野を広く持とうぜ。
SOLIDの原則なんて
我が社では使われていない。

書籍で書かれていたからといって
我が社で使われていなければ
世の中の一部でしか知られていない用語ってことだ。

世界レベルの視野の広さを持とう
我が社が世界の全てである。

915 :仕様書無しさん:2015/07/05(日) 20:40:46.45
>>913
でも関係有るのが大半ですよ?

916 :仕様書無しさん:2015/07/05(日) 20:41:38.07
で、Googleの検索結果からもあきらかなように
SOLIDの原則を知らない奴はモグリだってことだよ。

917 :仕様書無しさん:2015/07/05(日) 20:43:57.59
SOLID原則知らなかったやつがプライド傷ついて
粘着してるだけのようにしか思えぬな。
この業界で長年仕事していてSOLID原則を知らないっていうのは
考えにくいから新人かな。職場で甘やかされているプライドの高い
新人が知らない用語を使われて発狂したってとこだろ。

918 :仕様書無しさん:2015/07/05(日) 20:45:54.24
>>914
リアルで自分の会社の用語しか
知らない奴がいるからなw

919 :仕様書無しさん:2015/07/05(日) 20:49:07.91
>>915
だからもっとずっと後ろ見てけ。大半は関係ないわ。
意地になってコピペ荒らしの粘着すんなよw

920 :仕様書無しさん:2015/07/05(日) 20:49:59.89
>>919
よくわからん。それでお前が言いたいことは何なんだ?
Google検索して7000件も見つからるほど
有名な用語なんだが?

921 :仕様書無しさん:2015/07/05(日) 20:51:54.89
コンピュータサイエンスの臭いがする。

922 :仕様書無しさん:2015/07/05(日) 20:52:20.04
7000件という結果が多いのか少ないのか。
それが問題だ。

923 :仕様書無しさん:2015/07/05(日) 20:55:21.21
知らないことがあったらそれを自分の中に取り込んで自分の
世界を広げる努力をしないとな。自分の小さな世界を守るだけで
満足したら技術者として終わりだろ。常識的に考えて。

924 :仕様書無しさん:2015/07/05(日) 20:55:28.62
設計用語一覧集みたいなのがあった。
みんなどれだけ知ってる?

http://d.hatena.ne.jp/asakichy/20100203/1265158263

DRY原則
YAGNI
KISS原則
OAOO
Unix思想(Unix思想 簡易版)
UNIX哲学
可逆性
曳光弾
直交性

(一部抜粋)

925 :仕様書無しさん:2015/07/05(日) 20:55:51.22
>>920
> よくわからん。それでお前が言いたいことは何なんだ?

とりあえず、googleの検索結果をひたすらコピペするという荒らし行為の意味が聞きたいわ

926 :仕様書無しさん:2015/07/05(日) 20:59:01.38
>>925
どうせ検索しろって言ってもしないだろうから検索結果を貼り付けて
SOLID原則がよく知られた用語だと証明しただけ。

質問に答えたよ。次は君ね?

927 :仕様書無しさん:2015/07/05(日) 21:02:29.06
へー、こんなのもあるんだ。

http://d.hatena.ne.jp/asakichy/20090703/1246589874

SLAP(Single Level of Abstraction Principle)

抽象化レベル統一の原則
どういうこと?

同じメソッドに属するコードの抽象化レベルをすべて統一する。
たとえば?

同じメソッドの中で、ある部分では低水準のデータベース接続を扱い、
他の部分では高水準のビジネスロジックを扱い、
またある所ではWebサービスのインフラに対応している、
ということをしてはいけない。
^^^^^^^^^^^^^^^^^^^^^^^

928 :仕様書無しさん:2015/07/05(日) 21:02:51.97
>>926
7,240件は出てきたと言ってるのに、
わざわざそれを1件1件貼り付けたことに対する犯行動機は?

929 :仕様書無しさん:2015/07/05(日) 21:05:40.52
>>928
質問に答えるのは次はお前だってw

930 :仕様書無しさん:2015/07/05(日) 21:10:06.25
犯行動機については口を閉ざしている模様と…

931 :仕様書無しさん:2015/07/05(日) 21:10:48.15
>>927
これくらいは良いだろ別に。
神経質な奴もいるんだな。

932 :仕様書無しさん:2015/07/05(日) 21:14:38.29
>>927みたいなのは無意識のレベルでやるもんだよな
敢えて言葉にすると何か変な感じだけど

933 :仕様書無しさん:2015/07/05(日) 21:22:59.18
世の中いろんな考え方があるが、
自分の好みのマイナー論を拾ってきては、それを常識のように強要するマネージャがいると、
プロジェクト進行がやりにくいことこの上ない。そんな経験ない?

934 :仕様書無しさん:2015/07/05(日) 21:56:53.39
プロジェクトを完遂したいわけじゃなくて
コンサルタントを売り込みたいだけだからな。

935 :仕様書無しさん:2015/07/05(日) 22:00:17.23
経営陣がなんとか先生を呼んで来て
なんとか先生勉強会とか開いて
なんの成果も出せずに
いつの間にかフェードアウトしてる
あの無駄金で誰も責任取らない経営陣

936 :仕様書無しさん:2015/07/05(日) 22:02:12.51
>>927
まぁ一般的に避けるよね。
なんでだろうな。レベルが違うものが入り交じってると
頭を切り替えるのにエネルギー使うからかな。

937 :仕様書無しさん:2015/07/05(日) 22:11:22.13
なんでだろうな、じゃないよ。
当たり前過ぎて論じる価値も無いこと。

938 :仕様書無しさん:2015/07/05(日) 22:27:14.88
>>935
経営陣の仕事は業績改善することだ。
実際に業績改善できたらうれしいが、そんなの不確定で給料への影響も知れてる絵に描いた餅だ。

だが直近の問題として、対策予算消化したり改善提案出してるフリはしてなきゃいけない。
そういうわけで無駄金だろうがなんだろうが、先生呼んだりいろいろやってる理由はある。

939 :仕様書無しさん:2015/07/05(日) 23:39:20.61
>>872
温かい…だろ。精液を熱いとかいう本見たことねーよ。

940 :仕様書無しさん:2015/07/05(日) 23:51:31.61
>>939
それは まだ きみが けがれてないからだよ

941 :仕様書無しさん:2015/07/06(月) 06:46:37.21
>>927
なんか方向性が間違ってるなこれ
関数を小さく作ればそもそもこういう原則とか必要ないだろ

942 :仕様書無しさん:2015/07/06(月) 06:52:04.02
>>941
必要ないっていうのは関数を小さくすれば自然と抽象度が同じになるから?
それとも関数を小さくすれば抽象度なんて気にしなくていいから?

俺は後者だな。

943 :仕様書無しさん:2015/07/06(月) 06:57:16.23
関数を小さく作ればすべて解決します教かよ

944 :仕様書無しさん:2015/07/06(月) 06:59:09.13
>>943
嘘だと思うでしょう。それがホントなんですよ。ここだけの話。
構造が洗練されてないと関数を小さくすることって難しいんですよ。
関数を小さくすることを意識してると自ずと構造が洗練されてくるんです。
騙されたと思ってやってごらんなさい。

945 :仕様書無しさん:2015/07/06(月) 07:03:25.65
ワオ、それはびっくりだね!
さっそくエクササイズだ
いまならスペシャルコースが半額で、3時間の無料レッスンDVDが付いてるよ

946 :仕様書無しさん:2015/07/06(月) 07:26:46.55
ステップデバッグしてるとあっちこっち飛んで目が回るだろうな

947 :仕様書無しさん:2015/07/06(月) 07:30:07.77
部品化と分割を混同してなんでもかんでも小さくすりゃいいと思ってるバカは
バグ生成機にしかならん

948 :仕様書無しさん:2015/07/06(月) 07:42:36.91
まあ確かに関数を分割するという考えが浮かんだところで既に負けっていうのはある。
関数分割なんてのは本来初心者が学ぶべき事で、習熟度が進んでくれば自然に
小さな部品から関数を組みたてる方向に考え方が変わっていく。

949 :仕様書無しさん:2015/07/06(月) 07:44:36.17
>>941 >>942
おまえら抽象度って分かってないだろw

950 :仕様書無しさん:2015/07/06(月) 07:53:52.32
関数は小さけりゃいいとか大きけりゃいいとか
そういうもんじゃない

951 :仕様書無しさん:2015/07/06(月) 07:59:58.15
>>949
抽象的なレスだな、言いた事があるならはっきり言おうよ。

952 :仕様書無しさん:2015/07/06(月) 09:15:10.13
>>941
いやw

抽象化レベル統一の原則が正しい関数のわけかたなんだよ。

>>565-566
にも書いてあることからもわかるように、
同じレベルで分けるから、あっちこっち見なくちゃいけなくなる。

抽象化レベルで分けると、見なくて良い関数ができるから
あっちこっち見なくて良くなる。

953 :仕様書無しさん:2015/07/06(月) 12:08:42.45
見通しのための関数作って得するのは、処理の内容を知ってる自分だけだね。
他人からすれば謎関数にしかならない。

954 :仕様書無しさん:2015/07/06(月) 12:31:02.47
>>952
抽象化レベルで分けるってなんだよw
意味分かってないのバレバレだぞw

955 :仕様書無しさん:2015/07/06(月) 12:36:59.31
馬鹿が互いに相手を馬鹿と言い合っているだけで
何の議論にもなっていないし1ミリたりとも進展がない
まさに「技術力が低い会社にありがちなこと」だな

956 :仕様書無しさん:2015/07/06(月) 12:37:36.43
ちなみに>>927の原則に忠実に従ってコードを書くと
大量のラッパー関数を書くはめになる
はっきり言って馬鹿馬鹿しいことこの上ない

957 :仕様書無しさん:2015/07/06(月) 20:53:43.89
コード書かない奴の言うこととは信用するなの法則

958 :仕様書無しさん:2015/07/06(月) 21:06:18.00
形にこだわる奴に真のプログラミングは無理

959 :仕様書無しさん:2015/07/06(月) 21:50:24.73
理論云々言ってる奴に限ってコード書かせたら残念なことになる法則

960 :仕様書無しさん:2015/07/06(月) 21:52:09.61
>>954
>>927に書いてあるとおり

> 抽象化レベル統一の原則
>
> 同じメソッドに属するコードの抽象化レベルをすべて統一する。

これぐらいわかるだろう?
現に>>956は意味がわかっているようだ。


>>956
> 大量のラッパー関数を書くはめになる
ラッパー関数は一つもない。
抽象化レベルが違うのだから
それぞれ意味も違う。

961 :仕様書無しさん:2015/07/06(月) 21:53:23.33
>>959
> 理論云々言ってる奴に限ってコード書かせたら残念なことになる法則

優れたプログラマで理論を言わない奴はいないんだが?
逆は多いけどね。

ある原則に明確な理論で反論するならばよいが、
知らないのは単なる無知にすぎない。
理論に反論する以前の問題

962 :仕様書無しさん:2015/07/06(月) 21:57:24.02
ラッパー関数は抽象レベルが同じ時に発生する。

具体的には

標準のデータベースライブラリ使いにくいっw (←単に無知なだけ)
仕方ないな、俺が簡単に使えるデータベースライブラリを作ってやるよ。
標準ののデータベースライブラリではなく、俺が作った(ラップした)
ライブラリを使え。

と、このように抽象化レベルが同じ場合に
ラッパーになる。

963 :仕様書無しさん:2015/07/06(月) 22:00:07.62
>>961
真に優れたプログラマは、形や理論にこだわらない自由な発想の持ち主

964 :仕様書無しさん:2015/07/06(月) 22:01:42.84
>>963
具体的に誰のことですか?
想像の中の人?w

965 :仕様書無しさん:2015/07/06(月) 22:02:15.93
>>964
俺を含めたOSS仲間全員

966 :仕様書無しさん:2015/07/06(月) 22:02:35.07
Matzとか日本を代表するプログラマの一人だろうけど
作るものは理論の塊だからな。

967 :仕様書無しさん:2015/07/06(月) 22:03:09.64
>>965
具体的に名前は言えないんですね?w
理論にこだわってる人の名前ならいいましたよ?

968 :仕様書無しさん:2015/07/06(月) 22:05:16.35
>>967
こんなとこで言うわけないだろ
一部の有名人しか知らないなんて可哀想だな

969 :仕様書無しさん:2015/07/06(月) 22:06:49.97
>>968
自分のことでもないのになんで言えないんだよw
有名な人の名前を言えばいいんだよ?

無名な人の名前をいうよりも
簡単でしょう?

970 :仕様書無しさん:2015/07/06(月) 22:08:14.09
有名な人は全部理論派だから
いえないんじゃね?w

971 :仕様書無しさん:2015/07/06(月) 22:09:00.26
>>696
プログラマとしては名は通っていなくとも
優れた有名ソフトを公開してる人は山ほどいるだろう
見る目のない君には気付きもしないだろうけど

972 :仕様書無しさん:2015/07/06(月) 22:09:20.07
>>971
いるね。

それでその人の名前は?

973 :仕様書無しさん:2015/07/06(月) 22:09:57.73
別にハンドルネームでいいんだよ?

974 :仕様書無しさん:2015/07/06(月) 22:10:41.27
優れた有名ソフトを公開してる人で、
名前をハンドルネームすら明かしていない人。

条件に当てはまるものは、ずいぶんと縛られましたねw

975 :仕様書無しさん:2015/07/06(月) 22:10:47.83
>>972
こんなとこで言うわけないだろ
あることを知ってるなら誰か言ってみ

976 :仕様書無しさん:2015/07/06(月) 22:11:32.30
>>973
別にハンドルネームでもいいぞ

977 :仕様書無しさん:2015/07/06(月) 22:12:01.35
>>975
さーせん。頑張って探しましたが、
有名な人で理論はじゃない人は
見つからなかったです。

全員理論派でした。
もう、俺には、反論できないよ!

978 :仕様書無しさん:2015/07/06(月) 22:12:55.16
>>977
つまりただのミーハーで人を見る目はまったくないわけだな君は

979 :仕様書無しさん:2015/07/06(月) 22:13:03.80
プログラマで理論派じゃない人はいないようだ。
まあ当然か。

980 :仕様書無しさん:2015/07/06(月) 22:14:02.01
>>978
でも見つからないんですよ!
代わりにあなたが見つけれるんですか?
できないでしょう!!!

こまった。理論派じゃないことを
証明できる人が誰もいない!

困ったー!

981 :仕様書無しさん:2015/07/06(月) 22:14:18.42
>>979
真に優れたプログラマは理論で語らない、柔軟

982 :仕様書無しさん:2015/07/06(月) 22:15:10.00
>>962
たまたまお前がそういう関数を書いたことがあるってだけだろw
訳の分からん独自理論作るのやめれ恥ずかしいw

抽象度のレイヤーとラッパー関数とは全く関連性はない
所謂直交する概念()てやつなw

983 :仕様書無しさん:2015/07/06(月) 22:15:16.98
>>980
見つけられるもなにもOSSの仲間に大勢いる、有名ではないがな

984 :仕様書無しさん:2015/07/06(月) 22:15:33.20
>>981
まじですか!
その人の名前を教えて下さい。
知っていたらでいいんです!

知らないなら答えないでください!これは命令ですよ
あなたは私の命令に従うはずです。

985 :仕様書無しさん:2015/07/06(月) 22:15:59.33
>>984
こんなとこで言うわけないだろ

986 :仕様書無しさん:2015/07/06(月) 22:16:56.52
優れたプログラマって何が優れているのだろ。
設計か、実装か、パフォーマンスか、テストか、ドキュメントか、売上か、
利用者数か、名声か、おちんぽか。わからぬ。

987 :仕様書無しさん:2015/07/06(月) 22:17:14.44
理屈派は融通が利かないからプログラムもゴミしか作れない

988 :仕様書無しさん:2015/07/06(月) 22:18:09.92
>>982
ラッパーを抽象度のレイヤーと言い張っている可能性は?
ラッパーと抽象度のレイヤーを区別するのが独自理論である可能性は?
検討したか?

989 :仕様書無しさん:2015/07/06(月) 22:18:23.96
終わりそうなので立てときました。

技術力が低い会社にありがちなこと part 7 [転載禁止](c)2ch.net
http://kanae.2ch.net/test/read.cgi/prog/1436188667/

それでやっぱり名前を言わないんですね。
命令に従ってくれてありがとうございます!

990 :仕様書無しさん:2015/07/06(月) 22:18:45.25
>>986
わからないうちは優れたプログラマってやつを見たことがないんだろう
真のれべるになるとバケモノとしか言いようがないハイスキル

991 :仕様書無しさん:2015/07/06(月) 22:19:01.49
>>988
> ラッパーを抽象度のレイヤーと言い張っている可能性は?
0だよ。

992 :仕様書無しさん:2015/07/06(月) 22:19:51.17
>>990
まじっすか!
真のレベルは頭がヤバイってことで
誰からも相手にされないから
知られてないんですね!

993 :仕様書無しさん:2015/07/06(月) 22:19:56.95
>>990
せやから何がハイスキルなのよ?
どうもうさんくさいなあ。

994 :仕様書無しさん:2015/07/06(月) 22:20:14.40
>>988
ちょっと何言いたいのか分からん

995 :仕様書無しさん:2015/07/06(月) 22:20:28.96
>>991
何を根拠にいっとるんだ。適当なことぬかすな!!

996 :仕様書無しさん:2015/07/06(月) 22:20:36.36
>>989
命令は知らんが命令が発行される前に2回も「書くわけない」と書いたと思うが
理屈家の実態は非理論的で強引だな、ゴミしか書けないわけだ

997 :仕様書無しさん:2015/07/06(月) 22:20:48.18
ホラー話

そして誰も帰ってこなかった。

なんで誰も帰ってこないのに
その話知ってるんだよ!

的な?(笑)

998 :仕様書無しさん:2015/07/06(月) 22:21:13.42
>>994
わかってるくせにw 白々しくもいみじくもわからぬ振りをして逃げようとするとは。恥を知れ!!

999 :仕様書無しさん:2015/07/06(月) 22:21:14.69
誰もしらないが、優れたプログラマがいる。
そのことを俺は知っている。

1000 :仕様書無しさん:2015/07/06(月) 22:21:40.83
>>992
理論派を推してる君は、最大級に非理論的だな

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

271 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)