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

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

本当にあった変な社則とコーディング規約 [転載禁止]©2ch.net

1 :仕様書無しさん:2015/05/18(月) 15:36:18.94
変な社則を何個か書こうと思ったが
どれも面白すぎなので省略

あとコーディング以外の規約もオッケー
関数ごとにフローチャートをかけとか

2 :仕様書無しさん:2015/05/18(月) 16:36:17.38
おちんちんをかきむしる

3 :仕様書無しさん:2015/05/18(月) 19:57:41.17
実処理は80カラム以内
コメントは80カラム目から
修正履歴コメントは120カラム目から

4 :仕様書無しさん:2015/05/18(月) 22:33:01.29
修正履歴ってなんだよwww

5 :仕様書無しさん:2015/05/19(火) 02:36:42.94
は?
コメントに修正履歴も書いたことないのかオマエ。。
修正日付と共に書くだろ

6 :仕様書無しさん:2015/05/19(火) 08:33:07.92
修正前コードはコメント化して、決して消してはイケナイ。
だんだん読めなくなってくる。

7 :仕様書無しさん:2015/05/19(火) 12:13:21.34
変数名の規約

グローバル変数名はg_
スタティック変数名はs_から始める
内部変数名にi.j.kなど英字1文字は禁止

8 :仕様書無しさん:2015/05/19(火) 12:52:42.37
内部変数名ってなんだ?

9 :仕様書無しさん:2015/05/19(火) 14:07:33.92
>>8
ローカル変数だろ

10 :仕様書無しさん:2015/05/19(火) 19:32:14.85
>>7
接頭辞は
 プロジェクト固有2文字
+プロセス名3文字
+スコープ1文字
+型2文字
=8文字
が過去最高

11 :仕様書無しさん:2015/05/19(火) 21:12:59.48
>>9
じゃあクラス内部名はなんて言うんだ?
クラス内部名でいいのか?

12 :仕様書無しさん:2015/05/19(火) 21:15:16.25
メンバ変数

13 :仕様書無しさん:2015/05/19(火) 21:19:18.79
> グローバル変数名はg_
> スタティック変数名はs_から始める
これって変なのか?

14 :仕様書無しさん:2015/05/19(火) 21:30:19.19
特に変ではないと思うに1票

15 :仕様書無しさん:2015/05/19(火) 21:48:18.03
>>12
メンバ変数とローカル変数ね。

それで内部変数名ってなんなんだ?

16 :仕様書無しさん:2015/05/19(火) 21:57:52.44
>>15
ローカル変数だろ

17 :仕様書無しさん:2015/05/19(火) 22:29:14.06
>>14
同じく

18 :仕様書無しさん:2015/05/19(火) 22:34:13.70
>>5
今の世の中はバージョン管理システムってものを使うんじゃないかな

19 :仕様書無しさん:2015/05/19(火) 22:52:27.74
バージョン管理システム使ってたって、ファイルに変更履歴書くことはあるぞ

20 :仕様書無しさん:2015/05/20(水) 12:24:05.50
>>3
一瞬FORTRAN を連想してしまった

21 :仕様書無しさん:2015/05/20(水) 17:54:52.40
変な社則はどうした?w

22 :仕様書無しさん:2015/05/21(木) 01:05:53.59
>>19
ホントはバグ票とかチケットとかとリンクしていればいいんだけど、
バグ票とかの管理が杜撰で無くなっていたり、見つけるのが困難な
ところに入り込んでいたりで片方だけ残っていてもなあってのはある。

あとCVS>SVNやSVN>Gitの移行でほぼ確実に読まないであろう
過去の履歴ごと移行しても意味あんのかなあとかは思ったな。

23 :仕様書無しさん:2015/05/21(木) 21:47:38.76
>>19
変更履歴はないな。どうしたそうしたかならあるけど。

例えば「普通に書いたらこういう風になると思われるけど
○○のせいで、こういう現象が起きたのでこのように書き換えている。」
みたいな変更履歴?というか変更した理由なら書く。

>>22
> ホントはバグ票とかチケットとかとリンクしていればいいんだけど、
ツールが大事。git使ってるならgitlabがいいよ。

「チケットとリンク」というふうに考えるから管理が面倒くさくてやらなくなる。
gitlab(元になったgithubなんかでもそうなんだけど)は
コミットメッセージに「#123の問題に対応」とか書くと勝手に相互にリンクされる。
あとはちゃんとコメント書きましょう。ぐらいの感覚でよくなるよ。

> あとCVS>SVNやSVN>Gitの移行でほぼ確実に読まないであろう
> 過去の履歴ごと移行しても意味あんのかなあとかは思ったな。

うちはgit化の時に過去の履歴はそのまま凍結して引き継がないで移行した。

過去のコードを全く見ないわけじゃなくて、古いコードでバグが有った時
最初からなのか、何かの理由があってこうしたのか調べる時に見たりはする。

gitのやり方で見れるから、ないよりはあったほうがマシだが
そんなに調べないので履歴を引き継がなくてもあまり困ってはいない。
過去のコードは凍結しただけで見れるしね。

24 :仕様書無しさん:2015/05/22(金) 13:05:19.14
バージョン管理システムって使い方ミスるとファイル壊れるから避けてるw

25 :仕様書無しさん:2015/05/22(金) 18:57:32.38
ねーよどんなバージョン管理システムだwww

26 :仕様書無しさん:2015/05/22(金) 20:08:38.02
そんなに壊れるんならどこかしこも使ってないわなぁw
避ける方が変だ

27 :仕様書無しさん:2015/05/22(金) 21:14:19.00
>>24
外国人が普通にgithubとかを使いこなしてるみると、
日本はなんて遅れてるんだろうってつねづね思うよ。

28 :仕様書無しさん:2015/05/22(金) 21:25:16.64
こういう奴が変な社則やコーディング規約を作っていくんだろうなぁ

…というツッコミ待ちか

29 :仕様書無しさん:2015/05/22(金) 21:43:22.08
自分たちで作らないで、有名な何かを参考にして欲しい。
もしくはツイッターで公開するとかさ。
そうすれば変な奴は叩かれるだろうしw

30 :仕様書無しさん:2015/05/24(日) 01:38:09.50
>>27
個人はともかく、日本に限らずマトモな企業は使わない。

31 :仕様書無しさん:2015/05/24(日) 01:40:38.89
>>24
そうそう、エディタやPCも使い方ミスるとファイル壊れるから避けなきゃねw

32 :仕様書無しさん:2015/05/24(日) 07:50:41.03
>>24
人間が使うとなんでもこわしちゃうからAIが発達するまではソロバン使ってた方が良いよ

33 :仕様書無しさん:2015/05/24(日) 12:51:11.40
ポインタは危険だから使用禁止。

34 :仕様書無しさん:2015/05/24(日) 17:33:42.25
組み込みだけど
構造体禁止あったな

35 :仕様書無しさん:2015/05/24(日) 21:51:25.48
三項演算子は使用禁止

理由:分からない人がいるから

36 :仕様書無しさん:2015/05/24(日) 22:03:30.58
本当はわからない人がいるからじゃなくて、
「自分がわかんない。勉強もしたくない」
なんだよなw

37 :仕様書無しさん:2015/05/24(日) 22:04:18.42
プログラム言語は使用禁止
理由:分からない人がいるから


ということにならないのはなんでなんだろうねw

38 :仕様書無しさん:2015/05/24(日) 22:20:20.86
経験者募集

「経験者につぐ、お前ら今までどれだけ力をつけてきたか知らんが、
これから、この足かせをつけて働いてもらう。
おまらが使えるそれらの力は一切使用禁止だ。
どんなに力があっても一番下の者にあわせる。それが平等というものだよ」

こんなんで生産性をあげるとか出来るわけがないわけで。


(どんなに足が速い人でも一番遅い人に合わせて)
全員手をつないで一等賞。に通じるものがあるよなw
ゆとり的発想。

39 :仕様書無しさん:2015/05/24(日) 22:26:11.14
Java8でラムダ式禁止とかなったりして。

40 :仕様書無しさん:2015/05/24(日) 22:30:11.29
>>39
たまに理由として古い環境で使うかもしれないからとかあるが、
実際に古い環境で使うことって無いんだよな。

あるかどうかわからないことを考えるよりも
古いものを新しくしていった方がいい。

41 :仕様書無しさん:2015/05/24(日) 22:30:40.23
Java8でラムダ式禁止はむしろありだと思う。
使い方もロクに知らん奴に中途半端に使われたらかなわんわ。

42 :仕様書無しさん:2015/05/24(日) 22:35:21.41
>>41

本当はわからない人がいるからじゃなくて、
「自分がわかんない。勉強もしたくない」
なんだよなw

43 :仕様書無しさん:2015/05/24(日) 22:42:51.07
>>42
「ラムダ式使ってるから関数型」とかいって副作用塗れのコード書かれたらたまんねーの。

44 :仕様書無しさん:2015/05/24(日) 22:43:36.72
言語のとある機能を禁止して言っていいのは、
その言語を使いこなしている人が、適切な理由で
使うとコードが悪くなると判断したものだけよ。

例えばJavaScriptのwithとかね。

コードが悪くなるんじゃなくて「わからない人間がいるから」を
理由にしてはいけないってこと。

45 :仕様書無しさん:2015/05/24(日) 22:44:22.76
>>43
それはラムダに問題があるのではない。
人間の問題だ。

46 :仕様書無しさん:2015/05/24(日) 22:54:34.63
Linuxわけわからんから
使うの禁止。みたいな話w

47 :仕様書無しさん:2015/05/24(日) 23:43:37.05
ラムダ禁止したらストリームの記述がウンコになるなぁw

48 :仕様書無しさん:2015/05/25(月) 03:51:10.23
ラムダは駄目だ!

49 :仕様書無しさん:2015/05/25(月) 05:00:15.81
それを言うなら、
ラムダはラクだ!

50 :仕様書無しさん:2015/05/25(月) 05:45:18.10
包丁は使ってはいけません。
けがをする人がいたからです。

51 :仕様書無しさん:2015/05/25(月) 07:33:39.89
>>18
お前はまだまだ若いな

52 :仕様書無しさん:2015/05/25(月) 07:48:40.46
>>51
年寄=偉い、ってのは明治まで。

53 :仕様書無しさん:2015/05/25(月) 08:04:50.23
>>51の意訳
「その話にはついて行けないから触れんでくれ」

54 :仕様書無しさん:2015/05/25(月) 09:01:42.84
>>52
>>53
若いな

55 :仕様書無しさん:2015/05/25(月) 09:06:01.72
>>54
それ、面白くないよw

56 :仕様書無しさん:2015/05/25(月) 20:55:57.71
>>55
老けてんな

57 :仕様書無しさん:2015/05/25(月) 21:09:50.11
下請けあるとバージョン管理システム共用できなくてソースだけが流れてくるから

58 :仕様書無しさん:2015/05/25(月) 22:46:35.14
パーフォース使いなよ

59 :仕様書無しさん:2015/05/25(月) 23:29:55.68
>>57
その場合、大抵コメント残すことルールだったりするよね
コメントバージョン管理システム cvs

60 :仕様書無しさん:2015/05/26(火) 01:17:23.41
>>57
VPNが使えない会社は悲惨だな・・・

61 :仕様書無しさん:2015/05/26(火) 02:19:53.64
>>57
世の中にクソで馬鹿な会社ってあるんだなぁw

62 :仕様書無しさん:2015/05/26(火) 22:07:15.60
クソで馬鹿な会社かぁ。
前居た会社(別業界)、このエリアはキャットウォークで歩く事とかあったなぁ。
キャットウォーク=猫背歩きらしいw

63 :仕様書無しさん:2015/05/26(火) 22:29:02.14
え? 女豹のポーズじゃないの?

64 :仕様書無しさん:2015/05/27(水) 00:22:04.58
なんじゃそりゃ

65 :仕様書無しさん:2015/05/28(木) 17:09:27.94
インデントが理解できない爺には困ったw

66 :仕様書無しさん:2015/05/28(木) 17:53:26.66
歩き方でキャットウォークって言われたら普通の人はモデル歩きを思い浮かべると思う

67 :仕様書無しさん:2015/05/28(木) 22:14:10.59
元々猫背のモデルが多かったからキャットウォークって言われたんやで

68 :仕様書無しさん:2015/05/28(木) 23:09:56.16
月イチの朝礼で選ばれた人がスピーチ。
スピーチした人がくじ引きで次の人を選ぶ。
ここは小学校かと。

69 :仕様書無しさん:2015/05/29(金) 00:03:06.41
キャットウォークって金網の通路のことだろ

70 :仕様書無しさん:2015/05/29(金) 12:28:48.18
インデントは2か4か6で喧嘩になるから何も言わない

71 :仕様書無しさん:2015/05/29(金) 12:33:18.49
6派がいるのか。そして喧嘩が成立するくらい6派に発言権があるのか。希少だな。

72 :仕様書無しさん:2015/05/29(金) 12:40:09.83
6は初めて聞いたwww

73 :仕様書無しさん:2015/05/29(金) 12:42:44.24
>>71-72
タブと勘違いしてない?インデントとタブは別の概念だぞ。

74 :仕様書無しさん:2015/05/29(金) 12:47:03.74
昔4と8であちこちで戦争が起こって悲惨なことになったのじゃよ。
ある会社でだな、人徳はあるが技術には疎い偉い人が、こう裁定したのじゃよ。
「4と8で揉めるなら、間を取って6にしなさい」

そして、インデント6が使われることになったのじゃよ。
争っていた技術者たちは、4と8で争わなければこんな不便なことにはならなかったのに、
と互いに涙して己らの過ちを悔い、馬鹿に決定権を与えてはいけないことを覚ったのだとさ。

75 :仕様書無しさん:2015/05/29(金) 12:58:16.08
おもしろいつもりなの?池沼?

76 :仕様書無しさん:2015/05/29(金) 21:42:44.47
>>73
> タブと勘違いしてない?インデントとタブは別の概念だぞ。

インデントとタブを別の概念にしたのは間違いだったよな。
わざわざ区別する理由がないし、区別しないほうが良い。

77 :仕様書無しさん:2015/05/29(金) 21:57:54.20
別に6でも良くね?

78 :仕様書無しさん:2015/05/29(金) 22:09:33.65
もしTABが昔から4文字移動するキーだったら
こんな論争は起きなかったと思うよ。

79 :仕様書無しさん:2015/05/29(金) 22:39:34.01
タブ
ブタ

80 :仕様書無しさん:2015/05/29(金) 23:06:54.16
タブクリア

81 :仕様書無しさん:2015/06/01(月) 10:02:06.94
あぁ、それ好きだった

82 :仕様書無しさん:2015/06/01(月) 22:32:16.28
言語、処理構造、データ構造は全て好きにしてよい。
ただし他の人と歩調を合わせること。バグが出ないこと。あとで困らないこと。苦情がこないこと。
(本当に「○○社のプログラマに対する規約」にこれだけ書いて壁に張ってある)。

逆に言うと、全部おまえらで問題が発生しないように取り決めろってことで、この上なくめんどうだった。
まぁどんな仕事になってたか気になる人がいれば書くが。

83 :仕様書無しさん:2015/06/01(月) 22:54:25.39
>>73, >>76
それを言うとインデントとカラムも別物だが…

84 :仕様書無しさん:2015/06/02(火) 20:46:12.92
>>82
失敗した? それならどうなったかだいたい分かるよw

まずその規約自体は、間違ってはいないのだが
前提として高い技術力を持っている必要がある。

その規約で失敗したのであれば、技術力が低くて、
どうすればいいかがわからなかったのだろう。

つまり、技術力が低くて
・言語、処理構造、データ構造をどう選べばいいかわからない
・他の人と歩調を合わせる方法がわからない
・バグを出さないようにする方法がわからない
・あとで困らないようにする方法がわからない
・苦情がこないようにする方法がわからない

できるのは「頑張る」(どういう風に頑張るかが抜けてるから意味ない)
と言うセリフを口にするか、せいぜい意味のないルール盛りだくさんの
独自のコーディング規約を考えて終わりと言った所だろう?

ルールを守るのが目的のルールがたくさん出来てしまって、
そのルールを守る・守らせることに時間を浪費する。

85 :仕様書無しさん:2015/06/02(火) 21:59:42.15
>>82
これが成功するなら、各々の意識や成熟度が非常に高い組織と考えていいと思うね

86 :仕様書無しさん:2015/06/03(水) 01:36:52.52
>>84
残念ながらけっこう違った

87 :仕様書無しさん:2015/06/03(水) 03:51:08.70
>>85
CMMIレベル0だろどうみても

88 :仕様書無しさん:2015/06/03(水) 17:06:44.12
組織として成立してないに一票

89 :仕様書無しさん:2015/06/06(土) 11:01:33.22
インデントはほんとにモメるなあ
0x09で入れといてレンダリングは各自のエディタに任せるとかでいいと思うけど
コードじゃなくてホワイトスペースにしろとかいう宗派もあって大変

90 :仕様書無しさん:2015/06/06(土) 11:18:43.92
>>89
まあ、人に食わせて貰ってる連中は、そういうカネに成らない下らない事で何かを主張した気になるんだろう。

91 :仕様書無しさん:2015/06/07(日) 06:59:53.44
宗教戦争したがるのはビジネスわかってない学生あがりの若いヤツだよな

92 :仕様書無しさん:2015/06/07(日) 09:06:32.45
アシストだったっけ
漫画持ち歩き禁止とかいう社則は
もちろん社内絶対禁煙

まだやってんのかな

93 :千葉徳洲会病院:2015/06/09(火) 13:51:49.84
   
千葉徳洲会病院 腹腔鏡手術ガイドライン適応外手術で三人死亡
 第二の千葉県がんセンターか?

 千葉県船橋市の千葉徳洲会病院(高森繁院長)で2013年より少なくとも三人の患者がガイドライン適応外の腹腔鏡手術を受け、術後すぐに死亡していることが明らかになった。
 千葉徳洲会病院はがん拠点病院の認定を目指して手術件数を増やしているところであり、無理な手術適応の拡大が死亡の原因である可能性が指摘されている。
 術後行われたデスカンファレンスで高森院長はガイドライン適応外の手術であることを認めており、「ガイドラインの適応外の手術を自粛すると他の関連施設に迷惑がかかるので今後もガイドラインの適応外の手術も行っていく」と明言している。
 そのうち、2014年7月7日の手術については手術直前の術式が変更になり、研修医が執刀し、指導医に術式を含め大幅に手術記録を訂正されている。術中出血量は15000mlであったが輸血はほとんど用意されていなかった。

94 :仕様書無しさん:2015/06/13(土) 03:39:25.72
ダメ:

if (...) {
 A;
}
B;

よい:

if (...) {
 A;
} else {
 B;
}

理由:上のはわかりにくいから  ←!??

95 :仕様書無しさん:2015/06/13(土) 08:59:01.78
>>94
ロジック変わってんじゃん!!

96 :仕様書無しさん:2015/06/13(土) 09:32:16.39
別の記述やろが

97 :仕様書無しさん:2015/06/13(土) 10:35:10.02
//ダメ
if(expr){
 A;
}


//よい
if(expr)
{
 A;
}

こうじゃなくて?

98 :仕様書無しさん:2015/06/13(土) 13:52:57.37
見やすさに関してはどちらも言うほど変わらないので
行数が短くなる方を優先した方がいい。

99 :仕様書無しさん:2015/06/13(土) 14:33:22.29
ステップ数を稼ぐために、行数が長くなる方を優先するんじゃなくて?

100 :仕様書無しさん:2015/06/13(土) 14:46:55.29
ライン数ならともかくステップ数は行数を長くしようが変わらない。

101 :仕様書無しさん:2015/06/13(土) 14:58:31.03
行数を水増しするツールを作ればいいだけ。
例えば()の前後に改行を入れるだけでも
かなりの行が水増しできる

if(expr){
 A;
}



if
(
 expr
)
{
 A;
}

102 :仕様書無しさん:2015/06/13(土) 18:13:49.58
>>101
最初から水増しした状態で書けばよいのに、
わざわざツールを使ってワンクッション入れる理由は?

103 :仕様書無しさん:2015/06/13(土) 23:35:22.17
ツールつか、フォーマッタの設定変えるだけでしょ。

104 :仕様書無しさん:2015/06/13(土) 23:37:01.21
>>102
水増ししたコードは読みづらくメンテナンスもしづらいから。

開発時は効率を優先させ
金をぼったくるためにツールを使う。

無駄に苦労して金をその分もらったって意味ないのよ。
ぼったくるなら楽してぼったくらなきゃw

105 :仕様書無しさん:2015/06/14(日) 03:48:21.51
最初の方にあったけど、

VCSが壊れるから使わないとか、まともな会社は使わないとか
もう日本完全に終わってるなw

今時Gitやその類を使ってない所は頭のおかしい奴らがいると見ている

106 :仕様書無しさん:2015/06/14(日) 05:12:15.16
CtrlとCaps入れ替え禁止なんてルールあったら発狂しそう
フリーウェア禁止、Windowsカスタマイズ禁止のコンボなら結果的にNGになりそうだけど
そんな環境で耐えてる奴はいるんだろうか

107 :仕様書無しさん:2015/06/14(日) 11:45:34.35
int hoge(){
 :
 :
 :
 :
 :
 return 0;

 //↓それでも延々と続くコメントされていない古いコード
 :
 :
 :
 :
}

というコードに遭遇したことがある
素人が見ただけじゃ絶対バレないとでも思ってたんだろうか

108 :仕様書無しさん:2015/06/14(日) 17:39:56.44
どっかにgotoあんじゃね

109 :仕様書無しさん:2015/06/14(日) 18:08:04.03
>95-97
あーごめん
全部 return; 抜けてた

if (...) {
 A;
 return:
}
B;
return:

if (...) {
 A;
 return:
} else {
 B;
 return:
}

110 :仕様書無しさん:2015/06/14(日) 18:35:38.54
returnいれすぎだろ

111 :仕様書無しさん:2015/06/14(日) 20:29:55.93
returnこそ最後に一個の典型例だろそれ

112 :仕様書無しさん:2015/06/14(日) 20:33:10.52
returnは最後に一個のみというのは
変なコーディング規約の一つ

113 :仕様書無しさん:2015/06/14(日) 20:54:21.85
ララらラベル、ララらラベル、ララらラベル、ラベル、ラベル

114 :仕様書無しさん:2015/06/14(日) 20:58:38.47
>>112
どんな言語でどんな時でも頑なにreturn1コを守るのはおかしいわな
'90年代は俺もそれを守ってたけど、今は守ると考えずに自由にやってる
状況に応じたイイ書き方があるからね

115 :仕様書無しさん:2015/06/14(日) 21:03:33.87
'90年代ってのは変な書き方だったなw
try catch finallyとかの言語が出てくる前って意味

116 :仕様書無しさん:2015/06/14(日) 22:01:11.58
returnを最後に1つ
の為にif文妖怪まみれなソースが大量に量産されました

今どきやってる脳みそ膿んでるところがあるのかねぇ

117 :仕様書無しさん:2015/06/14(日) 22:04:32.84
エラー条件を最初に書いて抜けるif文は構いませんてか今じゃまぁ普通ですね

ですがreturn1つを守る為にif文ネストが酷いのがありました
さらに変数に成否入れ替えまくって最後にreturnで返すという味付けされているのです

118 :仕様書無しさん:2015/06/15(月) 12:08:50.93
例えば、○○がtrueの時はこうするって要求を、
○○がfalseならまずreturnするって置き換えると苦言を言われる。

内部仕様じゃなくて、テストの結果を確認すればいい話だと思うのだが

119 :仕様書無しさん:2015/06/15(月) 12:28:52.93
○○Unitその他のテストツールすらかませてない現場とかいまどきないだろ…
ないよな?

120 :仕様書無しさん:2015/06/15(月) 12:37:13.15
ないあるよ

121 :仕様書無しさん:2015/06/15(月) 12:38:19.02
>>119
うちは受託だから、顧客がやってと言わなければやらない。

122 :仕様書無しさん:2015/06/15(月) 12:39:32.39
会社に入社するまえに最低限Linuxを弄れるようにしてくること

業務でLinuxなんてNASしか組んでない。

最低限ってどこまで最低限だよ…ログインまでかよ…

123 :仕様書無しさん:2015/06/15(月) 12:45:34.18
>>122
LPIC Lv3までとっとけば文句ないんじゃね?

124 :仕様書無しさん:2015/06/15(月) 12:52:13.18
>>123
おお、こんな資格あるんだ。受けよ。
ただ、問題見ただけだが今の実力じゃ多分レベル1に受かるか受からんかな気がした。
俺も低脳だったわw
セキュリティスペシャリストの頭休めで受けたら捗りそう。

125 :仕様書無しさん:2015/06/15(月) 19:41:11.30
>>118
ガードって呼ばれる書き方っすね。
ガード禁止されたらネストせにゃならんのよね。

126 :仕様書無しさん:2015/06/16(火) 01:18:05.04
Cにて
変数宣言はすべて関数の先頭で行うこと
宣言時に初期化するの禁止

ブロックの先頭で変数宣言することも許されず
ソースは見辛かった
まあこっちはまだマシだった

C++にて
テンプレート使用禁止
クラスを新しく定義すること禁止
参照禁止
生ポインタ使用禁止

奇っ怪なマクロによる超高性能スマートポインタ(ただし中身はvoid*)を必ず使用すること、
という取り決めによりいつも奇っ怪な動作(不具合とも言う)に悩まされる職場だった

127 :仕様書無しさん:2015/06/16(火) 02:15:48.51
>>126
Cがブロックの先頭で変数を宣言出来るようになったのが正式にはC99からだし、
もっと古い処理系だと宣言と初期化が一緒に出来ないコンパイラもあったからな。
いいか悪いかは別として、そういうのも知らないのに批判してる奴ってのは
滑稽だなあと。

128 :仕様書無しさん:2015/06/16(火) 05:08:03.58
>>125
guard clauseを先頭に書くスタイルを
premature returnsやearly returnsって呼ぶんじゃね?
俺もあまり自信ないけどさ1

129 :仕様書無しさん:2015/06/16(火) 07:47:19.09
>>77
プログラマは2O乗が好きだからね。

>>89
Tabコードもホワイトスペースじゃないかというのは置いといて、
各自に任せるといっても、想定の数じゃないと見れたもんじゃないから、
設定しなくても合うスペースの方がいいんじゃないかと思う。
ファイルサイズはでかくなるけど。

130 :仕様書無しさん:2015/06/16(火) 07:48:38.23
あれ、「2のn乗」って書いたんだけど、なんか化けるな。

131 :仕様書無しさん:2015/06/16(火) 12:13:22.78
>>127
C89でしょ。C99ではブロックの先頭以外でも変数宣言できるようになっている。
知ったかすると恥ずかしいよ?

132 :仕様書無しさん:2015/06/16(火) 19:23:02.98
>131
禿同

133 :仕様書無しさん:2015/06/17(水) 01:18:25.56
>>131
https://ja.wikipedia.org/wiki/C99
新機能

C99にはさまざまな新機能が導入された。その多くはさまざまなコンパイラによってすでに拡張として実装されていた。

インライン関数
★ファイルスコープでない変数宣言がブロックの先頭になければならないという制限の撤廃
いくつかの新しいデータ型。long long int、拡張整数型、明示的なブーリアン型、複素数型 など
BCPLやC++のような、//から始まる一行コメント
snprintfのような新しいライブラリ関数
stdbool.hやinttypes.hなどの新しいヘッダファイル
型総称的な数学関数 (tgmath.h)
IEEE 浮動小数のより進んだサポート
指示初期化子
可変引数マクロのサポート
最適化のための restrict 修飾子

134 :仕様書無しさん:2015/06/17(水) 04:17:02.02
>>131
書き間違えにこまけーな

135 :仕様書無しさん:2015/06/17(水) 08:44:11.77
>>134
肉体労働者と違って我々は知識でメシを食っている。

知識の間違いは命取りだぞ?
間違った知識を披露して信用や尊敬を失うかもしれない。

136 :仕様書無しさん:2015/06/17(水) 12:12:10.46
バージョンxxからyyになった。
こうゆうのは間違いは許されない。

137 :仕様書無しさん:2015/06/17(水) 17:38:01.49
>>127
C89が要件の仕事でC99と勘違いしてソースかいたら大変なことになるけど?
大変なことにならないと思っているなら、それは無恥の集団の中にいるから
C99の機能も使いこなせないだけ。

138 :仕様書無しさん:2015/06/17(水) 17:40:13.06
>>134
そうっすね、1,000千円を1,000万円なんて契約書で書き間違えても
大したことじゃないっすよねwww

139 :仕様書無しさん:2015/06/17(水) 23:11:24.09
人の書き込みの粗を探して指摘出来ちゃうオレカッケェー
って思っていたら皆に自分のミス突っ込まれて顔真っ赤
という図にしか見えない今日この頃です

誰とは申しませんけども。

140 :仕様書無しさん:2015/06/18(木) 00:46:08.55
>>137
>>126を読んでどこがC89の案件と読めるのか不思議

141 :仕様書無しさん:2015/06/18(木) 01:49:54.78
>>140
人からよくアスペって言われるでしょ?

142 :仕様書無しさん:2015/06/18(木) 03:08:55.18
>>141
おまえほどじゃないさ

143 :仕様書無しさん:2015/06/18(木) 07:43:25.46
細かいことに拘るのがアスペの特徴だろ

144 :仕様書無しさん:2015/06/18(木) 09:42:38.04
>>143
逆は必ずしも真ならず。
まあそれ以前に、侮辱する為によく知りもしない病名持ち出すような、病身舞メンタリティの奴はチョットねえ、、、

145 :仕様書無しさん:2015/06/18(木) 20:39:19.69
突っ込み入れられたくらいで
ガチ切れしてアスペ言いたがるのはいるわな

146 :仕様書無しさん:2015/06/18(木) 21:38:08.00
>>127 は頭おかしいってことでいいの?

147 :仕様書無しさん:2015/06/18(木) 21:38:53.63
マなんて全員頭おかしいのよ

148 :仕様書無しさん:2015/06/18(木) 21:40:10.00
>>146
それはお前が>>127に対して適切な
レスを返せるかどうかだよ。

仮に>>127が頭がおかしかったとしても、
それに対してお前が反論できなければ
お前歯>>127よりも劣るってこと。

ま、そういうい質問をしている時点で
>>127よりも劣ってるのは明白だけどね。

149 :仕様書無しさん:2015/06/18(木) 21:43:59.24
>>148
じゃあ僕に対して適切なレスを返せなかった君は
僕より劣ってるってことになるじゃないですか!?はい論破です。

150 :仕様書無しさん:2015/06/18(木) 21:48:48.71
>>148
適切なレス返してるじゃん?

適切なレスっていうのは、相手がいった内容に対して
何かコメントするってことだよ。

例えば相手がいったに対して言及せずに、
(よくわからんけど)お前はバーカ。みたいなこと言うのは
適切なレスじゃない。

だから>>149の内容自体も適切なレスじゃない。

151 :仕様書無しさん:2015/06/18(木) 22:11:54.94
>>150
お前はバーカwww

152 :仕様書無しさん:2015/06/18(木) 22:21:23.00
>>150
じゃあ僕の内容に対して何もコメントできなかった君は
僕の足元にも及ばない知恵遅れってことになるじゃないですか!?
自分が言い出した論理で自分が追い詰められてますよね。はい論破です。

153 :仕様書無しさん:2015/06/18(木) 22:23:07.29
>>127 は頭がおかしいってことですよね。

154 :仕様書無しさん:2015/06/19(金) 02:15:20.14
>>127>>148>>152

155 :仕様書無しさん:2015/06/19(金) 05:47:53.70
まったく低脳のコーダーどもが、目くそ鼻くその争いしてんじゃねえよ

156 :仕様書無しさん:2015/06/19(金) 06:34:01.98
C++で
new禁止
std:string禁止
STL禁止
辛かった・・・
あとややこしいからgitも禁止してた

157 :仕様書無しさん:2015/06/19(金) 07:29:41.26
>>156
釣り、、、だよね?、、

158 :仕様書無しさん:2015/06/19(金) 07:37:00.81
>>154
苦し紛れの発狂レスですね。はい論破です。

159 :仕様書無しさん:2015/06/19(金) 12:07:59.63
>>152
> じゃあ僕の内容に対し

お前の内容に対してはレスしている。
嘘だと思うなら「お前の内容」を示してみ。
その内容に対してはレスしてるから。

160 :仕様書無しさん:2015/06/19(金) 13:43:48.62
>>156
本当ならひでぇ話だなwww

161 :仕様書無しさん:2015/06/19(金) 14:26:13.96
よくあるベターCを強制した使い方ってことか
まぁ少なからず恩恵は有るけどほぼ無意味だなwww

162 :仕様書無しさん:2015/06/19(金) 20:10:58.61
>>131
マジか?C99すごいなあ

163 :仕様書無しさん:2015/06/19(金) 20:13:28.53
vbで雑用ツールつくってるけど
Cのコーディングにも良い影響あたえてくれる

164 :仕様書無しさん:2015/06/20(土) 00:50:02.95
>>156
あったわ
組み込みだったんだが
せっかくC++でもなんちゃってだったりしてな
周回遅れな業界だったりするんだよな

165 :仕様書無しさん:2015/06/20(土) 00:51:39.53
>>161
C++をそんな風に使うくらいなら、D言語の方がマシなくらい。

166 :仕様書無しさん:2015/06/20(土) 00:56:58.54
中途半端に使えるのは迷惑なんだよね

167 :仕様書無しさん:2015/06/20(土) 01:17:16.09
若者のhoge離れ
http://developers.srad.jp/story/15/06/19/0840215/

168 :仕様書無しさん:2015/06/20(土) 08:00:00.34
組み込みだと、C言語で十分と、C++が分かる人間が居ないし
下手するとC++に敵意を持ってたりする。。

そもそもC言語なのに構造化以前のぐちゃぐちゃなスパゲティコードで、
初期化漏れ、開放漏れのバグが出まくり。

そういう環境だと、ベターCでいいから、せめてカプセル化+コンストラクタ・デストラクタ
だけでも導入して欲しいと思う。

169 :仕様書無しさん:2015/06/20(土) 08:22:31.12
>>168
いるよねー
C++に敵意持ってるCプログラマ

常套句は「C++を使うと遅くなる(キリッ」
C++コンパイラ使ってCみたいなコード書いておいて、
こういうこと言うからもうワケワカメ

170 :仕様書無しさん:2015/06/20(土) 08:26:17.16
雑魚はどこにでも居る

171 :仕様書無しさん:2015/06/20(土) 11:42:42.15
>>168
そんな人でもコンストラクタは魅力なのか使ってたりするんだけど
それをmemcpyしてたりなかなか怖い
その後、他の人が改造して継承したりvirtual追加したりしても
memcpyは残ったままとか身の毛もよだつような事が起きたりする

172 :仕様書無しさん:2015/06/21(日) 10:37:59.61
>>168
大半の組み込みではヒープメモリ使わないから
malloc使ってfree忘れってのはない

173 :仕様書無しさん:2015/06/21(日) 10:47:34.53
>>172
それはまた極端な例だな
エンべデッドLinuxとかQNXとか組み込み系でも自分で全部メモリ管理するなんて今はほとんど無いだろ

174 :仕様書無しさん:2015/06/21(日) 11:05:31.56
>>173
動く機械系は
16ビットマイコンが主流だから
マイクロセカンドの制御に高級なOSなんぞ
使わないから

メモリマップを監視しながらデバッグしてるよ

175 :仕様書無しさん:2015/06/21(日) 11:45:06.99
>>174
だからさ
そーゆー世界が有るのは知ってるって
ただそれが今でも主流みたいな思考はいつの時代だよって

176 :仕様書無しさん:2015/06/21(日) 12:03:57.33
ラズパイでwindows10が動く時代だからな

177 :仕様書無しさん:2015/06/21(日) 13:16:29.00
>>175
主流だよ

パソコンしか触ってないからそう思ってるだけで

16ビットマイコンは毎月何億個も消費されてる

178 :仕様書無しさん:2015/06/21(日) 13:30:59.65
>>177
お前の世界が狭すぎるだけだろ
販売個数だけ持って来てもなんも説得力ないわ

179 :仕様書無しさん:2015/06/21(日) 13:32:18.41
そういう世界はそもそもC++すら使えなさそうだが

180 :仕様書無しさん:2015/06/21(日) 13:43:35.31
休日出勤中のエンベデッドスペシャリストの俺に言わせれば、
>>178
の方が低レベル


ただ俺も16bitマイコンは久しく触ってないが、今開発中のアノ部品にも使われてるし、やっぱどこかで開発してる人達は今もいるだろ。

181 :仕様書無しさん:2015/06/21(日) 14:05:13.01
販売個数多いとそれが開発方式の主流になんのか?

182 :仕様書無しさん:2015/06/21(日) 14:09:42.80
そうです広い世界が見えるようですので
一部に使われているとそれが主流になるんです

183 :仕様書無しさん:2015/06/21(日) 14:36:48.89
主流かどうかは知らんけど、
例えばCPUの仕組みと動作のさせかたを知らないのはプログラマーとは少し違うなと思う
自称マクロ使いとかならいいが

184 :仕様書無しさん:2015/06/21(日) 18:18:29.79
とりあえず無知な奴らが大半ってことだけはわかった

185 :仕様書無しさん:2015/06/21(日) 19:35:18.60
マイコン一つ一つに丁寧にプログラムを書き込むお仕事です。

186 :仕様書無しさん:2015/06/21(日) 21:59:43.35
真理値は必ずtrue falseと比較すること

結果、以下のような組み合わせを注意深く読み解く羽目になった
if (isXXXX() == true)
if (isXXXX() != true)
if (isXXXX() == false)
if (isXXXX() != false)
if (isNotXXXX() == true)
if (isNotXXXX() != true)
if (isNotXXXX() == false)
if (isNotXXXX() != false)

187 :仕様書無しさん:2015/06/21(日) 22:37:03.25
頭の悪い典型例じゃねぇか
反転されたものを反転させんなよ

188 :仕様書無しさん:2015/06/21(日) 23:06:24.43
真理値

189 :仕様書無しさん:2015/06/21(日) 23:07:51.57
見事にスレタイ通りである

190 :仕様書無しさん:2015/06/21(日) 23:50:45.17
真理値は必ずtrue falseと比較すること
その理由は・・・


これが抜けてるとどんなルールでもクソにしかならない

191 :仕様書無しさん:2015/06/21(日) 23:53:13.93
真偽値

192 :仕様書無しさん:2015/06/22(月) 01:23:42.71
>>191 はい答え言いました。減点30

193 :仕様書無しさん:2015/06/22(月) 05:42:07.34
負論理でモーター回転
モーター停止の信号レヴェルは?

194 :仕様書無しさん:2015/06/22(月) 06:31:20.58
まさに真理

195 :仕様書無しさん:2015/06/22(月) 09:25:53.40
>>180
自分の発言がブーメランになってることに気付いてないマヌケ

196 :仕様書無しさん:2015/06/22(月) 16:18:47.19
(result==true)みたいなのは、=が一個でもエラーが出ないからむしろ禁止すべきなんだけどな。
Java以外は知らんけど。

197 :仕様書無しさん:2015/06/22(月) 16:44:18.50
なんか知らんがとにかく手書きで下書きって言う爺

198 :仕様書無しさん:2015/06/22(月) 17:00:42.97
>>196
論理値を先に書いたりってのはYoda conditionsとか呼ばれて何となく異端扱いにされてるけどね

199 :仕様書無しさん:2015/06/22(月) 18:25:24.23
Yoda conditionsの話しなんか
誰もしてない、ヨーダが?

200 :仕様書無しさん:2015/06/22(月) 19:57:12.40
>>196
誰に向かって言ってんの?
>>186以降の流れを読む限り、「真理値は必ずtrue falseと比較すること」がおかしな規約だという共通認識はとれてるように思うけど

201 :仕様書無しさん:2015/06/23(火) 00:48:10.39
>>200
言語によっては196のような書き方をしなければ回避できない
問題があって、それじゃ書くの手間でしょというのでjavaなんか
だと条件判断にbool値しか使えないようにした経緯がある。

ただそれでもbool変数だけを書いたり、「! 変数」を書いたりと
ゆらぎが出るから、書いた意図が伝わる、ぱっと見分かり
やすいようにtrue/falseを必ず書いて明確にするってのは
書捨てのコードじゃない限りは有用だったりする。

202 :仕様書無しさん:2015/06/23(火) 00:49:52.48
>>200
誰かのレスに反論した訳じゃないぞ。

203 :仕様書無しさん:2015/06/23(火) 00:59:51.86
>>201
「(書かないと分かりにくい場合に)ぱっと見分かりやすいようにtrue/falseを書いて明確にする」
ならわかるが

なんで全部に書かないといかんのだ?
書くべき場合、書くべきじゃない場合があるんだから
それに応じて適切な書き方をすればいいだけだろ。

そこがだめなコーディング規約の、だめなところなんだよ。
ルールを作ることが目的となってしまい。
何故そうするかを考えてないから、

「ルールなんて、とりあえずなにか決めておけばいいんだよ。
例外がある?知らない。そんなことま考慮してルールを作るなんて面倒くさい」

って重要な規約づくりを、適当に終わらせてしまう。

そんな規約ならないほうがまだまし。

なお俺のおすすめは、標準的な何かのルールをツールを使って確認する方法。
設定はなるべくデフォルトで特別な理由がなければ好みだからとかいう理由で変えたりしない。

204 :仕様書無しさん:2015/06/23(火) 02:43:16.83
うちの会社なんて補助ツール(構文解析、ファイル自動整理、ログファイル読み込み、内容変換、文法解析、テスト用通信、その他もろもろ)がPerlなんだが、

-------------------------------------------
#logfile例
aaa 100 AZX日本語文字列A
aab 100 NFZ日本語文字列B
aba 110 BXK日本語文字列C
------------------------------------------
@all = <FILE>;
push @all, [ /^([a-z]{3})\ ([0-9]{3})[\ \ ]+([A-Z]{3})(.*)$/ ] foreach(@val);
## print(join( ', ', @$_) . "\n") foreach(@all); #テスト用出力
-------------------------------------------
全部こんなん。
社員はPerl使えるんで当たり前のように読み書きするが、
臨時社員とか派遣とか発狂してる。

「それ開かなくていいから用途に応じてダブルクリックするだけでいいよ」
って言ってるけどな。

205 :仕様書無しさん:2015/06/23(火) 03:05:16.91
>>204
あぁ、酷いね。Perlらしくないコードだ

正規表現をそのまま直書きするのは、殆どの場合だめなパターンだって思ってるよ。
どうせその例は短い正規表現で、長い正規表現の場合も、同じような書き方なんだろう?
この場合の一番いい方法は、正規化の部分を関数化すること

変数名だけじゃなく、関数名にも処理にもわかりやすい名前を付けないと駄目なんだぞ。

もう一つ、変数の内容を直接出力するのもあまり良くないな。出力は最後にまとめてだ。
(そのコードで他に処理があるかどうかはわからんからなんと言えんが)

あとな、それmap使え。後置のforeachを使うことは殆ど無い。

そのコードだったらこう書くべきだろう。

sub 何のパターンかわかりやすい名前 { [/^([a-z]{3})\ ([0-9]{3})[\ \ ]+([A-Z]{3})(.*)$/] }
@all = map { 何のパターンかわかりやすい名前 } @val;
$text = map { join(",", @$_) } map @all;
# オプション見てテキストなりファイルに出力


社員はPerlを使えるという、最低限の第一歩は踏み出しているようだが、
わかりやすいコードを書くという、レベルには到達していないようだな。
分かりにくいコードに慣れてしまって、それが分かりにくいと分からないかわいそうなパターン

206 :仕様書無しさん:2015/06/23(火) 03:09:08.56
あ、間違えた。(というか書いている途中)

$text = join('\n', map { join(',', @$_) } @all)

207 :仕様書無しさん:2015/06/23(火) 08:05:23.27
>>203
完璧な規約なんてあるんなら、完璧な仕様の言語も当然あるよね。教えて?

馬鹿はすぐ0か1かの極論に走るからビジネスできない。

208 :仕様書無しさん:2015/06/23(火) 08:25:46.68
>>203
> 書くべき場合、書くべきじゃない場合があるんだから
誰も彼もが正しくその場合を判断できるわけでも、担保できるわけでも
無いからな。 そもそも一週間前に書いた自分のコードだって正しいと
担保できる人間なんてそういないし、担保できるならその人はまるで
成長していないだけかも知れんし。

>って重要な規約づくりを、適当に終わらせてしまう。
こういうのは今までの積み重ねと、組織とあなたの力量、ポジション
次第だからなんとも言えん。批判や綺麗事を言うことなら誰でも
出来るし、口だけの人間なのかなんて周りが判断するし。

209 :仕様書無しさん:2015/06/23(火) 08:43:50.43
>>207
> 完璧な規約なんてあるんなら、完璧な仕様の言語も当然あるよね。教えて?

誰が完璧な規約があるなんて言ってんの?

そんなのを求めるな。無いからって自分で
作ろうとするなって話をしてるんけど?

自分で無理やり作ろうとするから、
意味のないルールまで作ってしまって
逆に作りにくくなってしまう。

210 :仕様書無しさん:2015/06/23(火) 08:56:46.68
>>208
> そもそも一週間前に書いた自分のコードだって正しいと
> 担保できる人間なんてそういないし、担保できるならその人はまるで
> 成長していないだけかも知れんし。

当たり前。というか一般論として、人は成長するもので過去に書いたものより
今のコード、今のコードよりも未来のコードのほうが良くなってるもの
(便宜上コードと書いたが、設計やテスト等でも同じ)

それはコーディング規約を作るなどということにも当てはまって、
過去に作ったコーディング規約は、成長前の知識で作ったもので
成長した今は正しくない可能性が高い。

だから自分で作るなって話。少なくとも世の中で広く使われており、
それを判定するツールが存在するものは、広くレビューされているわけで、
自分で作るよりも何倍も正しい。

それを無視して、自分で考えることが
「重要な規約づくりを適当に終わらせてしまう」こと
だって言ってるんだよ。

世の中の規約で「こういう場合はこうすること」と書いていないものは
世の中の規約が適当だからじゃない。考えぬいた末に、
それは規約として定めることではないと判断したから、あえて書いてないんだよ。

そういうものに対して、ルールが無いから自分でルール考えました。なんてことをやるな。
自分で考えたルールには穴がある。

211 :仕様書無しさん:2015/06/23(火) 09:04:24.22
そもそも、各言語で普及している一般的な規約を
採用するだけのほうが、自分で考えるよりも何倍も楽なのに
なんで自分で考えようとするのか理解できん。

それこそ、開発しやすくするためやるべきことが、
ルール作りが目的になってんじゃねーの?って思う
ルールさえできれば、中身はどうでもオッケーみたいな。

コーディング規約なんか、○○を採用します。その規約に適合するかの
チェックには○○を使います。これをCIやビルドやテストツールに
組み込んで自動チェックします。で終わりじゃん。

212 :仕様書無しさん:2015/06/23(火) 10:20:17.78
>>205
こういう趣味とか、僕の考えた最強の美しさ、なんてのを主張しだす馬鹿が
現れると崩壊するよね。

213 :仕様書無しさん:2015/06/23(火) 10:24:55.17
>>212
それで内容に対して、何か言及はしないの?
少しは内容に対して言い返そうよ。

それだとなんかムカついたから
大人はみんなそーなんだーって言ってるだけだよ

214 :仕様書無しさん:2015/06/23(火) 10:53:29.78
>>212
単に無駄がなくて意味がわかりやすいのが
良いコードってだけでしょ?

215 :仕様書無しさん:2015/06/23(火) 11:00:47.04
コーディング規約はこれ、と別のプロジェクトで作った(そのまんま)ものを渡してくれて、規約に合わせて書き直そうとすると、別のプロジェクトの規約だから必ずしも、守らなくていいとかいう、どっちやねん的なもの。

あと、その規約には書いてないけど、goto禁止なとかいう、指示。

216 :仕様書無しさん:2015/06/23(火) 11:09:19.78
>>214
だから、そういう主観で片付かないから変な社則やコーディング規約ができるわけ。
キミの主観は統計的に多数を占めている意見なのかもしれないけど、それが
おかしな規則ができる場所において正しいか、という意味では、それが多数派で
あろうとなかろうと意味をなさないわけ。

217 :仕様書無しさん:2015/06/23(火) 11:20:56.12
>>216
変なコーディング規約を作るぐらいなら
コーディング規約を作らなければいいじゃない?

コーディング規約は採用するもの。
決まっているルールは守るべきだが、
そこで決まってないことは何をしてもいい。

218 :仕様書無しさん:2015/06/23(火) 11:30:21.37
コーディング規約で決まってないから何をしてもいいが
わかりやすいコードを書くようにするのは当たり前の話。

わかりやすいコードっていうのは、場合によって変わるものなので
どちらがいいと決めることは出来ない。
だからこれはコーディング規約にはできない。


そもそもの話、コーディング規約はわかりやすい
コードにするためのものじゃないんだよ。

コーディング規約で決めることはおおまかに以下のもの

・どちらでもわかりやすさに影響はないが、統一しておきたいもの
(改行とかスペースとか、命名規則とかそんなの)

・禁止事項
コードが悪いという理由が明確に示せるもの
「わからない人がいるから」はコードの問題じゃないので
これを理由にするのは不可。


これらは客観的に決めることができるからコーディング規約にできる。
だけど「わかりやすいから」というのは場合よって変わるものなので
これを理由にコーディング規約にするのはだめ。

219 :仕様書無しさん:2015/06/23(火) 12:22:07.21
愚痴と理想ばっか語ってねーでさっさとリーダーになれば?
使い捨ての派遣君かな?

220 :仕様書無しさん:2015/06/23(火) 12:26:15.95
お前らの最強コーティングルールはどうでもいいから笑えるルールを晒せや

221 :205:2015/06/23(火) 12:29:10.95
>>212
正解。少なくともうちにはそれがいないのでPerlだらけ。いいのか悪いのかは知らないけど。
4年働いてPerで規約問題が発生してるのをみたことないし、たぶん規約もない。(たぶんっつーのはその機会に直面したことがない)

今見たら、社内用のPerlだけで1611ファイルあった。日付でソートしたら一番古いのは1991年だったw
とりあ今一番気になったのは「xxx社(他社)用C解析__Convert.pl」 。会社別に7ファイルもある。

>>213
当事者として言わせてもらうと、たぶんだが「じゃあやれ」ってなるな。
訳 → 口を動かすより先に手を動かせ。本業に支障が出ないようにやれ。それぞれのスクリプトの担当者にちゃんと話しは通せよ。
    問題は発生してないから給料は出ないよ。問題が発生した場合は責任を負うこと。
でもたぶん勝手に書き変えたのを社内サーバーに混ぜると苦情くるし、信用の問題から全員古いほう使うぞ。

222 :204:2015/06/23(火) 12:30:43.22
まぁ自分の番号間違えた。204な

223 :仕様書無しさん:2015/06/23(火) 12:32:27.39
>>219
> 愚痴と理想ばっか語ってねーでさっさとリーダーになれば?
最近そんな感じになってるよ。
技術力の底上げとかしてる。

開発、ソースコードのレビューからCIやテスト、
インフラ関連に最新技術の導入を行ってる。

224 :仕様書無しさん:2015/06/23(火) 12:37:11.30
>>221
> 口を動かすより先に手を動かせ。本業に支障が出ないようにやれ。
それを実現してきた結果だろうな。

(新プロジェクトの)現在のソースコードではメンテナンス性が悪くて、
これから必ず支障が出ます。手遅れになる前に問題点の修正を行うべきです。という
俺の提案があっさり通ったのは。


どうでもいいけど、かわいそうな会社だと思うよ。

会社のためになる素晴らしい提案だけど、責任取るのが嫌という理由でやりません。
という決断をする会社は。

225 :仕様書無しさん:2015/06/23(火) 12:45:16.45
>>221
> 4年働いてPerで規約問題が発生してるのをみたことないし

発生している問題を問題だと認識できてないかもしれないね。


例えば、新しい人が入ってきた時、
その人がコード見て苦しむとかねw


技術力が低いとか、その人自身に問題があるののなら

勉強しろで終わりだけど、コード自体が汚い場合もあるからね。
例えば言語の高度な機能(俺にとっては簡単だろうけど)を
使ってないとかね。言語の機能ってのはほとんどが開発効率を上げるためのもの。

226 :仕様書無しさん:2015/06/23(火) 12:45:19.95
>>217
リアルで言ったら即効クビだぞ。

他人の家に土足で上がってはいけない法律はないからって土足で上がるようなことを
しでかしそうな馬鹿はいらない。批判したらアメリカでは〜みたいな愚にもつかない
こと言い出しそうだし、こういう知能レベルが低いクズとは仕事できないな。

227 :仕様書無しさん:2015/06/23(火) 12:49:46.58
>>226
かわいそうな会社だね。

コーディング規約を採用しただけで
クビになるなんてw

228 :仕様書無しさん:2015/06/23(火) 12:50:03.48
>>218
>・どちらでもわかりやすさに影響はないが、統一しておきたいもの
>(改行とかスペースとか、命名規則とかそんなの)

ものすごくわかりやすさに影響してくると思うけど?
人によってわかりやすさが違うから、強制的にルールで統一してるんだよ。
わかりやすさは場合によっても違うが、人による違いがやっかいで宗教論争に
なるからルールをつくるんだ。

229 :仕様書無しさん:2015/06/23(火) 12:51:22.19
>>227
ルールにないことは何をしてもいい、なんて言ってもクビにならない会社ってあるの?

230 :仕様書無しさん:2015/06/23(火) 12:51:51.14
>>228
自分で言ってるじゃんw

宗教論争の範囲(=どれがいいと断定できない)
だから統一したいって。

231 :仕様書無しさん:2015/06/23(火) 12:53:02.60
俺の会社はまともで良かったと思う。
規約じゃなくてお前らを見てると本当にそう思う。

232 :仕様書無しさん:2015/06/23(火) 12:54:12.62
>>229
> ルールにないことは何をしてもいい、なんて言ってもクビにならない会社ってあるの?

会社の文化次第だろう?

既存のルールにとらわれずに新しいことにどんどん挑戦すべきだって会社もあるだろう。

全てがマニュアル化され、そのとおりにしかやらないと駄目。
提案なんてもっての他だっていう会社もあるだろう。

233 :仕様書無しさん:2015/06/23(火) 12:55:38.68
決めなくていいこともまでわざわざ決めて
意味もないルールを守ることを強制されるような
会社じゃなくてよかった。

234 :仕様書無しさん:2015/06/23(火) 12:59:23.59
おまえら社内でそんなやり取りしてんの?

235 :仕様書無しさん:2015/06/23(火) 13:05:26.34
どうでもいいけど、おまえら

Aだ
いや違うAだ
バカかAだろ

という話をしているように見えるけどバカなの?
最後にレスした人が勝ちのゲームしてるの?

236 :仕様書無しさん:2015/06/23(火) 13:06:26.23
いや違う。バカだろ。

237 :仕様書無しさん:2015/06/23(火) 13:35:16.91
そうか? おれはバカだと思うが。

238 :仕様書無しさん:2015/06/23(火) 18:54:57.18
流れを読まずに言うと、PGReliefはウンコ。

239 :仕様書無しさん:2015/06/23(火) 20:49:22.93
>>238
UIのやる気のなさが目を引く

240 :仕様書無しさん:2015/06/23(火) 21:11:09.72
矢野はなんか持ってる

241 :仕様書無しさん:2015/06/23(火) 23:26:50.19
>>236-237

山椒魚 vs 小海老の戦いを彷彿。

242 :仕様書無しさん:2015/06/25(木) 02:14:42.35
ほんとは
テストコードを書け
だけで終わる話

243 :仕様書無しさん:2015/06/25(木) 04:08:00.38
>>211に完全に同意だわ

244 :仕様書無しさん:2015/06/25(木) 07:29:41.41
>>211
インデントや、カンマ前後のスペースの置き方なんて事は、その言語を使えなくても持論を書き込めるからな。

245 :仕様書無しさん:2015/06/25(木) 08:27:59.05
>>243
どうもw

>>244
そんなものこそ決める必要がないことですよw
自分の好きなやり方はありますが、
採用する規約で決まってるなら、そのデフォルトに合わせます。

(見やすいならば)一番どうでもいいところで、だれでも簡単に
決められることだから、自分で作りたくなっちゃう所ですよねw

これにこだわりだしたらルールを作ることが目的になってる兆候です。

246 :仕様書無しさん:2015/06/25(木) 09:57:49.58
郷に入れば郷に従うタイプだが
GNUスタイルだけは受け入れる自身がないわ・・w

247 :仕様書無しさん:2015/06/26(金) 08:36:00.09
あれはほとんど更新されてないしGNU Projectで守ってない奴も結構ある。

248 :仕様書無しさん:2015/06/26(金) 20:13:15.66
ユニットテスト禁止。
理由は「難しい」から。

俺の書いたソースがトランザクションスクリプト風に書き直されてた。
理由は「クラスとか関数に分けすぎて、読みにくいから」

249 :仕様書無しさん:2015/06/26(金) 22:28:18.41
ただ分けりゃ良いってもんじゃない。
それは判ってるよね?

250 :仕様書無しさん:2015/06/26(金) 22:31:31.80
>>248
死んでほしいな…

その会社は今すぐ辞めたほうがいい

251 :仕様書無しさん:2015/06/26(金) 22:37:14.91
>>249
お前わかってなさそうw

252 :仕様書無しさん:2015/06/26(金) 22:47:50.19
プログラムは文章みたいなもの。
分けるときは章立て段落立てをして
抽象度が上がるように分ける。

文脈を無視して文章を細切れにするのは一知半解。

253 :仕様書無しさん:2015/06/26(金) 22:49:23.26
それもこれも、何のためにやるのかを判ってないからだな。

254 :仕様書無しさん:2015/06/26(金) 22:57:30.66
最近関数が長くなった時
プライベート関数に分けるのは
ダメなやり方だってわかった。

関数が長くなった時にやるべきなのは、
別のファイルにパブリック関数として分ける

別のファイルっていうのが別のクラスだったり
そうでなかったりするがそれはどうでもいい。
そして別のファイルには意味がある名前をつけること。

255 :248:2015/06/26(金) 23:02:09.13
>>250
自社じゃなくて、客先なんだ。

>>249
だいぶ前の話だから、今より稚拙だったとは思うけど、単に前半後半に分けるとか、そういうことはしてないよ。
共通部分を抽出したり、ビジネスロジックのドメイン単位でモデル作ったり、そんな感じ。
多少なりともオブジェクト指向かじってるのが、俺一人だった。

ちなみに、ユニットテスト禁止した人と、勝手にコード書き直した人は同一人物(サブリーダー)。

256 :248:2015/06/26(金) 23:06:17.47
あ、あと変数名も変えられてた。

良い例が思いつかないんだけど、
「RowCount」みたいなのが、
「Iint_c1」みたいな感じに。

257 :仕様書無しさん:2015/06/26(金) 23:07:20.12
複雑度計測して、なんで複雑にするんですか?って
言ってやれw

258 :仕様書無しさん:2015/06/26(金) 23:08:47.91
何も判ってない奴に駄目出しされると発狂しそうになるよね

259 :248:2015/06/26(金) 23:12:00.77
>>258
そのプロジェクトで白髪むっちゃ増えたww

260 :仕様書無しさん:2015/06/26(金) 23:15:37.85
>>256
あんたより、世界の常識、
プロの常識を信じますって言ってやれw

261 :仕様書無しさん:2015/06/26(金) 23:20:00.60
>>256
地獄だなw

262 :248:2015/06/26(金) 23:24:25.96
>>260
プロジェクト初期に「ユニットテストの解説を読んだけど、難しいから禁止です」って言われた時点で、説得は諦めたよww

263 :248:2015/06/26(金) 23:29:05.35
>>261
俺の経歴の中ではマシな方だよww
メンバーみんな(サブリーダーも)、技術力はともかく性格は良かったし。

264 :仕様書無しさん:2015/06/27(土) 01:53:59.63
xUnitとかのテスティングフレームワークを使うのは形から入ろうとすると
難しい言葉並べてハードルが高く見えるからな。単純にprintfデバッグを
中じゃなくて外に書いてまとめて実行するものですよくらいのものですよ
とか言っておけばハードルを越えようとしてくれるだろうに。
javaなんて前準備、後処理が面倒だから依存性減らしてPOJOにするべ
とか言ってサボろうとしてる部分もあるし。

265 :仕様書無しさん:2015/06/27(土) 06:27:19.68
>>262
え? こんな程度も分からないの?
あんたはわからないの?
技術力低すぎじゃね?って言ってやれw

この会社は難しいからという理由で
生産性を上げることを禁止する会社なんですかって
言ってやれw

266 :仕様書無しさん:2015/06/27(土) 06:30:36.42
ここまで読んで俺が思ってるユニットテストと
その会社が言ってるユニットテストの意味が違うんじゃないかと思えてきた
詳しく説明してくれないか

267 :仕様書無しさん:2015/06/27(土) 06:40:02.52
>>265
多分煽っても無駄だよ
本当にレベル低い人が沢山いて
そんなもの導入したら、いなくなったときに他の人が対応できないレベルなんだろ

「馬鹿で安いエンジニア」を沢山集めて
「質に無頓着な客」から仕事を受けて稼ぐってビジネスモデルだから
そこを改革しようとしてもいい迷惑なんだよ

馬鹿に染まれないなら早く会社変えるべき
自社じゃないとか言い訳しないで、派遣されるような仕事を辞めるべきなんだよ

268 :仕様書無しさん:2015/06/27(土) 06:53:53.09
普通は、ユニットテスト=単体テストしてないコードは
コミットすんな。なんだろうけどね。

そういう意味じゃないかもしれん。
「コンピュータサイエンス」かぶれが
どっかで拾ったテストツールを強要したんじゃね?

269 :仕様書無しさん:2015/06/27(土) 07:22:38.35
>>267が余りにも的確すぎてワロタ

270 :仕様書無しさん:2015/06/27(土) 07:43:10.94
>>267
この業界9割方そのビジネスモデルだから困る
どうすれば良くなるんだろうね……免許制?

271 :仕様書無しさん:2015/06/27(土) 08:00:21.25
バカでも出来るってやり方は間違ってはいない。
但し、バカに道筋を与える側の人間までバカであってはならない。
要するにお前らレベルのバカが、導く側の人間だと勘違いしている事が大きな問題。

272 :仕様書無しさん:2015/06/27(土) 08:26:55.74
>>270
SIは業界ごと潰す。
改善を期待しない。

273 :仕様書無しさん:2015/06/27(土) 13:11:27.12
ユニットテストなら俺もひとつネタがあるぜ。

プロジェクトの全モジュール、全ライブラリをリンクさせないと流すことができない謎のテストシナリオ。
プロジェクトリーダーは、ユニットテストは凄い!万能!ってひたすらシナリオを書きつづけていた。

プロジェクト完了までに、テストが完走したのは2回しか見た事がない。
もちろんテスト結果は言わずもがな。

274 :仕様書無しさん:2015/06/27(土) 15:44:39.98
>>273
テストが完走したのが2回でも開発終了に出来るように
開発回しただけいいんじゃね?
カバレッジ厨みたいなのがいて、何が何でも全網羅する
テストを書きなさいそうしないとレビュー通しませんみたい
なのがいるほうが厄介だよ。

テストコードとはいえコードなんだからバグのないテストコード
だと担保するにはテストコードのテストコードが必要な無限
ループに入る。そうしないのはテストコード自体が依存性が
少ないプアなコードだという原理原則に基づいているから。
全く書かないのは問題だけど、全てというかそれに近い量の
コード書けってのも別の意味で思考停止だよ。

275 :仕様書無しさん:2015/06/27(土) 16:45:18.05
自分が主導してユニットテストとci回すようにしたが、正直テスト書くのと保守するのがめんどくさい。

276 :仕様書無しさん:2015/06/27(土) 18:33:26.11
>>274
> テストコードとはいえコードなんだからバグのないテストコード
> だと担保するにはテストコードのテストコードが必要な無限
> ループに入る

テストコードのテストは、アプリのコードだろ?
アプリが正しくて、テストコードがバグっていれば
同じようにテストが失敗するわけなんだから。
その他の部分に関しては同意するけど。

> 正直テスト書くのと保守するのがめんどくさい。
それはテストが単体テストになってないからだろうね。
一つの修正で影響する部分がたくさんある。

最初にテストを書くときはやる気あるだろうけど、
その後の保守が大変になるのは、依存関係が多すぎるから。

テストコードっていうのは、既存のコードにプラスして導入できるものじゃない。
テスト可能なコードにしてから、テストをする必要がある。だから高い技術力が必要。
(というかこの程度で高いって言うのは恥ずかしい話なんだが低い奴が多いので)

あとテストコードのテストコードの話に戻るけど、テストコードは目視で確認するものだろう?
テストコードを見て、そのテストが問題ないかどうか判断するもの。
それが出来ない人や出来ないコードが多すぎる。それは可読性の話だよ。

実行して手動で動かしてちゃんと動いているか確かめるんじゃなくて、
コードを読むだけで確かめられるようにしなきゃダメ。できるようならなきゃダメ。
他人のコードを読んでレビューできない人が多い。

277 :仕様書無しさん:2015/06/27(土) 18:54:43.88
一行目から違ってる長文は読む気がしない

278 :仕様書無しさん:2015/06/27(土) 19:17:42.36
読まなくてもレスしたいんですねw
レスしたい内容がないなら、レスしなくていいんですよw
出来ないのと同じですから。

279 :仕様書無しさん:2015/06/27(土) 19:27:29.33
レスしたい内容は長いってことだろ。

280 :仕様書無しさん:2015/06/27(土) 20:07:03.78
>>276
>テストコードっていうのは、既存のコードにプラスして導入できるものじゃない。
> テスト可能なコードにしてから、テストをする必要がある。だから高い技術力が必要。

少なからずこういう意識高い系の勘違いテスト厨がいるから自動テストの
導入が進まないんだよなあ。だいたい完全新規のシステム開発なんて
早々ないのに、既存のコードにプラスして云々(キリッ、じゃねえだろ。

とりあえず自分の担当しているところで試してみて、出来そうな部分と
出来なさそうな部分を試行錯誤しながら小さく、繰り返しながら試して
いくようなやり方が出来ないような奴はダメだよ。

281 :仕様書無しさん:2015/06/27(土) 21:04:02.74
状態を持つからテストしにくいんだ。
全部関数型で書こう。

282 :仕様書無しさん:2015/06/27(土) 21:09:46.58
>>280
>>276と同じことを言ってるように思えるけど・・・

283 :仕様書無しさん:2015/06/27(土) 21:15:39.00
テストなんかプログラマの自己満足ですよ

284 :仕様書無しさん:2015/06/27(土) 21:15:42.05
自分の会社(組み込みC言語の開発)では,そもそもコーディングルールがない.

一方で,風習はなんとなくあって,制御用のパラメータ変数は1ファイルに
グローバルで定義して,それをヘッダー使って全コードで共有するってのがある.

なので,関数は基本的に引数を持たず,あちこちでグローバル変数が使われて
副作用だらけ.

285 :仕様書無しさん:2015/06/27(土) 21:31:55.00
とりあえずTabキー定義した奴は死刑な。

286 :仕様書無しさん:2015/06/27(土) 21:55:47.09
>>280
あのね。既存のコードにテストコード書いた結論で言ってるの。
既存のコードが汚ければ、つまりよくあるモジュール化されてない
複雑に絡み合ったコードであれば、テストコードは書くのがとても困難なの。

単体でテストできないコードは、結合された状態でテストコード書かなければならない。
結合された場合だと、長いコードの中で幾つもの条件分岐を通るから
一つの処理に対するテストコード自体がとても複雑で膨大になってしまう。

そうならないようにするには、各箇所を小さくモジュールにしなければいけないのだけれど
そもそもなんで元からそうなっていなかったのか?
自動テストのことを考えなかったとしても、小さくモジュール化することは
ソフトウェア開発のベストプラクティスなわけで、それをしていない=出来ない=できる技術力がない
ということなわけ。

そういう人が、テストコードを導入しましょうと言った所で、
技術力不足でテスト対象のコードを小さく保つことが出来ないんだから、
コストに見合わないテストコードになるんだよ。
さっきも言ったとおり、テストコード自体がとても複雑で膨大になる。

技術力がないから、小さく、繰り返しながら試していくようなやり方ができないんだよ。
関数書く、テストコード書く、関数を伸ばす、テストコードを増やす、
関数をさらに伸ばす、ますますテストコードを増やす。
どんどん関数を伸ばす、テストコードもどんどん増える。

既存のコードっていうのは、どんどん関数を伸ばしきったもの。
それをそのままにして、テストコードをプラスする?
どんどん増えたテストコードを、書けるわけないじゃないか。

完全新規のシステム開発なんてないからこそ、既存のコードに対するテストコードしか書けない。
既存のコードにテストコードを書くには、テスト可能なコードに直さないと無理。

287 :仕様書無しさん:2015/06/27(土) 21:56:32.17
>>284
> 自分の会社(組み込みC言語の開発)では,そもそもコーディングルールがない.

コーディングルールは作るものじゃない。
採用するものだ。

288 :仕様書無しさん:2015/06/27(土) 21:59:13.04
リファクタリングを行うにはテストがなければいけない。
テストを作るにはリファクタリングしなければいけない。
デッドロックである。

つまり、リファクタリングはどっかの頭でっかちが考えた
非現実的な代物ってことはみんなわかってるよね。

289 :仕様書無しさん:2015/06/27(土) 21:59:57.64
>>287

ちょっとアスペっぽいかな。

290 :仕様書無しさん:2015/06/27(土) 22:01:07.34
>>289
で?

291 :仕様書無しさん:2015/06/27(土) 22:03:00.55
>>290
自分を見つめ直して更正しろブタ野郎。

292 :仕様書無しさん:2015/06/27(土) 22:06:02.96
>>288
その話の問題点は、技術力が低い所が書いたコードは
テストを書くにはあまりにも大変すぎるコードばかりだってことだな。

本来は、リファクタリングやテストなんぞ考えなくても、
コードを小さく保つことは当たり前。

その当たり前のことができていないから、テストをかけないし
リファクタリングも出来ない。

問題外のレベルの奴らが多すぎるんだよ。

だからリファクタリングの前に技術力を上げることが大事。
おそらくコードメトリクスって概念もないんだろうね。
循環的複雑度が30前後なら十分リファクタリングは行えるだろう。

だけど問題外のレベルの奴らだとテスト不可能と言われる
50を超えるものを作り出す。

293 :仕様書無しさん:2015/06/27(土) 22:06:54.50
>>291
ぶ?

294 :仕様書無しさん:2015/06/27(土) 22:08:55.63
>>293
ぶひ?

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

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

296 :仕様書無しさん:2015/06/27(土) 22:25:03.93
× 俺はSIerで働いているけど自動化テストは重要視されてない。
○ 俺はSIerで働いているけどテストにどれだけ時間かけても問題視されない。

実に羨ましいねw

スクリーンショットはるだけで数日かけても
何も文句言われないないんて。

こっちは自動化して全部のスクリーンショットをとっても
時間は十数分程度なのに。

あ、文句言われるかどうか以前に、俺は
手作業でつまらない作業を繰り返す苦痛に耐えられないわw

297 :仕様書無しさん:2015/06/27(土) 22:30:05.81
>>295
> 処理を書き換える予定がないなら関数を分ける必要はないのじゃないか。
> 関数分けると結局このインスタンス変数どこで使われてんだよってことになるよ。

何言ってるんだろうか?

お前は工場でLED作ってる人が、このLEDはどこで使うんだろうか?って
気にすると思ってるのか?

関数に分けるということしか知らないから、使われている所を
気にしないといけないような分け方をしてしまうんだよ。

関数に分けるんじゃなくて、役割を分けるの。
役割を分けて、どこで使われているのかを意識しないようにする。

つまり君、ダメ。技術力無い。

298 :仕様書無しさん:2015/06/27(土) 22:30:13.37
ルーチンワークの苦痛に耐えられない奴はそもそもクリエイティブな仕事に向いてないんだなこれが

299 :仕様書無しさん:2015/06/27(土) 22:30:19.51
>>296
まあ、下を探したくなる気持ちは判るけどさ、スクリプトであっという間に終わる作業担当から早く抜け出た方が良いよ。

300 :仕様書無しさん:2015/06/27(土) 22:32:10.31
>>296
テストのエビデンスは、ソフトウェアをソフトウェア製品に
仕上げる過程の中で処理が行われることの保証って位置づけなんだよね。
だから、面倒でもやらなければいけない。

どれだけ時間かけても問題視されないってことはないよ。
期限は結構厳しい。だからテスト期間中だけ5倍位人員が増える。
その人数でいっきに仕上げてる。テストケースを作るのは少数のベテランの人。
オールペアとかドメイン分析とかやって効率よくテストできるようやってるつもり
なんだけど、いかんせんSIerで扱うソフトウェアは規模が大きいからね。大変なのはしかたない。

301 :仕様書無しさん:2015/06/27(土) 22:32:25.20
>>298
> ルーチンワークの苦痛に耐えられない奴はそもそもクリエイティブな仕事に向いてないんだなこれが
それ、逆だよ。

プログラマにとってのクリエイティブとは
ルーチンワークを自動化することなんだから。

>>299
> スクリプトであっという間に終わる作業担当

あ、スクリーンショットはるお仕事ですねwww
スクリプトであっという間に終わらせてすみませんwww

302 :仕様書無しさん:2015/06/27(土) 22:33:18.66
>>300
> だから、面倒でもやらなければいけない。

だから自動化してやるって言ってるんでしょ?
同じことを君は面倒だと思ってるわけだ?



もしかして自動化するのが面倒だからやらない?

303 :仕様書無しさん:2015/06/27(土) 22:34:05.88
>>301
> ルーチンワークを自動化することなんだから。
これこそつまらない作業の典型

304 :仕様書無しさん:2015/06/27(土) 22:34:27.28
>>300

× どれだけ時間かけても問題視されないってことはないよ。
期限は結構厳しい。だからテスト期間中だけ5倍位人員が増える。


○ どれだけ時間かけても問題視されないってことはないよ。
期限は結構厳しい。だからテスト期間中だけコストを5倍にしても問題視されない



コストを掛けても問題視されないなんて
羨ましいですww

305 :仕様書無しさん:2015/06/27(土) 22:35:15.51
>>303
ルーチンワークのほうがつまらないでしょwww

306 :仕様書無しさん:2015/06/27(土) 22:36:59.33
>>302
顧客が見てわかるような形のものを納品しなきゃいけないから
出力のスクリーンショットをとらなきゃいけないんだよ。
そこまで含めて自動化するよりは人海戦術でエイヤでやった方が
コストが低くなるんだよね。

面倒といったのはテスト結果としてのスクリーンショットを納品物として
扱わなきゃいけないところのこと。

307 :仕様書無しさん:2015/06/27(土) 22:37:41.33
GoogleとかMicrosoftとか
大手はどこも自動化しているものと思っていたが、
ちいさい所はだめだな。

ちいさいというかソフトウェア開発能力が低いというべきか。
会社自体は大きくても、別で儲けていて
ソフトウェア開発能力が低い所は多いし。

308 :仕様書無しさん:2015/06/27(土) 22:37:45.52
>>305
ところがクリエイティブな結果を出すためにはルーチンワークの積み重ねは絶対的に必要なんだよ

309 :仕様書無しさん:2015/06/27(土) 22:38:27.55
>>306
> 顧客が見てわかるような形のものを納品しなきゃいけないから
> 出力のスクリーンショットをとらなきゃいけないんだよ。
はい、全部とっていますよ?

> そこまで含めて自動化するよりは人海戦術でエイヤでやった方が
> コストが低くなるんだよね。
え? なんで?w

理由が書いてないのは、理由がない証拠だよ。

310 :仕様書無しさん:2015/06/27(土) 22:40:43.90
>>308
> ところがクリエイティブな結果を出すためにはルーチンワークの積み重ねは絶対的に必要なんだよ

はい? そしてルーチンワークを自動化して、
自動化出来ない所に集中するわけですよね?
時間は無限じゃないし、コストも無限じゃないんですから。

そんなにルーチンワークが好きならば、
自動化している作業をどんどん手動のルーチンワークに
置き換えて行ったらいいんじゃないですか?
手始めにコンパイル作業を手作業でやるとか?w

クリエイティブになれますよw

311 :仕様書無しさん:2015/06/27(土) 22:41:59.18
エクセル使って自動計算なんて
クリエイティブじゃねぇ!

電卓使う事こそがクリエイティブだ!


↑クリエイティブを勘違いしている人。

312 :仕様書無しさん:2015/06/27(土) 22:42:48.07
>>304
SIerではテストってそれだけの価値があることなんだよね。
同じような作業の繰り返しで地味で基本つまらないから誰もやろうと思わない。
無料でソフト作って公開しますって人はいても、
無料てテストやって公開しますって人はあまりいないよね。
だから、企業はテストにお金を払ってやらせる。
テストはソフトウェアの製品としての品質保証のところだからやらないわけにはいかない。

テストケース考えられるようになるとすこし楽しくなるかな。
大変さも増すけど、ロジカルな仕事って感じ。

313 :仕様書無しさん:2015/06/27(土) 22:45:45.89
>>310
> はい? そしてルーチンワークを自動化して、
> 自動化出来ない所に集中するわけですよね?
これはゴールの形が見えてる時のやり方。
そういうのはクリエイティブな仕事とは言わないんだよ。コーダー君。

314 :仕様書無しさん:2015/06/27(土) 22:46:01.26
>>309
俺の会社ではそうしてるって話で
そちらの会社の事情とは合わないところもあるかもね。

理由は、SIerでは人を集める方が簡単ってこと。

315 :仕様書無しさん:2015/06/27(土) 22:51:10.62
ほらみて、これみんな手動でやったの!
自動化したら簡単にできてつまらないでしょ?

何日もかけて、人を増やして手動で頑張ったんだよ。
凄いでしょ?凄いでしょ?

効率よりも努力だよ!

っていって認めてくれる客がいて羨ましいですwww

316 :仕様書無しさん:2015/06/27(土) 22:54:38.78
むしろテスト自動化なんかに価値を見出して金くれるバカ客がいたらお目にかかりたいわw

317 :仕様書無しさん:2015/06/27(土) 22:58:48.93
>>295
インスタンス変数は広義のグローバル変数だからな。
本当は引数と戻り値だけでやり取りするのが一番良いんだ。

318 :仕様書無しさん:2015/06/27(土) 22:58:55.13
>>315
手動か自動かはたぶん客は気にしてない。
テストをどうやるかは開発の内部のところだからね。
テストドキュメントには、こういう手順で
こういう操作を行ってこういう結果になりましたってことが書いてあって
ソフトウェアではそれを証拠に操作を保証してますって感じかな。

SIerの客って結構あれだからね。守秘義務にひっかかりそうだから
あまり具体的なこと言えないけど、規模とか権力とか結構大きいところが
多いからね。皮肉で言ってるんだろうけど、本当に羨ましいと思ったときには
SIerの玄関くぐればいいと思うよ。

319 :仕様書無しさん:2015/06/27(土) 23:03:56.46
プログラマが規模や権力など羨ましがるだろうか。
おもちゃのバッジを見せびらかすのは馬鹿に見える。

320 :仕様書無しさん:2015/06/27(土) 23:07:26.06
スクリーンショットを
納品かあ。
確かに変な規約だなあ

321 :仕様書無しさん:2015/06/27(土) 23:08:34.53
>>317
引数にしてしまうと大量の引数を引きずり回さなきゃいけないって
ことがあるんだよね。類似のものが何個もありますってのなら
分類してクラス分けして引数を減らすことに意義を見出だせそうな
気もするけど、どうせこれ作るの一回きりで修正することもないなってときは
関数をわけない方が見やすくてわかりやすい。

322 :仕様書無しさん:2015/06/27(土) 23:10:14.70
>>320
客はわかりやすいからね。この画面が表示されるんだって感じで。
客にプログラム見せてこれでいいだろって通じれば話は早いんだけど
残念ながらそんなお得意様がいまのところいない。

323 :仕様書無しさん:2015/06/27(土) 23:14:34.68
>>322
まあそれに相当する仕様書書いて
これでよござんすか、で始めるやり方
しかやったことないから。

324 :仕様書無しさん:2015/06/27(土) 23:14:42.44
>>319
そういう人も居るのじゃないかな。人間の本能に近いと思う。

会社で給料や役職が上がったら普段は興味ないと
思っていても少しだけ嬉しくなったりするものだと思うよ。
そういう状況に慣れてなくて浮かれて信頼失う人もいるから気をつけて。

325 :仕様書無しさん:2015/06/27(土) 23:17:21.50
>>321
問題の局所化が出来てないから
大量の引数を渡すことになるのかなー

実際問題そこまで悩んでられないてのは判るよw

326 :仕様書無しさん:2015/06/27(土) 23:18:23.85
>>297
俺はね、工場でLED作ってる人が、このLEDはどこで使うんだろうか?って
気にすると思っていないよ。でも気にする人がいても不思議じゃないとも思う。

327 :仕様書無しさん:2015/06/27(土) 23:21:31.45
>>325
そうかもわからんね。
プログラムを示せればいいんだけど、今の会社に未練がありまくりで
問題起こしたくないし似たようなコードをぱっと思いつくこともできないので能力的に無理。

328 :仕様書無しさん:2015/06/27(土) 23:29:22.43
テストやるルーチンワークを軽視すると多分ニトリみたいになる。
そこまでひどくなくても有料βテストかよとやゆされるようなシステムは
少なくない。 例えば金融系なんかでそういうちょっとした不具合で
システムが止まったりデータの不整合なんかが出た場合はいろいろ
面倒な作業が増えるから、今面倒なのと後でもっと面倒になるのが
分かるなら、それを回避しようとはするだろうな。

329 :仕様書無しさん:2015/06/28(日) 00:29:37.95
>>270
その9割に入るくらいなら別業界に行ったほうがマシなんだよ
そんなところに行くやつがいるからどんどん地位が下がる
モドキとプログラマーは別物だと自分達が自覚しなければいけない

免許なんて用意してる間に考え方自体が変わるから無駄だよ
プログラマ主導のレベルの高い集団に属するか
小さな会社で部門のトップになったほうが良い

しかし、随分伸びてるな

330 :仕様書無しさん:2015/06/28(日) 00:50:51.66
> その9割に入るくらいなら別業界に行ったほうがマシなんだよ

別業界に行っても、やっぱり9割方同じようなビジネスモデル
(低賃金で雇えるバイトや海外生産で稼ぐ)だったりするんだよなあ

331 :仕様書無しさん:2015/06/28(日) 02:29:25.03
おまえら>>1の話をしろよ
長文書く奴つまんねーぞ!

332 :仕様書無しさん:2015/06/28(日) 03:31:41.01
DBにdate型使用禁止ならあったな
全部文字列で入れといて、取り出す時に日付として正しいか毎回チェックするという

333 :仕様書無しさん:2015/06/28(日) 09:35:37.68
>>332
DBは全部varcharで、というところなら見たことがある。
indexもvarcharなんだ。
意外と性能はまともだったのは最近のDBすげーって驚いたけど。

334 :仕様書無しさん:2015/06/28(日) 09:42:13.75
>>333
全部varcharはCOBOLがもらたした
災いの一つだな。
あいつらろくなことしてくれない。

335 :仕様書無しさん:2015/06/28(日) 12:14:34.08
>>334 それ多分、配列だけで構造帯がない言語、例えばBasicとかFortranを主にやってきた人じゃない?

336 :仕様書無しさん:2015/06/28(日) 12:27:36.31
え? 構造体に何の関係が?

337 :仕様書無しさん:2015/06/28(日) 13:00:16.90
要素がぜんぶ同型にならざるを得ないから…ってことじゃない?

338 :仕様書無しさん:2015/06/28(日) 19:32:11.01
構造体は無駄なもの。理解出来ない。配列でいいだろ
http://kanae.2ch.net/test/read.cgi/prog/1332351657/

27: 仕様書無しさん [sage] 2012/05/16(水) 19:21:09.97

本物のプログラマなら誰でも知っているとおり、有用なデータ構造は配列しかないのだ。
http://www.geocities.co.jp/Milkyway-Orion/3324/prog/realprog.html

339 :仕様書無しさん:2015/06/30(火) 07:58:34.93
Fortran, COBOL, Basic,
このどれかだけにどっぷり浸かったやつはろくなの居ない。
とにかく何かが偏ってる。言語だけじゃなくて、文化的にも、作ってきた物的にも。
C民はバランスいい。あくまで組織の一員としては。

340 :仕様書無しさん:2015/06/30(火) 14:26:25.16
>>339
最近はそのリストにPHPもエントリ

341 :仕様書無しさん:2015/06/30(火) 17:23:50.12
プログラム言語じゃないですやん

342 :仕様書無しさん:2015/06/30(火) 21:16:53.24
スクリプト言語だからいいじゃん

343 :仕様書無しさん:2015/06/30(火) 21:35:12.24
似ても似つかないほど別物だが
物を分かってないのが混ざるから変なコーディング規約が出来るんだ

344 :仕様書無しさん:2015/06/30(火) 21:37:49.01
構造体禁止としか思えない
コード見たな

345 :仕様書無しさん:2015/06/30(火) 21:50:53.36
>>340
最近のPHPはかなりまともになってるよ。
他の言語を使っている人がほしいと思った機能がちゃんとある。

346 :仕様書無しさん:2015/06/30(火) 22:04:20.11
>>345
言語の問題だと思ってるならお前もかなりやばい奴だぞ

347 :仕様書無しさん:2015/06/30(火) 22:16:35.35
>>346
言語には問題ないって認めたってことでいいですか?

348 :仕様書無しさん:2015/06/30(火) 22:40:18.43
おそらくは言語どうこう以前の問題と言うことだろう

349 :仕様書無しさん:2015/06/30(火) 22:43:13.55
いえ私が言ったのは、PHPという言語には問題無いということなので、
その点だけをはっきりさせたいだけです。

350 :仕様書無しさん:2015/06/30(火) 22:45:04.75
言語どうこう以前に問題がある人に○○使わせたら
ハゲが直ってお金持ちになってモテるようになった!

なんてことがあるわけないので、

言語どうこう以前に問題がある人は
どの言語使っても、同じ結果ですよ。

なので、最近はそのリストにあなたが好きな○○言語もエントリしましょうw

351 :仕様書無しさん:2015/07/01(水) 00:16:31.43
>>347
言語にも問題があるが
ここでいう問題というのは使う側のレベルの低さの話だと言っている

352 :仕様書無しさん:2015/07/01(水) 00:22:17.93
>>351
使う側のレベルの問題だから
言語は関係ないですよ。
何言ってるんですかw

353 :仕様書無しさん:2015/07/01(水) 00:37:37.86
PHPは簡単なことを簡単に出来る良い言語だよ

354 :仕様書無しさん:2015/07/01(水) 00:40:38.18
ウェブプログラミングの入門書がPHPだったからという理由で
PHPしか使えない日曜プログラマーみたいな人が多い

PHPしか知らないから、PHPの言語仕様がいかに糞か理解できないで
ずっとPHPだけを使い続けてる

言語仕様も利用者層もどっにも糞

355 :仕様書無しさん:2015/07/01(水) 00:52:44.36
ここでいう問題というのは使う側のレベルの低さだから
言語関係ないって言ってるよね?

356 :仕様書無しさん:2015/07/01(水) 01:12:46.24
>>286
スタブ関数作って
モノホンの関数つかわないでテストすれば
そこそこ楽だよ

357 :仕様書無しさん:2015/07/01(水) 01:15:26.06
>>295
スクリーンショットて許されるテスト結果

なに作ってるのか興味ある

358 :仕様書無しさん:2015/07/01(水) 01:58:20.40
>>356
スタブの問題点は本物の関数じゃないから、
本物の関数のほうの仕様が変わっても、
スタブの方は変わらないから、
古いコードでテストが通ってしまう。
で本物の関数を使った時、エラーが発生する。

359 :仕様書無しさん:2015/07/01(水) 01:59:31.34
>>351 言ってねぇ。文化圏の問題

そしてPHPは問題外として最初から採り上げるべきではない。
プログラムじゃないから。
それが分からんくて規約も仕様も話もひっかきまわすのがおるんだよ

360 :仕様書無しさん:2015/07/01(水) 02:10:38.94
>>359
いいかげんにしろ
ここでいう問題というのは使う側のレベルの低さの話だと言っている
言語は関係ない。

361 :仕様書無しさん:2015/07/01(水) 02:14:58.90
元々俺が言ってねぇっつってんだから言ってねぇんだよ

362 :仕様書無しさん:2015/07/01(水) 02:23:41.03
PHPで恥ずかしげもなく話しに花咲す神経がわからんな
いつまでやってんのか知らんがいいかげんにすんのはおまえだろう

これについて使用者のレベルと言語の完成度はどちらも関係ない
そして元々そんな言語の話しはしてない

363 :仕様書無しさん:2015/07/01(水) 02:52:13.13
日曜プログラマでもリーマンプログラマでも最初の1〜2年の知識で
成長が止まる人が多い。 現実問題として目の前の問題をただ
力技で解決するくらいだとそれくらいで済むというのがその成長が
止まる理由なのだが。 コーディング規約を気にして殴り合いの喧嘩を
するようなのはそれよりもちょっとだけマシなのかなあと思ったり。

364 :仕様書無しさん:2015/07/01(水) 02:59:43.89
学級崩壊と変わらんよ。

365 :仕様書無しさん:2015/07/01(水) 07:03:29.92
プログラミング能力が低い人は自身の能力不足をプログラミング言語のせいにしてPHPを憎みつづける

366 :仕様書無しさん:2015/07/01(水) 07:16:51.60
一時期騒がれたけどまだあるの?
業務系だとぱっと出で消える言語は手出せないからな

367 :仕様書無しさん:2015/07/01(水) 08:01:51.06
だから未だにVB6使い続けるのか?

368 :仕様書無しさん:2015/07/01(水) 08:17:22.24
そいや、そのPHPが騒がれてた時期に、多くのスレでPHPの単語が禁止になったの思い出したw

369 :仕様書無しさん:2015/07/01(水) 09:01:00.09
PHPはクラス作れるし匿名関数だって使えるぞ。
何が不満なんだ。

370 :仕様書無しさん:2015/07/01(水) 09:14:27.16
謎アピール発動

371 :仕様書無しさん:2015/07/01(水) 09:32:50.99
PHP使ってる奴頭悪すぎる
会話に挟まってくるなよ

372 :仕様書無しさん:2015/07/01(水) 13:59:23.67
会話に挟まる(笑)

373 :仕様書無しさん:2015/07/01(水) 14:23:46.39
>>358
仕様が変わったのにテストは変えないの?
スタブ以前の問題やな

374 :仕様書無しさん:2015/07/01(水) 21:19:26.17
PHPは視覚的に受け入れられない$$$

375 :仕様書無しさん:2015/07/03(金) 09:50:40.94
>>204-205
そんな記述を喜ぶのはプログラムを知らないコーダーだけ

376 :仕様書無しさん:2015/07/03(金) 21:35:46.84
何をする処理か知らんけど>>204は20〜30年くらい前に
日本で流行ったプログラミングの書き方だよな
空白を限界までギチギチに詰めて、いい気持ち♪ってスタイル
年齢で言うと50歳くらいの人が書くやり方

377 :仕様書無しさん:2015/07/03(金) 21:57:33.32
使い捨てつもりで書いたコードが
何時のまにやら本格運用に

378 :仕様書無しさん:2015/07/03(金) 23:20:46.47
プロトタイプが本番ってのはよくある

379 :仕様書無しさん:2015/07/04(土) 03:35:39.01
>>375
> そんな記述を喜ぶのはプログラムを知らないコーダーだけ

ぷっw

Perlで有名なライブラリのソース満たことある?
CPANで探してきなよ。

どれも同じような記述が使われてるからさw

380 :仕様書無しさん:2015/07/04(土) 05:01:24.28
>>377 まさにそれ
もしくは、アプリケーションを使えることがプログラムと思い込んでるかのどっちか

381 :仕様書無しさん:2015/07/04(土) 05:03:34.48
今時のperlなら正規表現に改行できるし

382 :仕様書無しさん:2015/07/04(土) 05:34:17.90
懐かしのperl使いと言う単語を思い出したわ
自分がプログラマーと呼ばれないと発狂し始めるわ、プログラムはしないわ、結局そうゆう人種
そして何を思ったか、最終的に言語の機能(笑)をアピールしはじめる

383 :仕様書無しさん:2015/07/04(土) 05:37:13.75
perl人種?

384 :仕様書無しさん:2015/07/04(土) 10:08:32.56
perlは4のときは、まだ許せたが、
Perl5からはキチガイ専用言語になってしまった。

人の作ったPerl5のソースなんて絶対に見たくないよ。

385 :仕様書無しさん:2015/07/04(土) 11:14:48.42
まだPerl4とか言ってる奴がいるんだw

386 :仕様書無しさん:2015/07/04(土) 12:06:58.34
アルゴリズムに文句を言える奴はよいが、
記述に文句を付ける奴は三流以下のごみクズと決まっている。

387 :仕様書無しさん:2015/07/04(土) 12:32:23.61
>>376
perl5がリリースされてもない時期にどうやってその記述を・・・

388 :仕様書無しさん:2015/07/04(土) 12:46:03.24
perl使いに不可能などないのだよ

389 :仕様書無しさん:2015/07/04(土) 13:47:27.34
>>386
汚いソースはだめだろ

390 :仕様書無しさん:2015/07/04(土) 13:57:29.80
>>389
きれい汚いの定義をしないで、「汚いソースはだめ」とかいってのけちゃう
史上最悪レベルの害悪だって認識してる?

391 :仕様書無しさん:2015/07/04(土) 14:27:33.08
所詮抽象型

392 :仕様書無しさん:2015/07/04(土) 14:34:18.30
要は『俺が嫌いなものはダメ』としか言っていない

393 :仕様書無しさん:2015/07/04(土) 14:40:43.85
D・A・M・E!!
D・A・M・E!!
ダメダメ

394 :仕様書無しさん:2015/07/04(土) 16:09:50.98
>>>390
きれい汚いの定義をすればいいの?

メトリクス計測を行って
数値が悪ければ汚い。

これで、文句をいうやつの98%は撃退できるからw

395 :仕様書無しさん:2015/07/04(土) 16:14:34.76
たまに好き嫌いの話と混同している奴がいるんだよな。
綺麗/汚いは、好き/嫌いの話とは別だからな。

綺麗/汚いは理由付きで明確に定義できる。

396 :仕様書無しさん:2015/07/04(土) 16:16:34.05
例えばインデントをタブにするか、スペース2個にするか4個にするかは
「好き/嫌い」の話。

だけど、インデントをしたりしなかったり、
ずれていたりと、めちゃくちゃにするとかは
「綺麗/汚い」の話。

インデントの話だから、全部綺麗汚いの話だと
思ったらダメだよ。

397 :仕様書無しさん:2015/07/04(土) 16:34:30.14
>>396
インデントも統一しない
コメントも無意味

そんなソースは汚いに決まってる

398 :仕様書無しさん:2015/07/04(土) 16:35:29.84
きれい汚い、良い悪いって意識があるだけでも素晴らしいな
おらはそういうの興味無くなっちまっただよ
プログラマの死ってこういうことなんだな

399 :仕様書無しさん:2015/07/04(土) 16:42:01.60
普通そうだよな。
決めてフォーマッタかけるだけだもん。
綺麗も汚いもない。

400 :仕様書無しさん:2015/07/04(土) 16:42:26.99
>>398
俺も、メンテ性なんていいから
動いてるコードは一文字も弄るな
って仕事では可読性なんて一切気にしないよ

責任負いたくないから
一文字でも修正が少ない方を選ぶ

401 :仕様書無しさん:2015/07/04(土) 16:43:29.47
>>399
組み込みだとコード整列が難しい

402 :仕様書無しさん:2015/07/04(土) 16:49:31.75
>>400
わかりやすいレスをありがとう。

まとめるとこういう言うことだろう?

私には今よりも会社を良くするための案があります!
でも責任取りたくないのでやりません!

403 :仕様書無しさん:2015/07/04(土) 16:53:51.60
良い提案だけど、責任を取らされるからやらないっていうのは、
もはやソフトウェア開発やコードの問題じゃなくて
会社の文化だからね。

「これから会社を発展させていきたい。何か提案はないか?」
「うむ、それは素晴しい提案だ。だが失敗したらお前が責任とるの?
取れないだろう? じゃあその提案は却下だ。」
「では次の提案をどうぞ?」

みたいな会議が行われている、会社じゃ
どんな改善もできんだろうって。

案の良し悪しじゃない。良い提案であっても「責任問題」で
却下するような文化じゃ、良くなるわけがないだろうって。

404 :仕様書無しさん:2015/07/04(土) 16:56:28.89
>>402
はい

405 :仕様書無しさん:2015/07/04(土) 17:30:49.74
>>401
?なんで?

406 :仕様書無しさん:2015/07/04(土) 18:20:30.88
>>404
あとは本人がそれで良ければ、
それでいいんじゃね?

ソフトウェア開発はクリエイティブで
新しいものを作る職業だと考える人がいる。
一方でメンテナンスだと考える人もいる

君にとっての仕事はメンテナンスなんだよ。
新しいものを作っちゃいない。
既に出来たものをメンテナンスしてるだけ。

もちろん本人がそれでよければそれでいい。

407 :仕様書無しさん:2015/07/04(土) 18:26:42.04
>>406
それ何も言ってないのと同じw

408 :仕様書無しさん:2015/07/04(土) 19:03:44.72
>>407
え? 何を言って欲しいの?

メンテナンス性を上げることが改善案であることは
同意してるでしょ?

それを却下する理由が「責任を取りたくないから」だとしたら
改善案が素晴らしいことを却下した理由にはならない。

あとは新社会人のセミナーにでもいけばいいんじゃね?
「責任を取りたくないので仕事しません」という人へのアドバイスは
それだけだよ。

409 :仕様書無しさん:2015/07/04(土) 19:14:51.65
>>394
メトリクス計測は害悪にしかならない、なんてもう5年近くも前に
確立された常識なのに、いまだメトリクス計測信者生きてたんだ。

410 :仕様書無しさん:2015/07/04(土) 19:23:39.29
>>409
CIとかでも普通に計測されてるだろw
少しは勉強しろよw
知ってるか?CIって?

411 :仕様書無しさん:2015/07/04(土) 19:24:36.18
計測したって数字を判断するのは結局人間だしな。
数字の意味とそのコードの適正な値を判断できない無能上司が
数値の高い低いだけでダメ出しするようなことがおきたから害悪なので
あって、メトリクス計測そのものは単なる測定手法。
使う人が馬鹿という話を手法にすり替えられても困る。

412 :仕様書無しさん:2015/07/04(土) 19:26:04.65
要約すると、
「使えない人間」という人間の問題は
ツール自体の問題の話じゃないのを
ごまかしてますが何か?

413 :仕様書無しさん:2015/07/04(土) 19:27:11.68
メトリクス測定で良いと言われたからといって
確実に良いわけではないが、

悪いと言われたコードは
確実に悪い。

414 :仕様書無しさん:2015/07/04(土) 19:27:14.59
>>411
だからSIerみたいな馬鹿の集まりに扱わせたら害悪という話なんだけど、
おまえ仕事したことある?

415 :仕様書無しさん:2015/07/04(土) 19:29:18.42
よくわかんないんだけど、メトリクス計測ってよい悪いって計測で判断されるの?
複雑度とか数字ででてくるだけじゃないの?

416 :仕様書無しさん:2015/07/04(土) 19:29:30.00
コードの良し悪しを判断できない人間は
そもそもコードに良し悪しが有る事自体が
わかってないからね。

まず悪いコードというものが存在して
それが数値で計測できるという現実を
突きつけてやるのが第一歩。

417 :仕様書無しさん:2015/07/04(土) 19:30:59.44
>>414
ごめん。小学生に飛行機運転させるという例を持ちだして
飛行機の批判をすることに意味の無さに呆れただけw

馬鹿が使って悪いからといって、
ツール自体の問題では無いのですよ。

418 :仕様書無しさん:2015/07/04(土) 19:31:20.65
>>414
どこからSierの話になったんだ?w

419 :仕様書無しさん:2015/07/04(土) 19:32:26.17
包丁の販売は禁止するべきだ

420 :仕様書無しさん:2015/07/04(土) 19:34:04.80
>>409
害悪=都合が悪い
ってことならその通りかもな。
無能さが明確に数値で出来ちゃうからね。
IQ200です、って売り込んで、計測してみたらIQ50の池沼でした、じゃ
都合悪いよねw

421 :仕様書無しさん:2015/07/04(土) 19:42:08.74
結局はここも派遣奴隷の巣でした、ちゃんちゃん

422 :仕様書無しさん:2015/07/04(土) 19:49:04.37
>>420
コードもそんな感じで調べられる。

自分で良いコード(IQ200)と思っていても
実際にツールで計測したら悪い(IQ50)ってでることもある。

ここまでの話でツールには問題ないことは
同意を得られているようだし、
つまりそういうこと。

IQ200でも犯罪者がいるように、いいとは限らないが、
IQ50は確実に馬鹿だw

423 :仕様書無しさん:2015/07/04(土) 20:24:41.53
>>408
なんか言ってることが浅すぎじゃね?w
中学生みたいw

424 :仕様書無しさん:2015/07/04(土) 20:48:02.95
有名OSSが軒並み悪い評価されている時点で
メトリクス計測は役に立たないけどな。

425 :仕様書無しさん:2015/07/04(土) 21:26:11.85
俺らOSS作ってるわけじゃないし。

426 :仕様書無しさん:2015/07/04(土) 21:36:56.55
ウンコ以外なにもつくってないもんな、ニートはw

427 :仕様書無しさん:2015/07/04(土) 21:50:45.03
UEFIのEDKII落としてコードみたけどGOTOだらけやな
アレはどうなん?

428 :仕様書無しさん:2015/07/04(土) 22:12:08.32
>>390
定義してなくても一目見て汚いって分かるのは相当汚いって事だよね

429 :仕様書無しさん:2015/07/05(日) 01:40:32.77
被害者の後頭部にはPerlのような物で殴打された痕があり

430 :仕様書無しさん:2015/07/05(日) 02:04:05.40
>>415
出来上がったコードから出したメトリクスの複雑度や結合度をどうこしろと
指示できる人はいるだろうが、コードのどこをどう直したら良いかと指示
できる人はそんなにというか誰もいないと思う。数字内に収めてかつ
修正前と機能は何も変わらず、バグを一切入れないとか普通に無理ゲー。

431 :仕様書無しさん:2015/07/05(日) 02:20:48.41
>>430
無能集団には無理げーでも、普通以上レベルのプログラマーならできて当然。

432 :仕様書無しさん:2015/07/05(日) 02:27:23.51
>>430
> できる人はそんなにというか誰もいないと思う。

ああ、技術力が低い会社
SIerばっかりの会社には
誰も居ないっていうのは正解だと思うよ。

433 :仕様書無しさん:2015/07/05(日) 02:51:40.40
さて問題です、複雑度が高いとメトリクス判定されるコードは
最低どれくらいの量になるでしょうか?

その量のコードに対してあなたが出来る事はそのコードを読んで、
そのコードを書いた人に対してコードのどの部分、どの関数を
具体的にどう直すかを指示して複雑度を規定値以下になるように
コードを書き直させるだけです。 自分で書き直すのも良いかも
しれませんが、そうした場合に先にそれを書いた人の価値は
どうなるの?

434 :仕様書無しさん:2015/07/05(日) 03:07:52.70
分かりやすく書くと、スパゲティーコードはどれくらいの量から
スパゲティーコードと呼ばれるようになるかだな。

きちんとした人が複雑度の高いコードになるようなら多分それは
相応の理由があってそうなるわけで。 そうじゃないなら大抵は
ダメな人が書いたダメなコードを指示を出してダメじゃ無い
コードに書き直させる、もしくは自分で書き直す。

こういう想像力も無しで普通以上レベルとか、技術力が低い
会社とか言えちゃう人はすごいなと、素直に思います。

435 :仕様書無しさん:2015/07/05(日) 03:25:45.02
>>443
> さて問題です、複雑度が高いとメトリクス判定されるコードは
> 最低どれくらいの量になるでしょうか?

量じゃなくて条件分岐の数で決まるけどな。
ちなみにこの間俺が作ったソフトウェアでは
複雑度の数値がすべて10以下。
平均(あまり意味ないけど)は2.なんとかだったな。

436 :仕様書無しさん:2015/07/05(日) 03:32:56.70
>>434
> きちんとした人が複雑度の高いコードになるようなら多分それは
> 相応の理由があってそうなるわけで。

実はそれを見抜くのは簡単。
そこ以外の部分がシンプルにかけているか、
そっちも複雑かを調べればわかる。

理由があって複雑になっているのであれば
それ以外はシンプルになっているはずだ。

437 :仕様書無しさん:2015/07/05(日) 06:12:21.44
>>402
そらそうよ
自分の仕事いっぱいあるんだから

438 :仕様書無しさん:2015/07/05(日) 06:20:16.71
>>437
もちろん合理的理論的にしたら
人の仕事を奪うことになるからね。

439 :仕様書無しさん:2015/07/05(日) 13:38:11.78
仕事なんて言われたことだけやっていれば
いいんだよ。新しいことなんて不要。
金さえ稼げればそれでいい。
だから給料上げろや。

440 :405:2015/07/05(日) 13:49:09.72
>>406
正しいよ。言うことはない。
君が馬鹿にしてるのもよくわかる

441 :405:2015/07/05(日) 13:50:45.47
>>415
複雑度は30超えるなとか言われるな

442 :405:2015/07/05(日) 13:53:17.43
>>439
それも正しいよ

443 :仕様書無しさん:2015/07/05(日) 13:56:21.62
高すぎだろw
> 複雑度は30超えるなとか言われるな

普通は10を超えたらダメだ。

444 :405:2015/07/05(日) 14:00:08.23
>>443
C言語で書いてると、それは結構難しい

ほとんどは10超えないけど
胴体になってる関数が30位になってしまう

445 :仕様書無しさん:2015/07/05(日) 15:05:41.19
複雑度だけがコードの品質の指標ではないけど
複雑度の高いコードは間違いなく品質が悪い
長いて深い関数書くようなゴミは死ね

446 :405:2015/07/05(日) 15:11:23.24
>>445
機能の関数は短いけど
それをコールして手続き的に処理する関数は
ネストが深くなるけどな

447 :仕様書無しさん:2015/07/05(日) 15:29:37.25
>>446
ふぅん?
お前がそう思うんならそうなんだろうな
お前の中ではな

448 :仕様書無しさん:2015/07/05(日) 15:56:20.01
どんな時でもネストが深いのは誤りだろ

449 :仕様書無しさん:2015/07/05(日) 16:43:12.46
お箸レストラン?

450 :仕様書無しさん:2015/07/05(日) 16:58:16.52
>>444
> 胴体になってる関数が30位になってしまう
ないな。

複雑度っていうのはコードの行数が
なくなっても増えない。

条件分岐やループ有ると増える。

お前の言う「胴体」は
メインの処理が入ってるだろ?

451 :仕様書無しさん:2015/07/05(日) 16:59:04.36
タイポで意味が逆になってたw

× 複雑度っていうのはコードの行数が
なくなっても増えない。

○ 複雑度っていうのはコードの行数が
ながくなっても増えない。

452 :405:2015/07/05(日) 17:33:46.19
>>450
関数コールでも一個増えるはず

453 :仕様書無しさん:2015/07/05(日) 17:36:48.68
こっちのスレでも関数とか複雑度とか言ってるのか
同じ奴が大暴れしてるんじゃね?

454 :仕様書無しさん:2015/07/05(日) 17:44:18.58
そうことを知っているお前が「同じやつ」だなw

455 :仕様書無しさん:2015/07/12(日) 20:40:22.34
バージョン管理ソフトの使用を禁ずる
修正時は修正前後のファイルをバックアップする事

456 :仕様書無しさん:2015/07/12(日) 20:59:49.76
バージョン管理とは別にリリース時点のソース一式取り出してバックアップされるが

457 :仕様書無しさん:2015/07/12(日) 22:07:14.47
修正を禁ずる

458 :仕様書無しさん:2015/07/13(月) 22:03:53.46
ファイルバックアップならまだましかもしれん
過去のコードを全部コメントアウトで残すよう強制されると
人間には読めない

459 :仕様書無しさん:2015/07/13(月) 22:30:05.19
>>458
インデント直すのも禁止されてたりしてネストがぐちゃぐちゃになんだよね

460 :仕様書無しさん:2015/07/13(月) 23:08:21.03
読めるよ。読む気がないだけだろ

461 :仕様書無しさん:2015/07/13(月) 23:27:59.74
>>460
読めるコードと読むことが出来るコードは近いようで遠いぞ

462 :仕様書無しさん:2015/07/13(月) 23:33:49.94
読めるだろ。生産性ガタ落ちになるだけだ。

ぶっちゃけ生産性なんていらないんだよ。
何億円かかかっても良い。

463 :仕様書無しさん:2015/07/13(月) 23:47:28.21
いじっていないファイルのタイムスタンプを変えてはいけない、
というルールのせいでバージョン管理ソフトすら使えない案件があった。

464 :仕様書無しさん:2015/07/13(月) 23:52:01.89
>>462
正に底辺土方の発言
テラワロス

465 :仕様書無しさん:2015/07/13(月) 23:56:48.60
掘った穴を埋めるような作業は嫌だよ。
金が儲かるかどうかじゃなくて、自分の時間を無駄にしてる。

466 :仕様書無しさん:2015/07/14(火) 02:41:28.90
それはドカタに失礼だろ

467 :仕様書無しさん:2015/07/14(火) 04:42:18.08
>>463
そう俺も一度だけあった

VCS反対勢力の理由の1つに
「タイムスタンプが変わっちゃうじゃないか!どれが最新か分からなくなるじゃないか!」
がある

468 :仕様書無しさん:2015/07/14(火) 07:11:28.68
>>465
金が手に入るなら無駄じゃないだろ。
ミュージシャン目指してるやつがバイトに明け暮れて練習する時間がなく
サラリーマンやってる人のほうが退社後にバンドの練習よっぽどできるみたいなもの。
志が高いだけじゃだめだ。

469 :仕様書無しさん:2015/07/14(火) 07:54:51.58
>>468
マジで頭おかしい
マゾい事で無駄が好きなんだなw

470 :仕様書無しさん:2015/07/14(火) 08:05:41.22
>>468
例えが下手すぎて意味不明w

471 :仕様書無しさん:2015/07/14(火) 09:51:57.06
>>468
>金が儲かるかどうかじゃなくて
って書いてあるだろ。

そのバイトやら会社員やらを金儲けのために嫌々やってたとしても、
たいていの場合、作業そのものには何らかの生産性があるわけじゃん?

でも、この業界じゃ、むしろ生産性下げるだけの作業、ゴールに辿り着かない作業が多すぎる。

実際、ひたすら穴を掘って埋めるって作業は、拷問として使われてたらしいしね。

472 :仕様書無しさん:2015/07/14(火) 10:56:02.35
課長王子を思い出した

473 :仕様書無しさん:2015/07/14(火) 20:02:59.26
掘った芋いじるな

474 :仕様書無しさん:2015/07/14(火) 20:24:30.12
バージョン管理ソフトでファイルのタイムスタンプをそのまま保持しといてくれる仕組みって作れないの?

475 :仕様書無しさん:2015/07/14(火) 20:26:45.53
>>474
ある程度は作れるかもしれないけど、すべてのファイルシステムで使えるとは
限らないし、そもそもそんなキチガイ思想を受け入れること自体が屈辱。

476 :仕様書無しさん:2015/07/14(火) 20:33:08.26
>>474
タイムスタンプをそのまま保持してしまうと
ビルドが正常に動作しなくなるんだよ。
だからタイムスタンプは保持したらダメ。

もしなぜかわからないなら、ビルドの仕組みを知らないってことだね。
ビルドっていうのはファイル単位でコンパイルしてオブジェクトファイルが作られ、
それらを結合するわけだがファイルの更新日付を見てコンパイルが必要かどうかを判断してる。

新しい更新日のファイルでオブジェクトファイルを作ったあとに
ブランチを切り替えて、古い更新日のファイルになった時、
タイムスタンプを保持してしまっていたら、コンパイルされない。

バージョン管理システムっていうのは
君が思いつかないようなことまでしっかり
考えて作られてるんだよ。

477 :仕様書無しさん:2015/07/14(火) 20:37:45.28
>>475
なんでキチガイ思想なんだよ
見てたら思いっきり需要あんじゃん

478 :仕様書無しさん:2015/07/14(火) 20:46:35.80
>>476
タイムスタンプで管理しているプロジェクトには
当然make cleanくらいあるから素人が余計な心配しなくていいよ。

479 :仕様書無しさん:2015/07/14(火) 20:51:08.07
>>478
そういう問題じゃないw
だからお前は馬鹿なんだ。

480 :仕様書無しさん:2015/07/14(火) 20:55:05.67
make cleanwwwww
馬鹿すぎて話にならないな。

481 :仕様書無しさん:2015/07/14(火) 20:57:29.04
こりゃバージョン管理システムを導入しないんじゃなくて
知能レベル的に導入できないから、どうしようもなくて
タイムスタンプなんて当てにならないものを管理してるんだな。

482 :仕様書無しさん:2015/07/14(火) 21:08:25.45
>>476
いえ、タイムスタンプを変えたくないという需要は確かにあります。
適宜ビルドするソースコードではタイムスタンプを保持しない方が良いかもしれないが、
最終更新日時も一般的には重要な情報です。
だからファイルには最終更新日時が付加されているんです。

483 :仕様書無しさん:2015/07/14(火) 21:16:39.87
タイムスタンプに依存したビルドプロセスには疑問すら持てない馬鹿
お仕着せの道具は使えても自分で新しい物は作れないタイプの人だね

484 :仕様書無しさん:2015/07/14(火) 21:19:37.31
そこまでならmake禁止だろうな。
常にフルコンパイル

485 :仕様書無しさん:2015/07/14(火) 21:26:13.74
タイムスタンプは、知らないうちになんかの弾みで書き換わるもんだ

486 :仕様書無しさん:2015/07/14(火) 21:29:06.57
さすがにそれはない

487 :仕様書無しさん:2015/07/14(火) 21:31:37.88
touch

488 :仕様書無しさん:2015/07/14(火) 21:59:23.12
>>469
金もらうんだから無駄じゃないだろ
作業だけやって金もらえなかったら無駄な作業だけどな

>>470
お前の理解力が足りてないんだろ

>>471
作業と引き換えに金をもらうんだから金を生産してる
会社で書くプログラムは自分が満足できるかどうかより
顧客が満足するかどうか
どんなに退屈な仕事でもそれで客が満足するなら立派な仕事だ
金もらってプライベートで自分の好きなようにプログラムを作ればいい
プライベートより会社の仕事を満喫したいとかどんだけ社畜なんだよ
首輪外すべきだと思うぞ

489 :仕様書無しさん:2015/07/14(火) 22:06:03.63
フォルダやファイルをコピーしたりとかしないのかい?
何も書き換えないで上書きしないことは、全員が徹底して守ってるのかい?
ファイルに対して暗黙なアクセスがないことは保証されてるのかい?
OS内の自分にとって不要なプロセスは、毎回止めてるのかい?
ハードウェア的な対処を取るとき、絶対にタイムスタンプが狂わない方法で統一されてるのかい?
そもそも、時間と実データが結びついていることが保証されるOSを使ってるのかい?そんなのはないよ

490 :仕様書無しさん:2015/07/14(火) 22:10:15.79
>>488
俺は趣味の延長で仕事やってるから、仕事が退屈だとニートになってしまう。
辛い仕事を仕方なくやって、首輪をされているのはどっちか、良く考えてみ。

491 :仕様書無しさん:2015/07/14(火) 22:13:11.55
>>490
どう考えても仕事を趣味にしてるやつが社畜だろ
他にやることねえのかよ
仕事に依存しすぎ

492 :仕様書無しさん:2015/07/14(火) 22:16:33.20
>>491
知らないだろうけど、仕事って楽しいんだよ。
そういう仕事に巡り合えるといいね。

493 :仕様書無しさん:2015/07/14(火) 22:21:18.87
>>492
ワタミを始めブラック企業で働いている人はたいていそう言う
この仕事にはやりがいがあるんだとかね
仕事が本当に充実してる人はそれに見合った金を受け取っているから
精神論持ちださなくてもすむんだよ
お前はまだ仕事というのをわかっていない

494 :仕様書無しさん:2015/07/14(火) 22:25:05.30
確かに仕事だからどうとか、俺にはよくわからん。
趣味の延長だし、嫌になったら投げ出すと思う。

495 :仕様書無しさん:2015/07/14(火) 22:28:19.07
>>494
そしたらお前ニートになるだろ
つまり俺とニート友だちになるってことだぞ
どうぞよろしくお願いいたします
以上よろしくお願いいたします

496 :仕様書無しさん:2015/07/14(火) 22:31:42.30
リヤカー引いてる売り子はマインドコントロールされてて、本人的には楽しいらしいぞ

497 :仕様書無しさん:2015/07/14(火) 22:39:09.85
>>489
6個も同時に質問して、さらに同時に自己解決までするとはなんとも欲張りな奴だ

498 :仕様書無しさん:2015/07/14(火) 22:47:36.17
タイムスタンプ維持しろとか寝言言う連中がビルドのこと考慮するはずがない
奴らにとってそれは他人事だ

499 :仕様書無しさん:2015/07/14(火) 23:32:51.51
>>489
cpコマンドで-aオプション付けて実行するスクリプトを必ず使うとか、
antでもタスクのオプションで時間を保持したままってのがあるから
基本的にビルドやらデプロイ関係はそういうツール越しに使うのを
習慣にしている。

まあそれ以前にsvnはexportでソースだけ取り出すとコミットした
時間で取り出せるからsvnを使っていた時のデプロイ関係の
作業はexportしてからやってたな。

gitはlinusが頑なにそこら辺を拒んでいるからそうなってないだけで、
それが常識みたいに勘違いしている奴も少なくない。

まあ、ファイルの同一性はタイムスタンプよりファイルのハッシュ値で
チェックしたほうがいいとは思うけどね。

500 :仕様書無しさん:2015/07/14(火) 23:34:45.25
>>499
exportとcheckoutをごっちゃにすんな

501 :仕様書無しさん:2015/07/14(火) 23:36:34.85
>>499
ファイルが同一でもオブジェクトファイルは異なることが有るんだよ。

502 :仕様書無しさん:2015/07/15(水) 00:38:29.88
>>500
どこがごちゃごちゃ?

503 :仕様書無しさん:2015/07/15(水) 00:39:57.74
>>501
オブジェクトファイルが何をさして言っているのか分からんが、
コンパイラが吐き出す中間ファイルならそんなもんはバージョン
管理に入れないだろ。

504 :仕様書無しさん:2015/07/15(水) 00:58:13.59
フルコンパイルしないなら、バージョン管理に入れることもあるかもしれないな

505 :仕様書無しさん:2015/07/15(水) 01:34:13.82
ちなみにCVSのチェックアウトはコミットしたタイムスタンプがローカルになり、
svnはチェックアウトした時間になる。ただsvnはオプションでチェックアウトでも
コミットした時間に出来る。ただ管理ツールでリポジトリ全体がそういう設定に
なるのでデフォルトのままのところが多い。 それでもローカルで時間だけを
変更したファイルの時間は変更がかからないから不完全とも言える。

gitはオプションでもそういう時間関係のを入れようとしないからタイムスタンプ
論争がおさまらないっていう。

506 :仕様書無しさん:2015/07/15(水) 03:41:10.10
ファイルの時間なんて毎日知らないうちに書き換わってる物

507 :仕様書無しさん:2015/07/15(水) 05:20:36.55
>>490
お、同士が居た
もう10年以上、"趣味"でやってるわ
この業界、嫌々続けている奴大杉

508 :仕様書無しさん:2015/07/15(水) 07:05:14.16
古代人のタイムスタンプマンは思考回路が止まってるからな

509 :仕様書無しさん:2015/07/15(水) 07:52:09.31
タイムスタンプが不要な情報なら、Windows10からはバッサリ削除されてるでしょうな

510 :仕様書無しさん:2015/07/15(水) 08:07:28.45
なぜか妙にこだわりすぎる奴がいるって事だろ

511 :仕様書無しさん:2015/07/15(水) 08:20:33.57
全て業務監査のため

512 :仕様書無しさん:2015/07/15(水) 09:10:22.04
多分、おそらくのはなしだけど、
昔「cvsでソース管理しておいて」っていったら、
csvでファイルの一覧とタイムスタンプの管理台帳みたいなのが
出てきたんだよ。
そんでバージョン管理はタイムスタンプで行う、タイムスタンプが
変わるバージョン管理ソフトなんて低レベルすぎて使えない、やっぱ
csvが一番だ!って思い込んじゃったんだと思う。

彼もまた被害者なんだよ。

513 :仕様書無しさん:2015/07/15(水) 10:53:27.60
makefileでソースファイルにtouchする奴もいるから
そもそも信用しちゃいけない

514 :仕様書無しさん:2015/07/15(水) 11:14:53.95
>>509
> タイムスタンプが不要な情報なら、Windows10からはバッサリ削除されてるでしょうな

タイムスタンプが重要だからこそ、
gitではcheckoutした時間が最新になるようになってるんだよ。

ファイルが変更されているというのに、
更新日時が過去に戻ったら問題が起きるだろ。

515 :仕様書無しさん:2015/07/15(水) 13:27:46.30
>makefileでソースファイルにtouchする

VC++1.5の「リビルド」が、「全ソースファイルにtouchしてビルド」って
実装になっててMSG爆破しに行きたくなったの思い出した。

516 :仕様書無しさん:2015/07/15(水) 13:39:21.76
よくわからんが、例えばアメリカだと東部〜西海岸までにローカルタイムが幾つかあるから駄目って事?

517 :仕様書無しさん:2015/07/15(水) 19:45:54.21
>>514
Windowsではファイルをコピーしても、元の更新日時が引き継がれるだろう?
つまりファイルがコピーされた時間より、元ファイルが更新された時間の方が
情報として重要という理念がある。

gitはcheckoutしたときに新たにファイルを生成してるんだから、
そのタイムスタンプが刻まれるのは動作としちゃ正しいさ。
一度ビルドしたソースファイルを元に戻す場合など、その方が都合がいいこともあるだろう。

ただ、元ファイルの更新日時という一般的には重要な情報が失われてしまうことも確かだ。

518 :仕様書無しさん:2015/07/15(水) 20:05:20.33
いつからここは「本当におった変な俺」を紹介するスレになったんだw

519 :仕様書無しさん:2015/07/15(水) 20:52:58.72
>>517
> ただ、元ファイルの更新日時という一般的には重要な情報が失われてしまうことも確かだ。
そんなものは要らない。

必要なのは、そのコードがいつコミットされたかだ。
gitでは行毎にそのコードがいつコミットされたか記録されている。

ファイルの更新日付という、コードが追加されたのと
全く関係ない情報を保持してどうする?

ファイルの更新日付が、2015/07/15であったとしても、
そのファイルに含まれるコードの大部分は10年前に
書かれたコードかもしれないんだぞ

一体何の意味があるのだ?

520 :仕様書無しさん:2015/07/15(水) 21:02:33.31
全バージョンのバックアップがある方がマシ

521 :仕様書無しさん:2015/07/15(水) 21:13:47.97
日本人ダケダヨ
VCSについてバカみたいな議論シテルノハ

522 :仕様書無しさん:2015/07/15(水) 21:20:05.70
>>519
知恵袋等でもこのような質問が出ていた。
このように、場合によってはタイムスタンプを保持したいことがある。

> 新規でプロジェクトを進める際はコミット時の時間が現在の時間で問題ありませんが、
> 他者からソースコードを受領した場合や既存のソースコードを管理し始める場合、
> それらをコミットするとファイルの更新日時が現在の時間になってしまいます。
> またプログラムをリリースする際にエクスポートするときも現在の日時に更新されてしまうようです。
> これでは、ソースコートの内容自体は変わっていないにもかかわらず、更新日時が変わって
> いるために、他者から見ると整合性がとれなくなってしまいます。
> 他者からもらったファイル/既存のファイルの内容変更が無い場合はファイルのタイムスタンプを
> 維持する方法はないでしょうか。

> 顧客とのやりとりもあり、不要な説明が増えそうなので
> 質問させてもらった次第です。

523 :仕様書無しさん:2015/07/15(水) 21:31:22.31
同一性を確かめるのに、素人はタイムスタンプに頼る
玄人はそんなものには頼らない

524 :仕様書無しさん:2015/07/15(水) 21:38:12.67
それは人それぞれ、事情それぞれ
手がかりは1つしかないより2つある方がよい

525 :仕様書無しさん:2015/07/15(水) 21:50:38.54
>>522
理由が書いてないな。
なにが問題なんだ?

526 :仕様書無しさん:2015/07/15(水) 22:13:21.43
こりゃまあ、10行中全部で3行も書いてあるものが読めないですと

527 :仕様書無しさん:2015/07/15(水) 22:20:24.36
そもそも更新されてないファイルのタイムスタンプが変わるのは
現状の、バージョン管理システム、およびビルドシステムの問題点であって
ファイルの更新日時が重要でない、という話では全くない。

528 :仕様書無しさん:2015/07/15(水) 22:56:41.57
ビルド職人とそれ以外とで温度差が違ってるんだろうな。

どっちにしろビルド職人を憎むあまり、タイムスタンプのチェック程度で
回避できるプロセスも走って大変なことに!みたいな笑い話もよく聞く。
小さいうちは富豪的でも問題なくても、ある程度大きくなると立ち行か
なくなったりするっていう。

529 :仕様書無しさん:2015/07/15(水) 23:13:42.81
>>527
> ファイルの更新日時が重要でない、という話では全くない。
むしろ重要。
ビルドは更新に日時を見るからね。

だからそれに最適化してgitでは更新日時を
記録しないようにわざとしている。

更にファイルの更新日時では出なく
コミットの更新日時が記録され
コードの行毎にいつ更新されたかがわかる。

重要なのは行ごとの更新であってファイルの更新日時ではないし、
複数の行の更新日時のうちどれを見ればいいかわからない
マージした時はどうなるというのか?

530 :仕様書無しさん:2015/07/15(水) 23:19:55.75
まずバージョン管理ソフトというのは
ファイルの版を管理するソフトじゃないってこと。

バージョン管理ソフトは、
ソフトウェアのバージョンを管理するもの
ソフトウェアのバージョンというのは
つまり機能であり修正である。

機能や修正はつまりコードの差分、パッチとして表現できる。
バージョン管理ソフトではその単位で管理するものなのだから
ファイル単位の日付は意味が無く管理してはいけないもの
バージョン管理ソフトではもっと小さい単位で管理する。

531 :仕様書無しさん:2015/07/15(水) 23:21:52.87
>>529
> むしろ重要。
> 重要なのは行ごとの更新であってファイルの更新日時ではないし、
どないやねんwww

俺の馬鹿センサーがギンギンに反応してる事をお知らせ致します

532 :仕様書無しさん:2015/07/15(水) 23:30:39.60
>>530
> バージョン管理ソフトは、
> ソフトウェアのバージョンを管理するもの
ソフトウェア以外のファイル管理もしたいんですが、そういう用途にはそもそも向かないってことだね

マージしたファイルはもちろん最終的にマージした時のタイムスタンプでいいのだが、
何の変更もないファイルについては既存のタイムスタンプを保持できればなあと思うが

533 :仕様書無しさん:2015/07/15(水) 23:47:27.67
お前らまだやってたのかよ

534 :仕様書無しさん:2015/07/15(水) 23:51:27.83
そんなに日付が重要なら冒頭メモに書いとけよと思う
日付が重要なんです → OSのファイル管理時刻使います → は??

535 :仕様書無しさん:2015/07/15(水) 23:58:34.83
まぁ実際重要なら重要なりの管理してるわな
更新履歴に時間書いてるのなら見たことあるけど
バージョン管理ソフト使えよと思う

536 :仕様書無しさん:2015/07/16(木) 01:02:05.90
だいたいUnixだとコピーで日付変わるから
タイムスタンプなぞ大事にしていても意味がない

537 :仕様書無しさん:2015/07/16(木) 07:35:49.99
>>536
つ -p

538 :仕様書無しさん:2015/07/16(木) 07:38:11.86
もう行ごとにコメントで変更日付書いとけよ
a=a+1; //20150716073750

秒を忘れるなよ(´∀`)

539 :仕様書無しさん:2015/07/16(木) 07:44:09.78
行ごとの更新日時管理がいかに役に立たないかが分かるレスだな

540 :仕様書無しさん:2015/07/16(木) 08:02:23.02
だからmakeしたら全ソースtouchされたりするから
こんなもので管理とか無理だって
はい終了終了

541 :仕様書無しさん:2015/07/16(木) 08:06:53.33
今時のVisual Studioもgit標準SCMとして使えるよね。中でファイルの日付を
どう扱ってるかは試してないのでわからないけど。
少なくともmsbuildはファイルのタイムスタンプを見ているようだ。

542 :仕様書無しさん:2015/07/16(木) 09:42:45.07
>>537
オプションなんか日常的に付けんぞ
Windowsから来た初心者がやりがち

543 :仕様書無しさん:2015/07/16(木) 10:02:24.75
alias cp="cp -p"

って自分ではやってないが。

544 :仕様書無しさん:2015/07/16(木) 10:12:09.88
ないない、そんなにタイムスタンプが大事なら
ディストロが最初からaliasをデフォルト設定してるだろ
そんなディストロは見たことないし、
OSSに含まれているシェルスクリプトでもまず滅多に使ってない

545 :仕様書無しさん:2015/07/16(木) 12:25:34.80
それはコピー時にタイムスタンプを保持するべきかどうか、という問題。

お前ら本当に馬鹿なんだな。

546 :仕様書無しさん:2015/07/16(木) 12:43:49.20
>>531
お前が馬鹿というセンサーですか?

git blameすればわかるが、gitでは
一行毎に修正した人とそのコミット番号がわかる。

ファイル全体という大雑把すぎる更新日を記録しても意味が無い。

547 :仕様書無しさん:2015/07/16(木) 12:48:54.81
>>539
> 行ごとの更新日時管理がいかに役に立たないかが分かるレスだな

正確に言えば、行ごとの修正管理だからね
行ごとに修正管理するのはすごく意味がある。

いつそのバグが入ったか?がわかるわけだから。
日時はついでだよ。
○月○日に誰々がその行を修正しました。

修正したのは行であってファイルではない。
たった一行修正しただけで、そのファイル全体が最新になるわけ無いしね。

548 :仕様書無しさん:2015/07/16(木) 13:47:35.96
タイムスタンプ厨が来たら逃げろという先人の知恵は正しかったな

549 :仕様書無しさん:2015/07/16(木) 17:23:17.71
雇用に流動性があれば逃げれるけどさあ

550 :仕様書無しさん:2015/07/16(木) 17:32:23.00
無能はタイムスタンプが嫌いでもしがみ付くしかないよな。
ヘタに反対意見も言えないしな。

551 :仕様書無しさん:2015/07/16(木) 20:21:30.08
そもそもgitとか誰の馬の骨か分かんないソフトを正義として使ってるのも問題だよね。
バグあったらどうすんの

552 :仕様書無しさん:2015/07/16(木) 20:32:51.84
ソースのないバイナリ使ってるほうがよほど恐怖

553 :仕様書無しさん:2015/07/16(木) 20:51:56.26
>>552
OSSの世界だとOpenSSLみたいにソース公開されていてもバグだらけのものばっかだけどな

554 :仕様書無しさん:2015/07/16(木) 20:56:27.45
これほどgitが信頼を得たのも、リーナスタソが作ったってのが大きいよね

555 :仕様書無しさん:2015/07/16(木) 20:58:36.41
信頼どころか、このスレを見てると狂信者が結構いるみたいだな。

556 :仕様書無しさん:2015/07/16(木) 21:01:34.63
この業界にいてリーナスを信頼している奴は未経験の馬鹿だけだろう。

557 :仕様書無しさん:2015/07/16(木) 21:12:44.62
素人で申し訳ないのですが、gitで管理したCをコンパイルするとオブジェクトにも自動的にそのレビジョン?が付加されるのでしょうか?

558 :仕様書無しさん:2015/07/16(木) 21:37:52.54
>>555 >>556
2回に分けて書かなくてよいのよ(まる)

559 :仕様書無しさん:2015/07/17(金) 01:16:34.06
gitというかgithubの功績の方がでかいよな。
分散分散言っているけど、結局のところ多人数で開発する場合は
中央リポジトリが無いと成り立たないっていう。

まあ、マージが楽でブランチを簡単に切り替えて開発できるのは
開発する上ではcvsやsvnよりはるかに良くなったけどね。

560 :仕様書無しさん:2015/07/17(金) 13:19:28.54
>>559
へ? もとから分散は
中央リポジトリをなくすためのものじゃないよ?

561 :仕様書無しさん:2015/07/17(金) 20:48:26.96
>>553
バグが公表されるから信頼されるんだけどね
OSXとか長年放置されたまま。

562 :仕様書無しさん:2015/07/17(金) 20:49:28.56
うむ、ハゲを隠してる奴は信頼できんな

563 :仕様書無しさん:2015/07/17(金) 23:27:39.71
>>560
他のは知らんけど、gitはlinusやその周辺の中央リポジトリなんて糞食らえ、
ビルド職人は氏ねっていう思想のもとに出来上がっているからGITBOOK
なんかでもリモート関連の部分は薄いんだよ。 各々が各々のバージョンを
もって、それを正しいとするみたいな考え方だから。

svnなんかと違って通し番号のバージョンやリビジョン番号じゃなくて、
コミットに対してチェックサム値を利用するというのがそれをよく表して
いるわけで。

564 :仕様書無しさん:2015/07/17(金) 23:30:04.35
> gitはlinusやその周辺の中央リポジトリなんて糞食らえ、
> ビルド職人は氏ねっていう思想のもとに出来上がっているから

お前の妄想ね(笑)

頭悪そう。

565 :仕様書無しさん:2015/07/17(金) 23:31:53.55
> svnなんかと違って通し番号のバージョンやリビジョン番号じゃなくて、
通し番号だったら、
あっちのリポジトリで番号10、
こっちのリポジトリで番号10、

マージする時どうするの?って問題があるからだろ。
少しは頭使えよw

566 :仕様書無しさん:2015/07/18(土) 01:56:53.03
>>565
は? 結局のところ複数人というか会社で開発する場合は
通し番号かそれに類するルールでの中央リポジトリみたいな
ものに集めて管理とかビルドとになっているだろ。

○○さんのところに最新のソース集めてそいつで最新版
つくろうみたいな話にはならないで、各自のローカルには
劣化バックアップみたいな状態になっているっていう。

567 :仕様書無しさん:2015/07/18(土) 07:01:59.19
じゃ svn で良いじゃん。

568 :仕様書無しさん:2015/07/18(土) 09:24:24.06
SVN脳w

569 :仕様書無しさん:2015/07/18(土) 10:54:08.41
svnは枝作るのが面倒杉
gitは個人リポジトリが枝みたいなもんだから簡単。

570 :仕様書無しさん:2015/07/18(土) 12:38:32.71
>>566
> は? 結局のところ複数人というか会社で開発する場合は
> 通し番号かそれに類するルールでの中央リポジトリみたいな
> ものに集めて管理とかビルドとになっているだろ。

だからなんだよ?

わかりやすく一言で言うならば、
gitは両方できる。svnは集中だけ。

どちらが優れているかなんてすぐに分かるだろ?

中央に集めないとビルドできないシステムなんて聞いたことないぞ
個人はビルドできないのかよw 個人はテストも出来ないのかよw

中央に集めるのはリリース用のタグ(バージョン番号)をつけるため
それ以外の通常の作業はどこででも出来たほうがいいだろ。

571 :仕様書無しさん:2015/07/18(土) 13:09:25.64
>>570
>個人はビルドできないのかよw 個人はテストも出来ないのかよw

厳密に言うと、正しいソースが入っていないソースでテストするのは
無意味。 誰々さんのリポジトリからのはビルドもテストも問題なかった
けれども、誰々さんのリポジトリだと無理だったとなった時にどう
判断するのかって話だよ。 どっちが優れているという話ではなく、
誰から取ってくるのが正しいソースなのかというのを担保するのは
中央リポジトリみたいのが無いと無理だろってこと。

>中央に集めるのはリリース用のタグ(バージョン番号)をつけるため

タグを付けるのなんてどうでもよくて、そこに正しい最新のものがあると
担保されているのが意味あるわけで、分散厨ってのはそういうのを
わざと無視するよな。 玄孫リポジトリで編集されたものをオリジナルに
送られても手間がかかって面倒なだっての。

572 :仕様書無しさん:2015/07/18(土) 13:28:10.75
> 厳密に言うと、正しいソースが入っていないソースでテストするのは
> 無意味。

無意味? じゃあ修正前のテストは全部無意味ってことになるが?
バグがあった。修正した。

じゃあそのバグが有ったときのテストは無意味?

意味不明なこと言ってるんじゃないよw
テストとそのテストが対象とする
ソースがあれば何の問題もないだろ。

君は小さく作ることを覚えないといけないよ。
小さい範囲でテストできるように設計するということをね。

573 :仕様書無しさん:2015/07/18(土) 13:31:02.70
>>571
お前、わざと無視するよな?

中央があったとしても、最新のソースが有るとは限らないんだが。

svnでも中央から最新のソースを取ってこない限り
個人のソースは最新とは限らない。

svnの中央というのは、中央に送信出来る状態でないと
使いものにならないという意味であって、
中央の最新のソースが常に反映されているという意味ではない。

gitでも中央にマージすれば中央は最新だ。

574 :仕様書無しさん:2015/07/18(土) 15:24:43.24
>>572
>じゃあそのバグが有ったときのテストは無意味?

正しいってのはバグのないソースってことじゃないぞ?
バージョンAに対して修正しました、本当はバージョンCに対して
修正をしなければなりませんでした。このバージョンAに対して
した修正のテストはいったいどのような意味を持つでしょうか?

運良く修正した部分がバージョンAからCに変わるまでに手が
入っていなかったら無駄にはならないが、そういう確率的に
不確かな状況で問題無いと思える方が問題だよ。

575 :仕様書無しさん:2015/07/18(土) 17:20:01.30
>>574みたいな害人が>>1のような変な車速と規約をつくるのだ

576 :仕様書無しさん:2015/07/18(土) 18:16:16.85
>>571
> 玄孫リポジトリで編集されたものをオリジナルに
> 送られても手間がかかって面倒なだっての

あはぁ〜その文章からしてGitをやったことないのがバレバレですね

編集されたものを送られても手間がかかって面倒
編集されたものを送られても手間がかかって面倒
編集されたものを送られても手間がかかって面倒

577 :仕様書無しさん:2015/07/18(土) 18:21:09.80
>>571は、svnレポヂトリを2ヶ所に作ってしまって(なんちゃって"分散リポジトリ")
ファイルをメールでやり取りして、手動パッチ当てるとか糞面倒くさくてバカな事やってるんでしょ?
そういうトラウマがあるからなんて懲り懲りで否定的なんだろうね
送られても面倒ってのはまさにそのトラウマ体験でしょうね

578 :仕様書無しさん:2015/07/18(土) 20:58:33.23
ローカルリポジトリでテストしました
じゃあ出荷判定は通らないよ

579 :仕様書無しさん:2015/07/18(土) 22:05:35.43
コミットしたら
自動でテストして
通らないとコミット拒否
とかが普通じゃないのかよ
ジェンキンズとか

580 :仕様書無しさん:2015/07/18(土) 22:17:35.60
>>574
> バージョンAに対して修正しました、本当はバージョンCに対して
> 修正をしなければなりませんでした。このバージョンAに対して
> した修正のテストはいったいどのような意味を持つでしょうか?

バージョンAが正しく動くという意味を持つが?

そして、バージョンAのあとにバージョンCができるんだろ?

それって、バージョンAに不具合があって、それが
修正されたバージョンCが作られたことと状況は同じだよね?


お前の理屈だと、バグを修正するたびに
以前やったテストは意味がないってことになるわけだが
テスト中にバグ見つからないのかよ?見つけるためにテストやるんだろ。

バージョンAに対してテストしたらのであれば、バージョンAが正しく動くという意味だし
バージョンCができたのなら、そのバージョンCのテストをすればいいだけ。

いったい何が問題?

お前は今、バグが修正されるたびに
(前のテストは意味が無いからというお前の理屈で)
すべてのテストをやっているはずだよね?

581 :仕様書無しさん:2015/07/18(土) 22:21:58.59
gitは便利に使わせてもらってるよ。 ただgitがここまで普及したのは
分散云々ではなく、単純にgithubみたいなホスティングサービスが
あったおかげだろってこと。

582 :仕様書無しさん:2015/07/18(土) 22:26:15.18
品質そっちのけでバージョン管理に夢中なプログラマ達

583 :仕様書無しさん:2015/07/18(土) 22:27:23.63
>>580
>以前やったテストは意味がないってことになるわけだが

xUnit系のカバレッジテストが毎回走るのは以前のテストの
結果のままダメだから再テストを流すわけで、以前やった
テストは意味がないってことだろ。

584 :仕様書無しさん:2015/07/18(土) 22:36:03.56
>>583
xUnitとかの自動テストの話は俺はわかってるよw
あえて明確に言わなかったけどな。

その話でも、以前やったテストに意味が無いわけじゃない。
以前のバージョンに対してやったテストだから
以前のバージョンのテストとして意味がある。


そして新しいバージョンが出来たのだから新しいバージョンの
テストをやる。「たったそれだけのこと」

>>574が「たったそれだけのこと」を問題視している
ってことはどういうことかわかるよね?

絶対>>574はバグが修正されたりして新しいバージョンが出来た時にテストしてない。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

だって自動テストができていれば「たったそれだけのこと」を実行するのは簡単だから。
問題視してるってことは「たったそれだけのことを」してない。

585 :仕様書無しさん:2015/07/18(土) 22:48:40.65
>>582
> 品質そっちのけでバージョン管理に夢中なプログラマ達

バージョン管理しないでどうやって品質を保てるんだ?
バグがどこで入ったか調べるとか
どういったコードの差分を追加するのかとか
コードをレビューするとか
バージョン管理ができていて初めてできることなんだが。

586 :仕様書無しさん:2015/07/18(土) 22:59:25.53
>>585
その考えが正に>>582
もうgitに首ったけwl

587 :仕様書無しさん:2015/07/18(土) 23:06:22.65
チケットのコメントにメールみたいな書き方すんなって文句言ってる管理職が
チケットのコメントにチャットみたいな口語調で書き込みをする
そのチャットを通知メールで通知されて何百人が見てると思ってんだよ
またかよこの馬鹿ってなる

588 :仕様書無しさん:2015/07/18(土) 23:13:47.72
>>586
うん、それでバージョン管理しないでできるの?
それとも出来ないの?

589 :仕様書無しさん:2015/07/18(土) 23:24:53.34
>>588
なんて幼稚な質問だ。
お前はバージョン管理すら満足にできてない。

590 :仕様書無しさん:2015/07/18(土) 23:30:16.26
答えにくい方の答えが正解だようだw
そりゃ能力がないと出来ないよね。

591 :仕様書無しさん:2015/07/18(土) 23:33:03.82
履歴管理
バグ管理
テスト管理

は三位一体
何れが欠けても品質は担保できんy

592 :仕様書無しさん:2015/07/19(日) 00:11:21.51
上2つはコードを管理するためのもので、品質を担保するものではないと思う

593 :仕様書無しさん:2015/07/19(日) 06:57:36.62
狂信的な分散repo反対派がいるな
マジで頭おかしいんじゃね?

594 :仕様書無しさん:2015/07/19(日) 07:16:29.85
バグ作り込んだら昼飯をメンバーにおごる。
恐ろしい事にこのルールは新人にも適用され
昼飯代を一度も払ったことが無い猛者も居たが
新人が生活に困り栄養失調で倒れた事で発覚し問題になった。
勿論辞める新人が多かった。
今思えば単なる新人に飯を集ってただけの悪質なイジメ

595 :仕様書無しさん:2015/07/19(日) 08:33:57.74
svnとgitって共存できるのにね

596 :仕様書無しさん:2015/07/19(日) 08:53:45.79
スキルが低い人間程gitによって与えられる万能感に心酔し
ソースコードの履歴を美しく保つことに必要以上に夢中になる
その行為は開発者としての現実逃避以外の何物でもない

597 :仕様書無しさん:2015/07/19(日) 09:43:23.88
>>592
コードを管理せずに
品質を担保する例を
ひとつ出してほしい

598 :仕様書無しさん:2015/07/19(日) 10:11:31.23
>>597
坊やのパパの資産はgitがない時代に書かれたソフトウェアによって守られているんだよ

599 :仕様書無しさん:2015/07/19(日) 10:14:33.28
>>598
なるほど。
動いているなら弄るなよ叔父さんか。

600 :仕様書無しさん:2015/07/19(日) 10:18:11.67
>>599
正確には「君には無理だから弄るな」なんだけどね
大人は角が立たないように前半部分はハッキリ言わないんだよ

601 :仕様書無しさん:2015/07/19(日) 10:59:19.78
「担保」「品質」「保証」って言葉を使う奴って、メーカー系のSIerで品質保証部とかの部門に居座る奴だよね
そりゃGitと相性悪いわw

602 :仕様書無しさん:2015/07/19(日) 12:29:29.47
たまに根性論言うやつがいるからな。
品質! 担保!って言っていればそれで問題が解決すると思ってる奴。

具体的にどうするか?まで言えないとダメ。
もちろん死ぬ気で頑張るは具体的ではない。

おそらく品質が重要なんだ、テストが重要なんだって
言っていれば、それで俺はちゃんと考えてるって思ってるのだろうが
重要なのは当たり前、それをどうやって実現する言えなければできてないのと一緒。

gitを使ってると言う方がまだ具体的。もちろん何も考えずに
言われた通りのコマンド打って使うだけのやつは意味が無い。

頭を使って考えれば、どこでどんな修正が入ったか、いつバグが入ったかまで調べられる。
その為に自動テストコードも使える。(手動テストでは無理)

具体的にどういう手法で品質を保ってテストを行っているか言える人がいる。
逆に品質が〜テストが〜重要と当たり前のことと言うだけのやつもいる。

603 :仕様書無しさん:2015/07/19(日) 12:32:07.40
>>602
むしろ、どこで修正したか、いつバグが入ったかはソフトウェアの品質には関係ない。
git履歴の見ばえの品質は良くなるかもなw

604 :仕様書無しさん:2015/07/19(日) 12:33:44.02
>>603
ほらねw

あれだけ指摘したのに、理由を何も言わない。
あ、ごめん、言えないんだよね。

605 :仕様書無しさん:2015/07/19(日) 12:36:31.78
ソフトウェアの品質はバグが少ないことだ!

↑これは製品として成り立つ最低限の話であって品質ではない。
品質というのはバグが無い(少ない)というのは
当たり前で、それ以上の付加価値のことだ。

例えばソースコードの可読性がいいとか
テストがしやすいとか重複コードがないとか
シンプルとか小さなファイルに分かれているとか
そういうこと

606 :仕様書無しさん:2015/07/19(日) 12:37:49.27
>>604
なんの指摘をしたつもりだ?お前?
むしろ俺が指摘してるんが?
分からんならもう一度言おう。

gitに夢中になってもソフトウェアの品質は上がらんよ

607 :仕様書無しさん:2015/07/19(日) 12:42:30.65
>>606
だからgitを使わずにどうやって品質を上げるのだ?
「頑張ればできる」じゃないぞ。

品質を上げる方法のほぼ全ての作業が
gitを使えばもっと効率的になるんだよ。

時間は無限にあるわけじゃないぞ。
お前が言ってるのはどうせ時間(または人件費)をかければ
品質はあげられるのだっていうことだろう?

608 :仕様書無しさん:2015/07/19(日) 12:43:08.88
>>605
それソフトウェアの品質じゃなくて開発者の自己満足だよね

609 :仕様書無しさん:2015/07/19(日) 12:43:56.76
最初から完璧に作れば品質は上がる。

それができれば苦労はしない。
コードを何度も見なおして完璧な形に
修正していくことが品質を上げる方法。

もちろんgit使えば効率的にアンル。

610 :仕様書無しさん:2015/07/19(日) 12:45:19.37
>>608
違うよw

これらをやれば開発が効率的に
スピーディーになる。

MicrosoftがWindows 10のベータ版を
一週間に3回もリリースした話知ってる?

これが今の時代のスピード。
お前のやり方ではこのスピードに対応できない。

611 :仕様書無しさん:2015/07/19(日) 12:45:47.03
>>607
ほう、ならばgitを使って要求仕様の誤りを是正する方法を教えてもらおうか?

612 :仕様書無しさん:2015/07/19(日) 12:46:53.54
ソースコードが小さくわかれていなければ
人をたくさん集めても平行して開発が行えない。

人さえ集めれば開発速度が上がる・・・わけはないんだよ。

ソースコードが汚ければ、新たな人が参加しても
理解するのに時間がかかる。

ソースコードの綺麗さも重要。

人さえ集めれば開発速度が上がる・・・わけはないんだよ。

613 :仕様書無しさん:2015/07/19(日) 12:47:29.84
>>611
それは仕様の品質であって
ソフトウェアの品質ではない。

食べられれば、品質はなんでもいいって
考えの人ですね。

614 :仕様書無しさん:2015/07/19(日) 12:48:46.77
>>610
なんで3回もリリースしたん?
品質が高かったら何回もリリースする必要ないような。
開発者の自己満足だよね☆(ゝω・)v

615 :仕様書無しさん:2015/07/19(日) 12:48:58.46
顧客の要求の中で言わなくても絶対に含まれている要件が有る。

それは、

・バグが少ないこと
・開発速度が早いこと

これらを実現するのが

例えばソースコードの可読性がいいとか
テストがしやすいとか重複コードがないとか
シンプルとか小さなファイルに分かれているとか
そういうこと

616 :仕様書無しさん:2015/07/19(日) 12:49:25.73
>>613
それを言うなら
ソフトウェアの品質とはバグの数の事ではない。
お前は根本的に誤解している。
コーダー脳とはこの事。

617 :仕様書無しさん:2015/07/19(日) 12:50:17.52
>>614
> なんで3回もリリースしたん?

3回リリースできるほどの
(Microsoftにとっては)長い時間があったからw

平行して開発できるほど
きれいな構造になっているということ。

618 :仕様書無しさん:2015/07/19(日) 12:51:37.12
>>615
十分にテストされて十分に稼働実績のあるプログラムコードをコピペして
新たにプログラムを拵えればバグがないし開発速度は速いよ。
これが枯れた技術を使うってこと。プログラマなら自分で
プログラム書きたい衝動に駆られるだろうけど、それって結局自己満足に過ぎないよね。

619 :仕様書無しさん:2015/07/19(日) 12:51:38.45
>>616
じゃあお前の言う品質とは何だ?

要求仕様は品質ではないぞ。
たんなる要求だ。

飯が食いたいとかいうもの。
お前が言ってるのは才芸源の要求であって
品質ではない。

620 :仕様書無しさん:2015/07/19(日) 12:52:25.19
× 才芸源
○ 最低限

621 :仕様書無しさん:2015/07/19(日) 12:52:51.48
>>617
時間があるってだけでリリースするん?
まとめて1回でリリースすればいいじゃん。
きれいな構造かどうかは中見ないとわからないじゃん。
中の人なの?

622 :仕様書無しさん:2015/07/19(日) 12:53:43.32
>>618
> 十分にテストされて十分に稼働実績のあるプログラムコードをコピペして
> 新たにプログラムを拵えればバグがないし開発速度は速いよ。

それは逆に遅いことが明らかになってるw
わざとらしい例を出すな。

「可読性」という言葉に含まれているのは
「読」という漢字だ。

コードが増えれば増えるほど読む時間は増える=開発速度が遅くなる。

623 :仕様書無しさん:2015/07/19(日) 12:55:37.92
>>621
> 時間があるってだけでリリースするん?

できることなのにリリースたらダメなん?w

お前はOSという大規模な物を修正したあと
短時間で全てのテストが実行できる?

MSはテストを自動化していることの
成りよりの証拠だ。


テストの自動化(効率的に行う)には、

例えばソースコードの可読性がいいとか
テストがしやすいとか重複コードがないとか
シンプルとか小さなファイルに分かれているとか
そういうこと

が必要になる

624 :仕様書無しさん:2015/07/19(日) 12:55:52.50
>>619
は?仕様が品質そのものだ。
仕様の品質が保たれなければ、後工程全てに影響を与える。
そもそも要求と全く別の物が完成する事すら少なくない。
世の低品質と言われるソフトウェアの全ては、その仕様の品質の低さに起因している。
もちろんバグもな。

625 :仕様書無しさん:2015/07/19(日) 12:56:00.25
>>622
明なかになったなんてことは聞いたことがないな。
コピペで作ったプログラムはバグが少なかったっていう話なら聞いたことあるが。
クラス名や関数名にわかりやすい名前を付けて抽象化しておけば全部読まなくていいだろ。
いちいちここで変数の値がインクリメントされてとか読んでるわけ?それってありえなくない?

626 :仕様書無しさん:2015/07/19(日) 12:57:14.18
>>623
短期間に何回もリリースしたのはテストしてないことの証拠かもわからないじゃん。
中の人じゃないとわからないよね。中の人なの?

627 :仕様書無しさん:2015/07/19(日) 13:01:10.15
ユーザーはWindowsをインストールしたときにスケジューラがどうとかペイントがどうとか
アイコンがどうとか隅々までテストしてるのかって話。しないだろ。
製品として出荷されている以上品質は保証されていると思うものだからだ。
コピペでプログラムを作るっていうのはそれと同じこと。
これまでの稼働実績のある品質の高いコードを使用するってこと。
つまりテストせずとも品質は保証されてる。

628 :仕様書無しさん:2015/07/19(日) 13:01:27.89
>>624
> は?仕様が品質そのものだ。

これで勘違いしていることがはっきりしたねw

仕様は仕様だろ。
品質ではない。

同じ仕様でありながら品質が違うものが
作れるだろう?仕様は品質ではないという証拠。

629 :仕様書無しさん:2015/07/19(日) 13:02:17.55
仕様と品質を勘違いしているレベルか
こりゃ話にならないねw

630 :仕様書無しさん:2015/07/19(日) 13:04:32.31
>>628
違う違う。その解釈は早とちりだ。
起因するって言ってるんだから仕様によって
製品の品質が左右されるってことを言ってるんだろ。
仕様と品質がまったく同じと言ってるわけじゃないぞ。

631 :仕様書無しさん:2015/07/19(日) 13:05:32.35
>>628
> 同じ仕様でありながら品質が違うものが
> 作れるだろう?仕様は品質ではないという証拠。
もし実際にこんな事が起こるとしたら、そもそもの仕様の品質が低い事が原因だな。

もっとまともな仕様書くれるとこから仕事貰えよ。

632 :仕様書無しさん:2015/07/19(日) 13:06:28.92
昔、コピペされたコードにバグがあって
十数ヶ所に分散したコードを直すハメになった事があるが…
おまえが犯人だろw

633 :仕様書無しさん:2015/07/19(日) 13:09:48.58
>>632
コピペ元のコード書いたやつが犯人に決まってるだろ。
稼働実績が十分にある品質の高い枯れたコードをコピペしとけば問題なかった。
普段からコピペを馬鹿にせずコピペスキルを磨いておくことをお勧めする。

634 :仕様書無しさん:2015/07/19(日) 13:26:29.19
1.拡張性を考えて作るべきだ
2.仕様を満足すれば十分だ

のせめぎあい。
2なら円周率を10桁計算しろの課題に
return 3.141592654;
でも良いわけだよ動きゃ。

635 :仕様書無しさん:2015/07/19(日) 13:41:47.53
突然どこにも書いてない事を読みとってしまった>>634

636 :仕様書無しさん:2015/07/19(日) 13:53:31.29
いやまあわからんでもないけどな。
あれだろ拡張性を考えるかどうかってことだろ。

637 :仕様書無しさん:2015/07/19(日) 14:22:39.24
品質、保証、担保、開発効率ってキーワードをやたらと連呼する人は
具体的にどうすればよいか分からないから
恐喝的な態度で人を動かそうとする

プログラミングできないSE(笑)によくいる

キミもそんなクズに遭遇したことないか?

638 :仕様書無しさん:2015/07/19(日) 14:26:06.95
ここはプログラマ板なのに、またSE(笑)が紛れ込んでるのか
いい加減にしろよ!

639 :仕様書無しさん:2015/07/19(日) 15:09:10.68
君の嫌いなSEですよ、呼んだ?

ちょwww君www君のコード汚なすぎるよwwwww
明日までにちゃんと直しておけよ

640 :仕様書無しさん:2015/07/19(日) 15:16:15.02
>>638
なあSEって何?
SEとプログラマなどというナンセンスな分類をしてるのは日本だけ。
ソフトウェアの機能定義や設計、実装、品質管理やテストを行うのもプログラマの仕事だ。

ところでまさかコーダー(笑)がこのプログラマ板に紛れ込んでるんじゃないだろうね?
仕様書渡されてコーディングするだけの人は、プログラマではないからね。

641 :仕様書無しさん:2015/07/19(日) 18:32:03.91
ここ数日「gitだめ」って言ってる人(多分一人)は、
自分が信奉している開発手法にはgitは合わない・使えない
って信じちゃってたりするんじゃねえかと思った。

642 :仕様書無しさん:2015/07/19(日) 19:22:49.89
>>641
> 自分が信奉している開発手法
はいダメ〜
この発想がもうダメ

643 :仕様書無しさん:2015/07/19(日) 20:06:55.13
>>640
それは要するにセックスエンペラーの事だ
この業界の常識なので覚えてちょんまげ




(´・ω・`)b

644 :仕様書無しさん:2015/07/19(日) 20:29:12.85
git使ったって減るもんじゃなし
そんなに毛嫌いする理由がわからん。

645 :仕様書無しさん:2015/07/19(日) 21:30:20.33
gitを毛嫌いしてるわけじゃなくて、
gitに心酔してる人が気持ち悪いという話だと思う

646 :仕様書無しさん:2015/07/19(日) 21:41:40.00
Gitが怖い・・・怖いよぅ
コマンドが怖い・・・怖いよぅ
分散するの怖い・・・怖いよぅ

647 :仕様書無しさん:2015/07/19(日) 21:43:53.77
Gitインストール&使用禁止の規約も存在するんじゃね?

648 :仕様書無しさん:2015/07/19(日) 21:46:36.65
Gitは一種のパラダイムシフトだからな
ついて行けない/行かない人がいるのも分かる気がする

649 :仕様書無しさん:2015/07/20(月) 01:36:51.16
過去のスタイルから変えれないついてこれないのが僻んでるだけ
そんな人にはvssだけ使わせておけばいいさ

git使わせたってコマンド打てないでしょ

650 :仕様書無しさん:2015/07/20(月) 01:46:39.01
使えない人って、可哀想w

651 :仕様書無しさん:2015/07/20(月) 06:55:33.29
RPGで[GO TO]文を使え!

652 :仕様書無しさん:2015/07/20(月) 07:09:09.82
そろそろ>>1の話をしないか?

653 :仕様書無しさん:2015/07/20(月) 07:10:46.41
>>648
>Gitは一種のパラダイムシフトだからな

そんな大げさな(´∀`)

たぶん gitの開発者の一人ががグーグルの
日本人だから嫌ってるんだと思う。

654 :仕様書無しさん:2015/07/20(月) 08:10:48.21
git嫌いとか一言も言ってないんだけど
>>645が正解

655 :仕様書無しさん:2015/07/20(月) 12:33:07.03
そりゃ使った事も無いのに
好きも嫌いもないもんだしな。
下っ端にドヤ顔で言われるのが嫌いなだけ
こういうのが人事権持ってると

git 禁止とかいう社則になる訳だよ。

656 :仕様書無しさん:2015/07/20(月) 14:46:27.47
大半が中央リポジトリにpush、pullしてるだけの運用なのに
分散スゲーと言うやつが多いからそれはちょっと違うでしょと
言っているだけなのになあ。
gitは他のに比べてマージが便利だからそれだけでも使う価値は
十分あると思うけど。

657 :仕様書無しさん:2015/07/20(月) 15:24:38.68
>>656
お前相手が一人だとでも思ってるの?

push、pullしてるだけの運用の人"だけ"に
それはちょっと違うでしょって言えよ。
ちゃんと確認してから言うこと。全員に言うなって。

658 :仕様書無しさん:2015/07/20(月) 15:44:45.21
そろそろ>>1の話をしてみないか?

659 :仕様書無しさん:2015/07/20(月) 15:47:38.23
git使ったことないのだけど、
svnとの違いと優れてる点をおしえてちょ

660 :仕様書無しさん:2015/07/20(月) 16:09:26.41
svnはブランチの作成と切り替えが遅すぎる。
ネットワークに接続するから当然だが。

gitだとディレクトリ切り替える速度で変更できるんだよ。
これだと突発的な割り込み作業。

つまり、あれ作ってる間に見つかる、これ作らなきゃっとか
これ修正しておかなきゃという、よくある問題を迅速に解決できる。

661 :仕様書無しさん:2015/07/20(月) 17:35:26.81
そろろそ>>1の話をしてみないか?

662 :仕様書無しさん:2015/07/20(月) 18:33:53.94
自分ですればいいだr

663 :仕様書無しさん:2015/07/20(月) 18:38:17.97
残業8hで代休1日って世間一般的には有りなの?

664 :仕様書無しさん:2015/07/20(月) 18:59:25.91
>>663
アリだよ。
法律的にも残業8h分の割増賃金が支払われれば問題はない。

665 :仕様書無しさん:2015/07/20(月) 19:05:54.42
>>664
あーいやそういう法律どうこうの話はどうでもいいんだ
実際に有りだと思うのかんなもん要らねーよって思うのかどうか

666 :仕様書無しさん:2015/07/20(月) 19:09:01.92
残業してる奴隷が代休なんて取れるわけないだろ。
休日だって休めないのに。

667 :仕様書無しさん:2015/07/20(月) 19:17:34.03
有休も代休も権利の筈なのに後であの有休は代休に変えといてねって言われるとすげー騙されてる感が漂うんだよね
そんなに有休使わせたくないのかと

668 :仕様書無しさん:2015/07/20(月) 19:21:49.56
そういう制度ができたら、代休とるために残業する馬鹿が沸くから
制度自体できないだろうね。

669 :仕様書無しさん:2015/07/20(月) 19:59:45.95
>>668
話が180°ズレてる

670 :仕様書無しさん:2015/07/20(月) 20:32:30.46
さすがすれ違いネタばかり投入される素敵な連中だわ

671 :仕様書無しさん:2015/07/20(月) 20:38:34.91
プログラマのコミュ力が推し量れる良スレ。

672 :仕様書無しさん:2015/07/21(火) 06:27:08.68
残業代惜しさの代休だから
さらに代休休日出勤とか
以下無限

673 :仕様書無しさん:2015/07/21(火) 13:29:32.39
休日出勤の割増率て普通の残業より高くならんかった?

674 :仕様書無しさん:2015/07/21(火) 14:12:48.57
>>673
高いよ

675 :仕様書無しさん:2015/07/21(火) 14:30:52.96
>>674
なら、社則で残業8hで代休取得要となっていてのなら8h分の普通残業+休日出勤分ということか

676 :仕様書無しさん:2015/07/27(月) 14:51:25.58
【OS】全ての「Windows」に深刻な脆弱性 緊急パッチが公開 [転載禁止] 2ch.net
http://anago.2ch.net/test/read.cgi/bizplus/1437462980

677 :仕様書無しさん:2015/07/27(月) 14:54:49.40
失礼、誤爆った

678 :仕様書無しさん:2015/07/28(火) 16:48:25.64
昨日から入った客先だが、
コーディング規則に「修正前コードはコメントアウトして残す」との記述…。

679 :仕様書無しさん:2015/07/28(火) 16:54:48.59
>>678
今すぐ帰ってこいよ。
そんな地雷職場にいる必要はないぞ。

680 :仕様書無しさん:2015/07/28(火) 17:09:43.06
>>679
初日からすでに帰りたいよ…。

ソース管理はsvnだ。
懐かしいわ。

681 :仕様書無しさん:2015/07/28(火) 17:16:51.64
>>680
君が、自分の給料のためではなく、日本の未来のためには
何をすればいいか理解している良いPGであることを
期待している。

682 :仕様書無しさん:2015/07/28(火) 17:30:04.04
>>681
数十人規模の、既に始動しているプロジェクトで、孫請けで後発の俺に何をしろと…。

てゆうか、自分の給料の方が大事だ。
おばあちゃんの介護施設の費用を稼がなきゃならないんで。

683 :仕様書無しさん:2015/07/28(火) 17:37:15.44
>>682
こういう、後発だからとか孫請けだからと自分を納得させて
巨悪を前に自分も悪事に手を染めていく人生にはそろそろ
ピリオドを打ったほうがいいんじゃないかな。
君には巨悪を倒す力があるはずだ。

684 :仕様書無しさん:2015/07/28(火) 17:58:13.54
悪事ってww

685 :仕様書無しさん:2015/07/28(火) 21:15:22.38
>>680
そのコーディング規則にsvnは、
うちが元請の可能性も・・・。
同意見だが、俺には変える権限が無いんだ、すまん。orz

686 :仕様書無しさん:2015/07/28(火) 22:38:37.29
>>678
俺もそれみたことあるわ。
完全に消去してやった。
ただし、提出用に古いコードを全コピーしたファイルは作った。

687 :仕様書無しさん:2015/07/28(火) 22:41:45.84
>>685
お前が諸悪の根源か!
勘弁してよ、もう〜〜

688 :仕様書無しさん:2015/07/28(火) 22:48:04.76
685を倒せば全世界32億人のPGの命が助かるわけだ。
とりあえずちょちょいとコメントアウトされた修正前処理を全消ししとけよ。

689 :仕様書無しさん:2015/07/28(火) 23:21:28.36
とりあえずそういうクソコーディング規約を
twitterやらなんやらでディスりまくらないといけないな。
プログラマじゃない人にまで伝わるぐらいに広めるにはどうすればいいか。

690 :仕様書無しさん:2015/07/28(火) 23:49:33.05
まあ例外として、変更前のコードを主として限定的にカスタマイズするプロジェクトなら
カスタマイズ仕様を明示するコメントと共に前のコードを残しておくのはいいけどね

691 :仕様書無しさん:2015/07/29(水) 02:00:42.11
そんな例外はない認めん

692 :仕様書無しさん:2015/07/29(水) 18:46:22.57
> そんな例外はない認めん

誰かと誰かがこういうやり取りを経て、また別のクソ規約が生まれていくわけですな。

クソ規約が生まれ続ける法則より

693 :仕様書無しさん:2015/07/29(水) 21:18:12.60
今時svn使ってるところはIT企業は馬鹿揃い
恥を知れ!

694 :仕様書無しさん:2015/07/29(水) 21:18:58.51
うむ日本語が変だった(恥

695 :仕様書無しさん:2015/07/29(水) 21:36:34.30
よっぽど興奮してただな

696 :仕様書無しさん:2015/07/29(水) 22:43:37.94
>>693
svnなかなか便利でおススメだよ!
ただファイルのタイムスタンプが変わるのが玉にキズだけどね
簡単に使えるから試しに使ってみて d(゚ー゚*)ネッ

697 :仕様書無しさん:2015/07/30(木) 00:20:16.62
全角文字アルファベット禁止

698 :仕様書無しさん:2015/07/30(木) 00:33:45.12
svn楽だし枯れてていいじゃん。
今は何がいいの?
gitはよくわからん。

699 :仕様書無しさん:2015/07/30(木) 01:39:51.37
中央はsvnだけど、クライアントはgit svnとかはよくある

700 :仕様書無しさん:2015/07/30(木) 09:06:22.65
>>698
gitがいい。

よくわからないというのは
お前の問題であって、
gitの問題じゃない。

701 :仕様書無しさん:2015/07/30(木) 09:13:03.91
gitがいい理由は説明可能だが、説明するのが面倒
だからこういう考え方をすればいい。

多くのプロジェクトでgitが採用されている。
svnからgitに乗り換え事例がたくさんある。
面倒なだけなら乗り換える人はいない。

だから少なくともgitの方が優れているという理由があると仮定できる。
その理由が事実でなかったとしてもだ。

つまりgitに乗り換える理由があるか?という質問は、
乗り換える理由を知っているか? という質問に置き換えることが可能。
理由を知らないならば、知識不足だということになる。

702 :仕様書無しさん:2015/07/30(木) 09:38:40.00
なんであれ使ってるだけ10000倍マシ

気軽に「こんなソフトありませんか?」Part.169 [転載禁止](c)2ch.net
http://anago.2ch.net/test/read.cgi/software/1432025255/833

833 名前:名無しさん@お腹いっぱい。[] 投稿日:2015/07/29(水) 23:14:31.83 ID:3sTMkah10
ディレクトリAは開発前、ディレクトリBは開発後のファイルが10000程度入ってるのですが、どのファイルを変更したのか分からなくなってしまいました。

ディレクトリAとディレクトリBの中身が違うファイルだけを抜き出して一覧化したいのですが、何かよいソフトはありますか?
ただし、タイムスタンプはあてにならないとします。


Windows7 36bitマシンです。

703 :仕様書無しさん:2015/07/30(木) 09:44:40.17
同一Path同一ファイル名のファイルをByteコンペアして
違いがあったら差分表示してLog化する様なTOOLを作ればよい

704 :698:2015/07/30(木) 09:46:42.32
gitが優れているのはわかるんだけどさ、
なんか過ぎた道具感が強くてね。
Hello world作るのにVisual Studio使ってTFSでソース管理する的な?

分散リポジトリとか簡単に解説されているメリット以上のメリットが
あるだろうことは予想はつくんだけど、過ぎた道具を与えて
教育コストは見合うのとか、機能使うな、ってことで制限しても
有名なだけに全機能使いたい馬鹿は一定数いて、それをどう抑止するか
とか考えると、svnから移行するのもめんどくさい、ってところ。

俺が勉強するコストは、まあ今でも使ってるというか使われている程度には
触ってるしどうせ習得するもんだからいいんだけどね、他人がある話なので
あーめんどくせってところ。まあ涼しくなってからだな。

705 :仕様書無しさん:2015/07/30(木) 09:54:43.61
いいから勉強してからそのくさい口開けよ無能

706 :仕様書無しさん:2015/07/30(木) 10:09:20.36
36bitかー
どこのCPUなんだろうなぁ

707 :仕様書無しさん:2015/07/30(木) 11:11:25.74
36bitフイタw
ファイルバックアップ運用でも
gitならわざわざリポジトリ作らくても自分だけ管理できるからいいな

708 :678:2015/07/30(木) 17:38:56.88
上で書いた「修正前のコードはコメントアウトして残す」客先の、
自社フレームワークの資料読んだ。

なんて言うか、懐かしい感じの造りで、
「枯れた技術を使う」ポリシーだから、
「DIコンテナは使わない」そうです。

709 :678:2015/07/30(木) 17:51:34.63
開発は究極のウォーターフォールって感じ。

設計は『オブジェクト志向?何それ』レベル。
クラスは、すべて画面orレコードor関数を集めただけのモジュール。

710 :678:2015/07/30(木) 18:03:25.79
設計
ほぼプログラムそのものレベルの細かさまで日本語で書く。
読みにくい。
もちろんオールExcel。シート多すぎ。

開発
上の設計書を淡々とプログラミング言語に訳す。
外部APIもデザインパターンも使わない。
これまでの経験は何も活かせない。

テスト
xUnitとか使わない。
日本語でテスト仕様書を淡々と書く。
もちろんオールExcel。

711 :仕様書無しさん:2015/07/30(木) 18:07:03.22
教育コスト
勉強するコスト
ってw

いやいや勉強してるなら、ソフトウェア業界から消えてほしいわ
害悪なんで!

712 :仕様書無しさん:2015/07/30(木) 20:16:49.10
>>700-701
gitがいいというこれだけの文章の中に、
gitがいい理由をただの一つも入れていないのがムーディーだわ

713 :仕様書無しさん:2015/07/30(木) 20:48:02.60
>>711
そんだけ日本語の理解力が足りないと日本で生きていくのつらいでしょ?
半島にお帰り。

714 :仕様書無しさん:2015/07/30(木) 20:50:20.77
だってgitなんて流行というだけで
なんのいいところもないんだもんw

715 :仕様書無しさん:2015/07/30(木) 20:57:20.52
バグだらけだしな

716 :仕様書無しさん:2015/07/30(木) 23:08:01.12
>>710
SIerらしいルールですな
結構なことでございます

717 :仕様書無しさん:2015/07/30(木) 23:47:01.68
>>708-710
笑ってはいけないSIer みたいだね

718 :仕様書無しさん:2015/07/30(木) 23:51:48.44
笑ってはいけないで済めばいいが、
人死にがでないようにな。

719 :仕様書無しさん:2015/07/30(木) 23:59:42.02
>>704
> Hello world作るのにVisual Studio使ってTFSでソース管理する的な?

さすがにHello Worldでgitを使えとはいわんよw

分散開発はわかっているようだから、それ以外の例で言えば

複数人の開発を行うのであればgitを使え。
複数の機能を並行で開発するならgitを使え。
使い捨てではないプログラムを作るのであればgitを使え。
マージ機能を使うならgitを使え。
リリースを頻繁に行うのならgitを使え。
リグレッションテストとバグの修正を効率的に行いたいならgitを使え
cd(change directry)並みの速さでブランチの作成、切り替えを行いたいならgitを使え。
ファイルのバックアップ管理ではなく、ソフトウェアのバージョン管理をしたいならgitを使え。


これらのどれにも当てはまらないものは
git使わなくていいよ。

720 :仕様書無しさん:2015/07/31(金) 00:03:37.97
>>708
> 「枯れた技術を使う」ポリシーだから、
>「DIコンテナは使わない」そうです。

実際にDIコンテナを使わせてみて、
正しく使えるなら、ポリシーで選んだと認めよう。


どうせDIコンテナを使えないから
使わないと言っているだけだ。

721 :仕様書無しさん:2015/07/31(金) 12:27:45.05
と、ただ使えるだけの人が申しております。

722 :仕様書無しさん:2015/07/31(金) 12:30:43.38
使える人ならいいけど、使われてる人の可能性大。

723 :仕様書無しさん:2015/07/31(金) 13:03:46.96
DIコンテナって組み込みCでは単にROM容量と労力が増えるだけな気がする。

724 :仕様書無しさん:2015/07/31(金) 13:11:22.15
組み込みでDIコンテナみたいなモデルが必要と認識した時点で
なんか狂ってんじゃね?

725 :仕様書無しさん:2015/07/31(金) 15:06:01.64
このスレではDIコンテナとDIは同義です

726 :仕様書無しさん:2015/07/31(金) 19:24:30.40
組み込みならコールバック

727 :仕様書無しさん:2015/08/01(土) 00:14:07.81
gitはマージが便利だな。分散云々でローカルコミットが出来る!みたいな
ことを売りみたいにいう人がいるが、Eclipseなんてそれこそ十何年も前から
ローカルの編集履歴を自動的に取っていて、自由に参照戻しが出来る。
そういうのを知っている、使っているとコミットタイミングでしか履歴が
残らないっていうのはそれほど売りじゃなくなる。

それに比べマージはSVNやCVSなんかでどうやっても面倒だったのが
えらく簡単に出来るようになったので重宝する。 gitbookなんかだと
コンフリクトした時はp4mergeみたいな3wayマージツールを使って
やるのがいいということが書いてあるが、web上で引っかかるのは
ファイル開いて目視で見つけて、手で直すみたいなお馬鹿な記事が
多いからハードルが高いように思われている部分がある。

728 :仕様書無しさん:2015/08/01(土) 00:23:27.23
>>727
gitつかったことないんだが
どうやってマージしてくれるの?

おしえてガリレオ

729 :仕様書無しさん:2015/08/01(土) 01:30:27.51
>>728
他のと同じでコマンド叩くだけだな。
A→B→C'→D
 ?C?
うえみたいにAからブランチ切ってCの修正を入れて、Aに
戻すみたいなのはよくあると思うが、svnなんかだとC'に
するときにBがないと素直に戻るが、Bがあるとちょっと
面倒な挙動をする時が多い。 gitの場合だと特に何事も
無かったかのようにC'として元のリポジトリに戻る。

BとCで同じファイルに修正が入っていてもBは1行目、Cは
20行目みたいに明らかに修正箇所が離れている場合は
コンフリクトをせずに自動的にマージされる。 svnなんかだと
修正箇所に関係なく、同じファイルをさわっていたらコンフリクト
として判定されて解消する必要がある。gitの場合は明らかに
同じ箇所を修正したような状況じゃないとコンフリクトとして
判定されない。バイナリファイルの場合はgitもsvnもだいたい
同じような状態になるけどね。

なのでgitの場合はちょっとブランチを切って(トピックブランチを
作ると表現されることが多い)、修正をして問題なかったら元の
リポジトリに戻すというような開発手法になることが多い。

730 :仕様書無しさん:2015/08/01(土) 01:58:50.02
昔のcvsのブランチ間マージもそんな感じだと思うけど。
何が違うん?

731 :仕様書無しさん:2015/08/01(土) 05:36:14.42
>>725
> このスレではDIコンテナとDIは同義です

やめてくれwww

「DIは要らない。なぜならDIを使わなくても
○○言語なら、こうすればいいからだ。」

というセリフの正しい意味は

「DIコンテナはいらない。なぜならDIコンテナを使わなくても
○○言語なら、こうすればDIできるからだ」

ということだよなって、この間思ったばかりだ。

そして、続きは

DIコンテナを使わないでDIすると、
出来なくはないが、意図が明確にならずに
可読性が悪くなるから、○○言語でもDIコンテナを使った方がいい。
○○言語におけるDIコンテナは、コーディングスタイル規約のようなもの
なくてもいいが、あればコードが統一できる。

732 :仕様書無しさん:2015/08/01(土) 05:39:02.74
>>727
Eclipseがどうとか言ってるが、

ローカルコミットは便利だ。
Eclipseでも独自にローカルコミットを実装していたほどだ。

という意味だよね?それ

人生をEclisepに依存させるの嫌だしw

733 :仕様書無しさん:2015/08/01(土) 06:33:38.76
>>730
ブランチを切り替えるのがえらく速い。
あとマージの失敗が少なくなった。
俺もgitにしてから機能ごとにブランチを分けるようになった。
本流を経由してそれぞれのブランチに変更をマージすれば
衝突もほとんど起こらないし。

734 :仕様書無しさん:2015/08/01(土) 11:14:34.89
>>732
結局EclipseからGitでもsvnでも好きなの使うのが一番いいんじゃないか

735 :仕様書無しさん:2015/08/01(土) 12:04:42.31
>>730
原理原則は同じだな。 ただそれをストレスフリーに近い状態で
出来るようになったのがgitのマージかな。 cvsやsvnだと本流に
マージするときなんかは、これからマージするからみんなコミット
待ってーとかいうのがあったけど、そういうのはほとんどなく
作業が出来る。

>>733はブランチ切り替えるのがえらく早いってかいているけど、
切り替えが早いからブランチを作って作業してるんじゃなくて、
マージが楽だからブランチ作って作業する気になるんだとオレは
思うんだよね。 だいたい今作業しているファイルが切り替わる
より、別ディレクトリに分けておくほうが意図しない修正が混じる
リスクは減らせるから早い遅いの問題じゃないし、そういリスクを
考えてもgitを選ぶという部分ではある。

まあ、ここらへんのは実際に使ってみないと分からないものだし
複数バージョンを平行して開発するようなプロジェクトじゃないと
実感しづらい部分ではあるけど。

736 :仕様書無しさん:2015/08/01(土) 12:07:05.84
>>732
ローカルコミットじゃなくて、ファイルを保存したらそのスナップショットが
取られているのでコミットしたとかしないとかそういうレベルの話じゃない。
別にEclipseに限らず今どきのIDEならそれくらいしてるでしょ。テキスト
エディタしか使わないような原始的な開発方法をしているところは別
でしょうけどね。

737 :仕様書無しさん:2015/08/01(土) 12:36:27.17
大量のゴミ履歴なんかあってもクソの役にもたたん。
IDEがない時代から変わらない事実。

738 :仕様書無しさん:2015/08/01(土) 12:51:06.63
ゴミは役に立たないだろ
意味不明

739 :仕様書無しさん:2015/08/01(土) 14:16:53.72
>>738
> ファイルを保存したらそのスナップショットが
> 取られているので

それタダのバックアップじゃんw

コミットというのは自分が意味があるという
単位に名前をつけることだよ。

名前をつけるということは、その場所に
移動したり戻ったりしたり知るということ。

勝手に取られるのは何の意味もない。

740 :仕様書無しさん:2015/08/01(土) 14:21:18.08
いいかげんこっちでやれ

バージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/

741 :仕様書無しさん:2015/08/01(土) 15:39:18.71
git 禁止から始まったけど
ちょっとしつこいかな。

なんでgit禁止だったのか忘れちゃった。

742 :仕様書無しさん:2015/08/01(土) 16:10:50.19
特定のソフトウェアや開発手法の導入に頑なに反対する人たちの層って、
>>1で言うところの変なコーディング規約に固執する人たちの層と思いっきり被るんだよね

gitはスレ違いかもだけど、カキコしてる内容の根っこは一緒のような気がするわ

743 :仕様書無しさん:2015/08/01(土) 16:22:30.06
>>742
むしろ頑なに導入しようとする層と、ケースバイケースで別でもOKという層しかいないと思うが。

744 :仕様書無しさん:2015/08/01(土) 16:32:17.50
ケースバイケースの、
導入しないほうが良いケースなんて
現実的じゃないだろ?

745 :仕様書無しさん:2015/08/01(土) 17:18:48.65
プロジェクトライフサイクルの状況によって変わるだろ。
何もない手探りでやっているならどの時点でも導入するほうが効果あるけど、
安定していて動いているものがある場合に、わざわざコストを払ってまでやる
ほどの価値があるかって話だろ。

746 :仕様書無しさん:2015/08/01(土) 21:12:05.15
いまどき生産性を重視しない仕事なんて有るの?
今日より明日、明日より明後日、常に生産性を
上げていかないといけないのに、どうやって生産性を上げるのさ?

これって社会人一年生で学ばなかったか?
常にもっと良いやり方はないか考えることって。

別に何かを導入しなくてもいいけど
それその導入するの物代わりに自作するって話。
たいていは時間かかって品質も落ちるけど、
それだけのコストをかける価値があるならそれをやってもいい。

いずれにしろ仕事は常に改善していくべきなんだけど
社会人としての自覚有るのかな?

747 :仕様書無しさん:2015/08/01(土) 21:35:58.52
やらない事の
言い訳ばかり
上手くなり

748 :仕様書無しさん:2015/08/01(土) 21:37:59.04
わかんねっすw先輩支離滅裂っすw自覚あんすか?…wwww

749 :仕様書無しさん:2015/08/01(土) 21:38:08.28
やらない言い訳なんて、全部面倒くさい。
責任取りたくない。新しいこと覚えられない。
のどれかだろ。

社会人一年生かよw

750 :仕様書無しさん:2015/08/01(土) 21:41:45.78
プログラマはどっちかと言うよやりたい言い訳ばっか考えてるよな
それ要らないのに

751 :仕様書無しさん:2015/08/01(土) 22:50:17.57
そりゃやった方が効率が上がるからねぇ。

752 :仕様書無しさん:2015/08/01(土) 23:03:05.77
要するに自分で穴を掘ってまたその穴を埋める。
そんな、誰にも望まれない仕事をやりながら、必死こいて効率化を叫んでるのが今の君たち。
穴掘りピエロやね。

753 :仕様書無しさん:2015/08/01(土) 23:16:50.03
なおコードはすべて MISRA 準拠とする

754 :仕様書無しさん:2015/08/02(日) 00:14:19.27
>>752
わかるわかるw

汚いコード書いて、
自分でそのコードを解読するのに苦労してるのw
見てて情けなくて笑える。

問題が起きた時に、自分で書いたコード見ながら
どうこういう場合にこういう問題が起こって
それを対応するのは、難しいですねとかいっちゃってるの。

755 :仕様書無しさん:2015/08/02(日) 07:40:35.06
>>746
導入工数だけで何億円もかかるなら変えない方がいい

756 :仕様書無しさん:2015/08/02(日) 11:41:12.23
>>678
去れ素早く去れ
居たら腐るぞ

757 :仕様書無しさん:2015/08/02(日) 11:43:55.65
>>693
svnならいい方じゃん
VSSなとこだと最悪だぜw

758 :仕様書無しさん:2015/08/02(日) 12:00:42.53
>>739
コミットを意味のある単位にしたいけど

実際はバックアップなんだよな

759 :仕様書無しさん:2015/08/02(日) 12:23:58.19
流れを読まずに新ネタ投下

昔、初めて行った客先でのこと。
プロジェクト内ルールとして、
・作業中の会話禁止
・連れ立って休憩に行ってはいけない
・質問はリーダーにしかしてはいけない
と言われた。
つまり、横の繋がりを一切禁じていた。

メンバーの紹介もプロジェクトの説明もなかったので、フロアのどこからどこまでが同じチームかよくわからなかった。

歓迎会が開かれたが、リーダー(けっこうなジジイ、低スキル)と俺と、先行して入ってたうちの会社の女の子の3人しか参加しなかった。

女の子が何人かいたが、仕事は、リーダーの思いつきで変化するコーディング規則に従って、すでに完成しているソースを書き直す…というものだった。
すでに何回めかの書き直しをしていた。


俺はリーダーと喧嘩して、3日でクビになったので、その後どうなったのか知らない。

760 :仕様書無しさん:2015/08/02(日) 13:01:29.77
何かを導入するのが目的になっていてその先を考えていないような人の
スルーするってのはあるなあ。

761 :仕様書無しさん:2015/08/02(日) 21:09:05.49
>>758
> コミットを意味のある単位にしたいけど
> 実際はバックアップなんだよな

まあ、何も考えないで保存すると
そうなるよなw
もちろん自動保存も含まれる。

762 :仕様書無しさん:2015/08/02(日) 21:11:49.59
>>760
> 何かを導入するのが目的になっていてその先を考えていないような人の

あぁ、導入するのはいいがやり方を変えないようなやつだなw

例えば最新版のJavaを使いますっていうくせに
最新版の機能は使ってはいけませんとかいう
意味不明なこといいだす。


目的は、開発効率を上げること。
言語の新機能は開発効率を上げるために作られた。
目的を達成するために、新機能はどんどん使うべき。

本当の目的はなに?って話。

ま、目的に「今より良くする」って考えが一切ない
所はもっと最悪だろうけどね。

763 :仕様書無しさん:2015/08/02(日) 21:17:55.29
>>761
開発アイテム単位でコミットしないとトラッキングとかマージとか色々面倒なのにメンドイからってまとめてやる奴ばっかり

764 :仕様書無しさん:2015/08/02(日) 21:42:52.65
>>762
> 本当の目的はなに?って話。
何だろね〜これって難しい問題だよね。
少なくとも「今より良くする」と「最新版の機能を使う」には全く関連がないよね。
わかる〜?

765 :仕様書無しさん:2015/08/02(日) 21:59:46.93
>>763
> 開発アイテム単位でコミットしないとトラッキングとかマージとか色々面倒なのにメンドイからってまとめてやる奴ばっかり

なんで君よりもすごい人たちが、全員そういうことやってると思う?
慣れればそれが快適だからなんだよ。

> 少なくとも「今より良くする」と「最新版の機能を使う」には全く関連がないよね。

あるよ。

最新版の機能は、今より良くするために作られているからね。
使い方を覚えることで、今よりももっと良くなる。

766 :仕様書無しさん:2015/08/02(日) 22:15:34.65
1バイトでも変えたらテストしろよ

767 :仕様書無しさん:2015/08/02(日) 22:16:10.85
>>765
君は頭が悪いね
最新版の機能で良くなっているのはそのソフトウェアそのものであり
君自身は相も変わらず、低機能でちっとも良くなっていないのだよ
もちろん君が仕事に対して出す結果もね

768 :仕様書無しさん:2015/08/02(日) 22:16:11.07
>>765
>最新版の機能は、今より良くするために作られているからね。

アホだな。 例えば関数型言語なんてそれこそ大昔から存在しているが
評価が高くなってきたのは最近だ。なんでかって言えば昔は十分
リソースもなく、並列処理用のマルチプロセッサなんてのが一般的じゃ
なかったからだ。ソフトウェアなんてのは人間の想像力を超えることが
出来ないもので、知らないだけで車輪の再発明的なものは少なくない。
それこそ数十年前の論文レベルのものなんて正確に知っている人
なんて稀なんだから、新しいってだけでありがたがってる奴はただの
バカだよ。

769 :仕様書無しさん:2015/08/02(日) 22:19:27.85
>>767
> 最新版の機能で良くなっているのはそのソフトウェアそのものであり

あのー、今はプログラム言語の話をしてるんですけど?
最新版ので良くなった機能は、
よりプログラミングをしやすくるために
そうなったんだよ。

770 :仕様書無しさん:2015/08/02(日) 22:21:13.07
>>768
> アホだな。 例えば関数型言語なんてそれこそ大昔から存在しているが
> 評価が高くなってきたのは最近だ。なんでかって言えば昔は十分

だからいろんな言語で、関数型言語由来の機能が
追加されて言ってるんですよ。

もしかして、関数型言語は、もう完成されていて、
「最新版の機能」と呼べるものは関数型言語には
存在しないと主張したいのですかね?

771 :仕様書無しさん:2015/08/02(日) 22:26:02.56
>>769
プログラム言語はソフトウェアなんですけど〜?

それはさておき仮にだ
君の言うプログラミングしやすくなったその機能を使って
君がプログラミングをしたとする

果たしてこの仮定において
一体なにが今より良くなっていると言うのだね?

772 :仕様書無しさん:2015/08/02(日) 22:26:29.70
概念自体は古いものでも、それを簡潔に表現することができるか?
っていうと別の話で、いわゆる糖衣構文の話なんだけど、
この糖衣構文ができることで、同じ概念であっても
今までよりもわかりやすく簡潔に表現できるっていうのはよくある話。

それが新機能なんだが、糖衣構文を新機能だと認めない人が
一定数いる。困ったことだ。

773 :仕様書無しさん:2015/08/02(日) 22:28:43.25
>>771
> 一体なにが今より良くなっていると言うのだね?

開発工数が減る。バグ数も減る。

これはどのブロジェクトでも必ずと
言っていいほど重要な要件になってる。

あまりにも当たり前すぎで、わざわざ書いていないから
要件に入ってないと思ってる人がいるが、
客に聞いてみればわかる。開発工数へ少ないほうがいいですか?
バグは少ないほうがいいですか?って。

774 :仕様書無しさん:2015/08/02(日) 22:31:05.83
>>765
うーんお前バカだな
どこからどこまでどのアイテムかわかんない状態なんて品質管理できねーだろが

775 :仕様書無しさん:2015/08/02(日) 22:32:20.39
>>774
このネジは、弊社で作ってないから
このネジを使った製品の
品質管理は出来ない!

って話ですか?

別にネジじゃなくても
なんにでも置き換えて構いませんが。

776 :仕様書無しさん:2015/08/02(日) 22:36:40.67
>>773
あれあれ?
元々、本当の目的とは?という話だったと思うのだが
それとも何かね?君にとって本当の目的とは
君一人の開発工数が減り
君一人のバグが減る
事だとでも言うつもりかね?

それじゃ何一つ良くなってないのだよ

そもそも君一人をとっても
本当にバグが減っているのかも甚だ疑問だしね

777 :仕様書無しさん:2015/08/02(日) 22:36:40.76
>>775
バカ過ぎて話す気失せるわ

778 :仕様書無しさん:2015/08/02(日) 22:48:42.89
>>776
君のようなついてこれない人を
切り捨てるのも、開発工数を上げる
方法の一つだよw

必要なのは優秀な人間。

779 :仕様書無しさん:2015/08/02(日) 23:31:32.92
たしかにまともな技術力ないやつほど
新しい機能にぐずぐず文句つける
バカのせいで開発効率落ちることは少なからずある

780 :仕様書無しさん:2015/08/03(月) 00:32:43.66
>>779
逆だよ。知識が無い人、出来ない人ほど新しいものに飛びつく。
なんでかといえば、今あるものをきちんと出来ていないから。
知識がない、出来ないから新しいもので出来るようになるかもと
飛びついて、飛びついた先でも中途半端に終わる人は多い。

781 :仕様書無しさん:2015/08/03(月) 00:37:03.67
>>766
コンパイラを信じろww

782 :仕様書無しさん:2015/08/03(月) 00:52:34.17
だいたい新しい技術なんて、小さく初めて実績なりなんなりを
作ってもっていったらたいてい通せるだろ。 それでも頑なに
取り入れようとしないような所なら、そんなところにいても何の
益にもなんないんだから、足抜けすればいいだけだろうし。

783 :仕様書無しさん:2015/08/03(月) 00:56:02.83
>>780
うん、そういう場合もあるし性格に難があって、上がしょうがなく意図的に誘導してるのに勘違いしている人も結構みかける。

784 :仕様書無しさん:2015/08/03(月) 01:09:37.59
?????「コミットは結果にするものだ」

785 :仕様書無しさん:2015/08/03(月) 05:47:02.40
いい加減こっちでやれよどうせ似たりよったりな痴呆症的煽り合いしかしないんだから
Git 12(c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1427085313/

786 :仕様書無しさん:2015/08/03(月) 06:50:50.09
このスレやっぱり面白い

787 :仕様書無しさん:2015/08/03(月) 07:32:08.83
>>781
コンパイラなんて信じられるかよ。
信じられるのは出てきたバイナリだけだ。
だからちゃんと逆汗して塗り潰し確認も必要だぞ。

788 :仕様書無しさん:2015/08/03(月) 20:25:06.04
>>780
> 逆だよ。知識が無い人、出来ない人ほど新しいものに飛びつく。

そんな統計無いよw

新しいものに飛びつくかどうかは、
技術力とは全くの無関係。


ただし成長するためには、新しいものに飛びつかないとダメ。

789 :仕様書無しさん:2015/08/03(月) 20:26:56.88
出来ない君がむっときちゃったんだよ許してやれ

せめて新しいものへの好奇心くらいはないとな

790 :仕様書無しさん:2015/08/03(月) 20:51:15.16
賢者は慎重な評価を行なった上で、価値の認められるものをそっと自分の道具箱に加える。

一方、バカは脊髄反射で飛びつく。

791 :仕様書無しさん:2015/08/03(月) 20:52:59.58
評価する=飛びつく

792 :仕様書無しさん:2015/08/03(月) 20:55:54.01
そういう思考だから飛びつくとしか言えないという事か

793 :仕様書無しさん:2015/08/03(月) 20:56:40.23
賢者は色んな物を使ってるからな。
色んな物に飛びつくから
何がいいか悪いかも判断できるようになっている。

794 :仕様書無しさん:2015/08/03(月) 20:57:07.18
まあ使っても見ないで、評価なんて出来ないよね(笑)

795 :仕様書無しさん:2015/08/03(月) 20:59:38.32
>>793←必死で正当化するやつw

796 :仕様書無しさん:2015/08/03(月) 21:00:31.27
>>795
そういうレスはいらんからw

実際、使ってみないと評価できないのは当たり前の話で
優れた人ほど、色んな物を使ってる。

797 :仕様書無しさん:2015/08/03(月) 21:02:22.37
>>796
で、お前は飛びつくだけのバカというわけか
よく分かってるじゃないか

798 :仕様書無しさん:2015/08/03(月) 21:06:41.96
なんでこいつこんな喧嘩腰なんだろ?
冷静に話しできないのかな?

799 :仕様書無しさん:2015/08/03(月) 21:16:19.16
>>798
自分ではいたって冷静なつもりだが、傍から見ると変なテンションではしゃいでる人
それがバカクオリティー

そう、君のようにね。

800 :仕様書無しさん:2015/08/03(月) 21:24:54.34
なんかトラウマがあんだよ。きっと。

801 :仕様書無しさん:2015/08/04(火) 08:24:40.20
冷静になれない病気なんじゃないかな
最近そういうの多いみたいだし

802 :仕様書無しさん:2015/08/04(火) 08:35:12.62
これ貼っときますね

28: 名刺は切らしておりまして [sage] 2015/06/12(金) 18:50:00.68 ID:8qBA3WXa

革新的なことをしたがる人ほど、
革新的でないことに無知である
故に多くが失敗する

803 :仕様書無しさん:2015/08/04(火) 09:05:03.50
>>802
偉い人が言ったならともなく、
2ちゃんねるの書き込みをコピペするなよw

804 :仕様書無しさん:2015/08/04(火) 17:20:46.39
>>787
お断りしますん

805 :仕様書無しさん:2015/08/04(火) 20:04:04.56
納品は紙リストとする。

ええと音声データとかどうすんですか?
そだね。ダンプリストでも出しとけば?
はーい。

806 :仕様書無しさん:2015/08/06(木) 21:43:21.33
>>805
音声はレコード盤で納品するのが当たり前だぞ

807 :仕様書無しさん:2015/08/06(木) 22:21:00.28
>>806
大手は生音が基本だぞ
レコードとかどこの零細企業だよw

808 :仕様書無しさん:2015/08/07(金) 00:10:36.22
お前らの会話がよくわからん。

納品が紙リストって? バイナリ渡す時はどうすんの?
レコードは唯一生音に最も近い物を出力できる現物だよな。
生音は有線じゃないと生音とは言わないよな?
>>805の言う紙リストって、実行バイナリの中身をプリンタで印刷したものってことなの?

普通に会話がよく分からん

809 :仕様書無しさん:2015/08/07(金) 00:54:17.06
>>808
音声データのバイナリダンプだろ

810 :仕様書無しさん:2015/08/07(金) 01:10:10.99
いや別に俺はギャグで聞いてるんじゃなくてだな、
まず紙リストってなに?

811 :仕様書無しさん:2015/08/07(金) 01:34:34.08
>>807
ソースコードの語り部でも居るのかw

812 :仕様書無しさん:2015/08/07(金) 01:38:01.71
>>810
昔は(今も馬鹿な所はやってるらしいが)
ディスクなどで提出っていうのはありえなかったんだよ。

仕事=紙の量みたいな考えがあってね。
(今も馬鹿な所はやってるらしいが)

量が多いほどいいとか、そういう
馬鹿なところがあるのよ。

量が多い=生産性が高いみたいに
正反対のことを考えてる。

だから印刷。

813 :仕様書無しさん:2015/08/07(金) 01:46:15.35
ソースを印刷するの?
いや俺、10年以上なるけどそんなのみたことないが

貰ったほうは、それ見て打ち込んで自分でコンパイルすんの??

814 :仕様書無しさん:2015/08/07(金) 01:49:21.62
>>813
打ち込まない。
単に目に見える形が欲しいだけ。

コンビニでも買えるこんなCD一枚で数百万円!?

よりもトラック一台分で数百万円の方が
価値がありそうだろう?w

本気でそう思っている馬鹿いるんだよ。

815 :仕様書無しさん:2015/08/07(金) 02:30:36.44
あー 理解して来たぞ
貰ったほうは苦情言わないのか
俺なら2秒でいらんって言いそうだが
まぁ解説どうもありがとう

816 :仕様書無しさん:2015/08/07(金) 02:33:20.58
病院のレセプトは紙で提出
それをスキャナで読み込み

そりゃ医療費も高いですわ

817 :仕様書無しさん:2015/08/07(金) 04:10:51.24
昔は雑誌にソノシートで
BASICがついてきたもんじゃよ

818 :仕様書無しさん:2015/08/07(金) 04:14:29.00
ダンプリスト段ボール箱4つぐらい
規定だか法律が有ったみたいよ

勿論、フロッピーは別に渡す。

819 :仕様書無しさん:2015/08/07(金) 05:27:44.85
法律があったというより、電子文書に関する法規定が定まってなくて無効とされていたんでは?
客によっては、クローズドシステムでDisplay端末、プリンタは全て業務としてフルに使用って所もあるからなあ
システム納品後に不具合がでたら、その場で確認とか修正作業を行ったりするわけで、端末が使えないから確認作業も出来ないとか言い訳出来ない場合もあるんじゃね

820 :仕様書無しさん:2015/08/07(金) 06:38:33.73
>>807
レコードを本気にするとは思わなかった
もちろん冗談ダヨ
スマソ

821 :仕様書無しさん:2015/08/07(金) 06:45:20.55
ドキュメント類を、キングジムにバインダー綴じするのが王道だよな
厚さ15cmくらいの極太バインダが並ぶ姿は圧巻だ
営業車を使って、ダンボールで納品とかまじで笑える
最後にそれを手伝ったのが12年前くらいだけどw

822 :仕様書無しさん:2015/08/07(金) 08:58:42.41
2003年でそれか

823 :仕様書無しさん:2015/08/07(金) 09:17:29.04
今でも1箇所紙納品だな。
仕様書ソースは印刷。前回納品は約16000枚だった。
それを全部チェックして印刷のかすれが1枚あった程度の理由で
検収不合格にするクズ。

824 :仕様書無しさん:2015/08/07(金) 09:39:12.27
16000枚? なにそれ気持ちわりーw

825 :仕様書無しさん:2015/08/07(金) 10:00:22.72
>>823
前回ってことは、現在進行形でそういう企業がまだあるってこと!?
ちょっとは地球のこと考えて欲しいわ…。

826 :仕様書無しさん:2015/08/07(金) 11:25:52.89
元請けのオレオレフレームワーク上での開発ルール

・画面とビジネスロジックのクラス数は1:1

・画面と、画面〜BL間でやりとりするDTOの数は1:2(リクエストとレスポンス用)

・BL内のメソッド分けは画面のイベント単位

・BL呼び出しは、1イベントに1回だけ

・BL呼び出し後の処理は、処理の種類ごとに決められた同じコールバック関数内に書かなければいけない
※更新ボタンが3つあったとすると、BL呼び足し前の処理は各イベントハンドラに書けるが、BL呼び出し後の処理は同じメソッド内で分岐させなければならない

827 :仕様書無しさん:2015/08/07(金) 13:24:21.27
>>826
そんなに具体的に書いて大丈夫か?
特定されちゃうぞ

828 :仕様書無しさん:2015/08/07(金) 13:25:27.27
>>823
16000枚は凄いなw
1キングジム=500枚としても、
30キングジムを超えるな

829 :仕様書無しさん:2015/08/07(金) 16:42:49.31
>>828
キングジムっていう単位があるのかと思ってしまった…

830 :仕様書無しさん:2015/08/07(金) 20:14:23.09
>>820
むしろお前は生音を本気にしたのか?
冗談を言うにはピュアすぎる性格だなw

831 :仕様書無しさん:2015/08/07(金) 20:25:53.74
生首だって。こわい。

832 :仕様書無しさん:2015/08/07(金) 20:30:08.89
前いた会社で
一人で残業してはならない
って社則が。
それは一人で残業した奴がな

833 :仕様書無しさん:2015/08/07(金) 22:18:55.76
>>832
続きはよ

834 :仕様書無しさん:2015/08/07(金) 23:12:07.02
バインダーに閉じた仕様書並べたら2mくらいになったことはあるな

835 :仕様書無しさん:2015/08/07(金) 23:30:05.79
残業して一人でバインダー並べてたのかよwww

836 :仕様書無しさん:2015/08/07(金) 23:35:44.81
>>834
だれもよまねーだろ

837 :仕様書無しさん:2015/08/07(金) 23:43:21.00
現地試験で問題起きた時に客が仕様と付き合わせるために置いてるから部分的に読むよ

838 :仕様書無しさん:2015/08/07(金) 23:47:30.75
IBMのSDLCの仕様書なんてトラック一台分あったとかいう話を何かの本で読んだ事があるような
裁判の証拠として提出させたら、余りの量に裁判官も相手側も腰を抜かしたとかなんとか…

839 :仕様書無しさん:2015/08/08(土) 21:10:51.34
え、現地でPC使えないってこと?

840 :仕様書無しさん:2015/08/08(土) 22:36:24.17
>>839
証拠なんだから印刷物じゃなきゃダメなんだろ?

841 :仕様書無しさん:2015/08/10(月) 10:34:27.91
データだとなにかのミスで消えるからとかなんとか
紙媒体が人的ミスで廃棄されたり天災でなくなっちゃったり
っていう可能性は一切考慮されない模様

842 :仕様書無しさん:2015/08/10(月) 14:55:40.37
大丈夫だ。
正副2部納入だから

843 :仕様書無しさん:2015/08/11(火) 22:02:59.93
>>841
冗長性確保だろ。

844 :仕様書無しさん:2015/08/17(月) 14:06:47.03
SCMに何を使うか以前でフォルダの中身が
a.c
a.20150817.c
a_最新.c

845 :仕様書無しさん:2015/08/17(月) 14:34:18.95
a_最新_20130817.c
a_最新2.c
a_最新_まだ使ってない.c

846 :仕様書無しさん:2015/08/17(月) 15:54:40.21
a,c.bak
a.c.bak2
a.c.bak.c
a.bak.c

847 :仕様書無しさん:2015/08/17(月) 16:42:15.74
構成管理とか知らないんだろうな

848 :仕様書無しさん:2015/08/18(火) 09:00:28.85
"フォルダ"に入れてる時点で終わってる気がする

849 :仕様書無しさん:2015/08/18(火) 13:01:20.08
通はディレクトリだよね

850 :仕様書無しさん:2015/08/18(火) 22:02:51.98
そういう意味じゃなくて
クラウドとかサーバとか

851 :仕様書無しさん:2015/08/18(火) 23:10:49.99
おそとにゴミを撒き散らすのか

852 :仕様書無しさん:2015/08/19(水) 08:48:03.58
どちらにしろルートディレクトリにばら撒くのは感心しない

853 :仕様書無しさん:2015/08/25(火) 01:17:30.42
高専→大学院で9年間情報工学やってきてSIerに入社したが、
新入社員でVB.NET使う現場に配属されて、

1. 変数宣言は関数の一番最初にやること
2.全関数Try-catch-finally すること(もちろんex as Exceptionしてログ吐いてThrow exしないといけない)
3.DBアクセス等の社内モジュールは返り値boolean(なぜかこいつはthrowしてくれず原因に関係なく失敗したらfalse
4.システムハンガリアン
5.LinQ?なにそれ、読めないから使うな
6.リファクタリングって何?伝わらないかもしれない用語を日報に書くな
7.テストツール?何それ

転職したい

854 :仕様書無しさん:2015/08/25(火) 01:26:50.28
忘れてた、これも追加で

8.修正開始前および終了後にはコメントアウトで日時をつけ、前のコードをすべて残すこと
9.結合テストを行うときは、バージョン管理ツールに最新のファイルがチェックインされていることを全員に口頭で確認してからコンパイルすること

ちなみに最近VSSからTFSに変更されました

855 :仕様書無しさん:2015/08/25(火) 14:11:08.00
>>853
日本の大手SIerはどこも似たり寄ったりだね。

その経歴なら海外行くとか、Web系のスタートアップ企業に入るとかした方が、やりたいことできるし、後々の伸び代も高いと思うよ。

自分は、いっときWebの会社にいて、最近SIerの下請けに戻ったんだけど、外の世界との差が酷すぎて、ショック受けた。

この業界ももう長くはないよ。
客も馬鹿ばかりじゃないから、100分の1のコストで100倍高品質なもの作る世界があるってことに気づけば、いずれSIerから去っていく。
腐っても資本主義の世界だからね。

856 :仕様書無しさん:2015/08/31(月) 19:57:15.55
>>853-854
そんな話を聞いただけでマジ 吐 き そ う!!!

857 :仕様書無しさん:2015/08/31(月) 20:02:30.35
>>853
当然のことながら、リリースビルドは設定ファイルなどを人間が手で書き換えて、IDEのビルドボタンをぽちっとな、ファイルを手動でコピー、指差し確認でデプロイする!
だよね?

858 :仕様書無しさん:2015/08/31(月) 21:41:17.84
>>854
9はなんとなくわかる気がする

テスト用のバイナリ作ったら
数分後にまだ間に合う?とか
忘れてたこれもお願いとか
言って来る馬鹿が居てイラっとする

859 :仕様書無しさん:2015/08/31(月) 21:50:44.32
>>858
そういう時は、機能追加は一週間前に締めきりましたって
いえばいい。

860 :仕様書無しさん:2015/09/01(火) 10:02:25.71
>>857
え、いかんの?

861 :仕様書無しさん:2015/09/01(火) 10:14:11.10
>>860
手で書き換えって時点でなんだかなぁだよ
普通書き換えなくてもターゲット指定で両方出来るだろ

862 :仕様書無しさん:2015/09/03(木) 21:15:16.44
ハゲ禁止
という社則があったら嬉しい。

863 :仕様書無しさん:2015/09/03(木) 21:18:07.40
ツールを製品と同じ品質にしろ

もう誰もツール作らねーだろこれ
作っても自分が使うだけになる

864 :仕様書無しさん:2015/09/03(木) 23:40:49.34


865 :仕様書無しさん:2015/09/04(金) 10:25:40.14
>>862
うちの会社はソフトバンク系は取引禁止。ある意味ハゲ禁止。

866 :仕様書無しさん:2015/09/05(土) 04:07:55.99
>>861
コミットされたらビルドサーバが勝手にビルドしてくれる

人間がやるのは>>853みたいな所

867 :仕様書無しさん:2015/09/05(土) 08:38:26.95
>>866
お前はもともとなんで茶化しが入ってるのかわかって無いだろ
すげーずれたこと言ってるから間抜けに見えるわ

868 :仕様書無しさん:2015/09/05(土) 12:43:09.36
完全AI化までの移行期間 (NEW)

・AIが雇用を減らす中で解雇できない国家は没落、解雇できる国家は変化に対応
・AIを持つ企業が医療・情報通信・流通・サービス・製造業で大きく成長し、既存の大企業を価格競争で脅かす
・解雇ができる国家に所属する企業はAI化による価格競争で生き残れる
・解雇ができない国家に所属する企業はAI化、自動化によって大量の無産労働者を抱えて価格競争に負けて破産する

過去
・日本の繊維業界が中国の低賃金労働に負けて壊滅
・産業革命により欧米以外が貧困化(イギリスによるインドや植民地への繊維品輸出はその一例)

現在
・本屋・出版業界がAmazonに飲み込まれる 、レコード業界がAppleに飲み込まれる

雇用10%消失 (10年以内)
・タクシー企業が次々と破綻 、ヤマト・佐川・日通等が破綻(自動運転、配送の無人化・自動化による)
・NEC、富士通、SIerが破綻(開発の自動化・AI化による)
・製造業や小売り労働者がAIにおき変わる(ロボットやAIによる無人化による)
・解雇できないため正社員での新規雇用は停止され、全て非正規雇用となる
・倒産した企業のメインバンク・都市銀行が不良債権で取り付け騒ぎをおこす。さらに多くの業界で企業年金の支払いが止まる。

雇用30%消失 (20年以内)
・医師・看護師・介護士・薬剤師が廃業 (AIや介護ロボットによる)
・大量の従業員を抱えるトヨタや日産、ホンダが破産 (工場の無人化による)
・格差に堪え兼ねた最下層の貧困層(を親族に持つ現役・退役自衛官)によるテロやクーデーターが発生

雇用50%消失 (30年以内)
・想像するのも恐ろしいが日本の大企業の大半が破産して貧困国に転落。生活保護等の財源もなく餓死者や凶悪犯罪やクーデーターが頻繁に発生。

雇用90%消失(40年以内)
・豊かさを維持した国家(解雇ができる国家)は、ベーシックインカムなどで繁栄、貧困国は豊かな国から借金をして隷属し、国家体制が破綻する。(Paul MasonのPostCapitalism、タイラー・コーエンの大格差など)

869 :仕様書無しさん:2015/09/07(月) 15:49:05.26
また変なのが来た

870 :仕様書無しさん:2015/09/07(月) 15:55:28.79
いまだコピペ荒らしが見えている人がいることのほうが驚き

871 :仕様書無しさん:2015/09/07(月) 19:09:56.15
長文アボーンみたいなビューワある?

872 :仕様書無しさん:2015/09/08(火) 05:41:46.86
ビューアの操作覚えるの面倒くさいから、普通のブラウザで見たり書いたりしてる

873 :仕様書無しさん:2015/09/08(火) 05:42:33.67
間違えた、ビューアじゃなくてワだ

874 :仕様書無しさん:2015/09/09(水) 23:43:58.17
継承禁止
バグ箇所に予めコメントが書いて無ければペナルティ

なおこのルールはルール作成者には適用されない模様

875 :仕様書無しさん:2015/09/10(木) 01:30:13.74
>>874
継承は使わないのが主流になってきてるけどな。

876 :仕様書無しさん:2015/09/10(木) 21:15:07.21
純粋仮想関数の継承なら必須だろ

877 :仕様書無しさん:2015/09/10(木) 22:35:57.02
委譲とコンポジション。

878 :仕様書無しさん:2015/09/11(金) 00:33:10.02
継承は多様性ランチャーする気で使ってるんならまだいいんだが
「コードの継ぎ足し」で使うやつが多くてヘキヘキする。
特にJava専業の人はこの傾向が強い。

「ねえそれpublicで書いてもよくね?」ってくらいすべてのフィールドに対する
setter/getter書いてる上、継承しまくってるとかよくある。POJOだから、知らんがな。

879 :仕様書無しさん:2015/09/11(金) 01:53:58.44
>>878
javaのIDEだと大抵はsetter/getterを生成してくれる機能があるから
手書きをする必要は無い。未だにIDEどころかコーディング支援も
無いようなメモ帳レベルのテキストエディタしか使っていない原始人
みたいな人には理解できないだろうけど。

880 :仕様書無しさん:2015/09/11(金) 22:10:47.34
>>875
一番表面のアプリな層の話ではそうだね

881 :仕様書無しさん:2015/09/13(日) 11:49:51.84
>>879
手間の話じゃなくて、setter/getter作る意味は何?

882 :仕様書無しさん:2015/09/13(日) 12:08:02.58
>>881
javaで書く手間以外でフィールドをpublicにする意味は?

883 :仕様書無しさん:2015/09/13(日) 14:26:50.00
話が噛み合っていないな。
なんでもかんでもgettter, setter作ったらカプセル化できないじゃんって話でしょうに。
ideがどうとか言ってるやつはバカなのか?まあ、Javaプログラマーのレベルを象徴する
書き込みだな。

884 :仕様書無しさん:2015/09/13(日) 14:31:05.38
>>883
話が噛み合ってないのはお前。
お前のレベルの低さを象徴する書き込みだねw

885 :仕様書無しさん:2015/09/13(日) 15:49:06.84
>>882
setter/getterを作る意味が無いから。
てか質問に質問で返すな馬鹿。

886 :仕様書無しさん:2015/09/13(日) 15:54:21.73
バカ「アクセッサを作ったから疎結合が達成された!」

887 :仕様書無しさん:2015/09/13(日) 15:55:09.53
>>885
なんで意味が無いと言い切れるの?未来予知が出来るエスパーなの?

オブジェクト指向でのクラスのフィールドは局所的なグローバル変数と
なんら変わらないもので、そういうカプセル化の意味でもアクセス制限を
かけるためにアクセッサーを介してアクセスするような基本的な考え方が
大前提として存在する。

あとは継承先で曲げたり、DIだのAOPでフックしてとかの利用方法も
あるが、パブリックフィールドだとそういうことも出来ない。将来何か
やろうと思って用意しても使わないことの方が多いが、適当に作って
後で後悔したことなんていくらでもあるし、未来予知が出来るエスパー
でもない限りは意味が無いなんて言い切れるものではない。

そういう大前提が分かっていないのが他人を馬鹿呼ばわり出来るくらいの
頭の弱い子なんだなと。

888 :仕様書無しさん:2015/09/13(日) 15:56:18.52
>>887
公開しないならprivateで良いだろ。

889 :仕様書無しさん:2015/09/13(日) 16:01:41.12
そういう意味でも他言語でもフィールドをパブリックにしろみたいな言語は
クソ言語なわけで。rubyなんかも直接じゃなくてattrを使ってアクセスを
制限するようになっている。ホントにバカは何も知らんよな。

890 :仕様書無しさん:2015/09/13(日) 16:03:37.68
>>888
元が>>878でアクセッサー作らずにパブリックにしろだからな。

891 :仕様書無しさん:2015/09/13(日) 16:05:00.05
リフレクションで拾うのが面倒なんだよ

892 :仕様書無しさん:2015/09/13(日) 16:08:24.45
>>887
つ「早すぎる最適化」

893 :仕様書無しさん:2015/09/13(日) 16:12:08.58
公開しているものについて意味が変わったり副作用が変わる修正をするなよ。
設計のまずさをアクセッサで凌ごうって事だろ?
根本的に間違ってるんじゃないの。

894 :仕様書無しさん:2015/09/13(日) 16:43:16.31
>>890
なんでもかんでもgetter,setterつけるならpublicで公開するのと同じだよねってことだろ

895 :仕様書無しさん:2015/09/13(日) 16:47:59.22
あとで使うかもしれないからgetter,setterを作っておくとか基地外沙汰だな。
それこそエスパー能力使ってるだろ。必要になってから作れよ。
基本はprivateだ。

896 :仕様書無しさん:2015/09/13(日) 16:56:48.22
>>889
getter,setterをpublicにしてたらフィールドがpublicなのと変わらんよ。
オブジェクト指向の基本は問い合わせるな命令しろだ。アクセッサなんていう
昭和時代の設計ミスを現代のプログラミングに持ち込むな。

897 :仕様書無しさん:2015/09/13(日) 17:07:44.22
あとrubyはゆきひろのオナニーだから。
railsで一時期もてはやされたが珍しがってただけでもはや下火。
レガシーと言ってもいいだろうね。今はscalaなどの関数型言語が評価されている。

898 :仕様書無しさん:2015/09/13(日) 17:29:51.76
>>894
> 「ねえそれpublicで書いてもよくね?」ってくらいすべてのフィールドに対する
> setter/getter書いてる上、継承しまくってるとかよくある。POJOだから、知らんがな。

これを

> なんでもかんでもgetter,setterつけるならpublicで公開するのと同じだよねってことだろ

こう読み取れるのは素敵だと思う

>>896
> getter,setterをpublicにしてたらフィールドがpublicなのと変わらんよ。

変わらんなら例えばrubyでattrを用意してでも直接アクセスさせないように
しているわけがないだろうに。

899 :仕様書無しさん:2015/09/13(日) 17:37:29.93
>>898
読み取れないお前がバカなんだろ。

アクセッサは昭和時代の設計ミスだ。
それを正しいと思い込んでるとしたらゆきひろの罪は重いな。
頭スッカラカンのプログラマを教導し洗脳した責任をとるべきだ。
ブラック企業の経営者みたいなもんだな。

900 :仕様書無しさん:2015/09/13(日) 17:40:08.91
偉い人が言ってただの言語として用意してるからだの
何かの本を鵜呑みにして消化できてないから、そういう説明が出てくるんだ。

901 :仕様書無しさん:2015/09/13(日) 17:40:36.09
>>899
バカって言う奴がバカなんだぞというような典型的なやつだな。

902 :仕様書無しさん:2015/09/13(日) 17:45:22.31
>>900
グローバル変数で痛い目をみたからカプセル化してアクセス制限をしましょうと
いうのがそもそもの狙い。全てにたいしてアクセッサを用意するのは残念な
書き方だが、それをフィールドとして生で用意するのと変わらないというのは
残念を通り越して危険な書き方になる。そもそもカプセル化というものを理解
していない可能性がある。

903 :仕様書無しさん:2015/09/13(日) 17:51:59.73
>>902
だから、そもそも渡した値に処理を施すつもりなら、メソッドにしようよって事だろ?
そこらへんが曖昧だからアクセッサなんて中途半端な事になるの。
明確な意図を持ってアクセッサを使うのは良いけど
なんでもかんでも使うのは「僕は何も判ってません」って宣言してるようなもんなんだ。

904 :仕様書無しさん:2015/09/13(日) 17:56:06.62
まあ言語としてプロパティ用意してくれるなら、そっち使うけどな

905 :仕様書無しさん:2015/09/13(日) 18:21:55.93
>>902
>>886

906 :仕様書無しさん:2015/09/13(日) 18:55:38.07
>>903
javaにおけるメソッドとアクセッサの違いって何? アクセッサていうのは
単なるメソッドの利用方法の一つだと思うのだが。あなたの中ではjavaの
言語仕様としてアクセッサというものが存在しているように見受けられるの
ですが?大昔にJavaBeansがあって、それに引きづられている部分は
ありますが、言語仕様にアクセッサなんてものは無かったと思います。

どう使おうがそこにいる奴ら次第でしかないけど、フィールドをpublicに
するのだけは絶対に認めたくないってだけです。

907 :仕様書無しさん:2015/09/13(日) 19:06:04.06
>>906
>javaにおけるメソッドとアクセッサの違いって何?
同じはずだけど?
情報を公開する以上の意味のある事をしたいなら、ちゃんとしたメソッドとして命名すれば良い。
君はpublicのフィールドは嫌だからというが、なぜ嫌なの?
指定した形式の引数以外はエラーにしたいとか、目的があるなら判るけどさ。
君はそういうの無いでしょ。

908 :仕様書無しさん:2015/09/13(日) 19:09:54.88
publicフィールドにgetter/setterを用意しましょうなんてのは
グローバル変数使いまくるような初心者向けの馬鹿除けだって判るだろ。
初心者じゃないなら、ちょっとは自分で考えろ。

909 :仕様書無しさん:2015/09/13(日) 19:22:54.07
>>907
カプセル化の原則に反するからpublicにするのは問題外なのですが?

910 :仕様書無しさん:2015/09/13(日) 19:23:55.87
>>909
じゃあアクセッサを用意すればカプセル化を達成できると?
そこが思考停止だって言ってるのさ。

911 :仕様書無しさん:2015/09/13(日) 19:25:51.95
>>909
たとえばだ、こういうクラスがあったとするなら
カプセル化もクソもないだろ。

public class Example {
 private int value;
 public int getValue() {
  return value;
 }
 public void setValue(int value) {
  this.value = value;
 }
}

それをこう書き換えても問題ないだろ。

public class Example {
 public int value;
}

912 :仕様書無しさん:2015/09/13(日) 19:31:12.09
好きにしたらいい

913 :仕様書無しさん:2015/09/13(日) 19:32:14.54
>>911
お前は氏ね。プログラムを2度と書こうと思うな。

914 :仕様書無しさん:2015/09/13(日) 19:32:40.67
>>911
どうせこんな風に値が直通で入るような意味のないアクセッサ書いてるんだろ。
何が内部情報の隠蔽だよ。

915 :仕様書無しさん:2015/09/13(日) 19:34:27.71
>>911
継承の時にオーバーライドできない。
拡張性がない。
getだけ、setだけにできない。

916 :仕様書無しさん:2015/09/13(日) 19:42:38.31
>>913
俺は死なないしプログラムを書く。お前は死ね。地獄に落ちて閻魔大王にアナル掘られろ。

>>915
単純な値の取得に拡張もクソもあるかハゲ。
カプセル化するならフィールドをprivateにしてアクセッサを定義しないのが
唯一の大正義だ。

917 :仕様書無しさん:2015/09/13(日) 19:46:49.53
単純な値の取得以外にもできるから
拡張性がある。

918 :仕様書無しさん:2015/09/13(日) 19:51:04.31
>>917
https://ja.wikipedia.org/wiki/YAGNI

919 :仕様書無しさん:2015/09/13(日) 19:52:14.72
ValueObjectでええやん

public class Example {
 public final int value;
 public Example(int value) {
  this.value = value;
 }
}

920 :仕様書無しさん:2015/09/13(日) 19:55:08.76
カプセル化を破壊するアクセッサ作って
拡張性があるとか頭に蛆わいとるわ

921 :仕様書無しさん:2015/09/13(日) 21:39:22.36
プロパティの内容によるだろ。
クラスの設定値っぽい値をgetsetで表現するのは問題無い。
但し如何なるタイミングでsetで値が書き換えられても大丈夫にする必要があるが。

922 :仕様書無しさん:2015/09/13(日) 22:59:32.11
VB6時代に作られて.NETに上げたであろうバッチに処理を追加する必要があったが
共通メソッドが糞過ぎて使う気になれなかった
メソッドを呼ぶごとにリソース(DBコネクション)を確保して破棄をすると繰り返してやがった
そのせいで処理時間がかかっているのにもう馬鹿かと
しかもエンティティはあってもサービス層が分離できていなくて
いたるところにSQL文が散らばっている

追加のバッチは、既存の作りを大きく変えて作ってやったよ
仕様は一つでも作り手によって効率、保守性、見た目の美しさが変わってくるんだよな
頭の中でコードがコンパイルされて流れるようにデバッグできる
どうしてこういうコードになったのかがすべて説明できる

C言語はプログラマを育てる
ごまかしがきかねぇからな
自分で考えどうすれば速く動くか
効率よくリソースを使いきれるか

923 :仕様書無しさん:2015/09/13(日) 23:11:14.10
データセット。。

924 :仕様書無しさん:2015/09/13(日) 23:21:13.99
>>922
バッチ処理は、1レコード取得するごとにSQL発行するゴミ実装とかザラにあるからな。
IO減らすよう最初から意識して作らないとパフォーマンスが酷いことになるよね。
俺もねえゴミを量産したよね。反省はしていない。

925 :仕様書無しさん:2015/09/13(日) 23:48:02.38
昭和昭和言っていたのが、Cの構造体程度の昭和な解決方法を
出してきたのは、笑える。

926 :仕様書無しさん:2015/09/14(月) 00:04:26.03
>>915
javaってgetXとかsetXとかかかないとプロパティ定義できないんですか?
ていうか、それただのメソッドですよw?
アクセサとか大層な呼び方するほどでもないですよw

927 :仕様書無しさん:2015/09/14(月) 00:09:08.35
>>925
バカかお前。人食いバクテリアに頭の中食い荒らされたのか?
アクセッサを置き換えるとしたらパブリックフィールドでいいだろ、
そもそもアクセッサを定義すること自体レガシーな開発手法であり
懐古厨でない限りやるべきじゃないと言ってるわけ。
俺だったらprivateにしてアクセッサを定義しないね。
なぜならばカプセル化したいから。
オブジェクト指向という名前が世に出てから30年程になるが、
近年になってようやくその開発手法が成熟した感がある。
お前のようにオブジェクト指向言語を使うだけでオブジェクト指向を
分かった気になっているレガシー厨にはわからないだろうがな。

928 :仕様書無しさん:2015/09/14(月) 00:15:18.27
>>926
> アクセサとか大層な呼び方するほどでもないですよw

アクセサが大層な呼び方だと考えるほうがおかしくね?
普通に使われてる言葉だよ。

例えばRuby、Python、C#、Objective-C等でも出てくる用語

おそらく知らないから、珍しい言葉だと思って
大層な呼び方だと勘違いしてしまうんだろうね。

929 :仕様書無しさん:2015/09/14(月) 00:39:46.15
単純にお作法の話でないの?
public変数は食事の作法で言えば犬食いみたいなもんだが
犬食いでも食事という機能は満たせてるって言えば
それはそうだけどみっともないよねってレベルの話

930 :仕様書無しさん:2015/09/14(月) 00:53:09.11
例えばファサードパターンなんかで、publicフィールドしか無いオブジェクトしか
渡せないと、他のところで使いたくてもフィールドが無いオブジェクトは使えない
という、そのオブジェクト専用の使えないファサードオブジェクトになってしまう。

アクセッサで用意しておけば、このオブジェクトの場合はこのアクセッサで
こっちのフィールドに入れるとか、アクセッサでの処理を無視するとかが
出来る。こうした場合に、データと処理の分離がある程度出来る。

富豪的プログラミングでオブジェクトがアプリケーションinアプリケーションに
なってしまうような人には多分理解できないかと思うが。

後はパブリックで直接公開しているとバカが他のオブジェクトでもやって
いいと勘違いして書いたりするから、そういうのの防止の意味もある。

931 :仕様書無しさん:2015/09/14(月) 02:44:05.04
>>928
C#は機能でアクセサが提供されてますが、javaはどうみてもただのメソッドでしょう。なんちゃってアクセサと呼びましょうね

932 :仕様書無しさん:2015/09/14(月) 07:30:22.56
>>931
C#の機能はプロパティ。
アクセサであることに変わりはないでしょうに。

933 :仕様書無しさん:2015/09/14(月) 07:57:04.99
なんか伸びてると思ったら宗教戦争か…

934 :仕様書無しさん:2015/09/14(月) 09:04:05.65
setterは引数ガードのために必要だろ

935 :仕様書無しさん:2015/09/14(月) 20:29:13.17
>>926
こいつ馬鹿

936 :仕様書無しさん:2015/09/14(月) 21:38:14.90
まだやってんのか

937 :仕様書無しさん:2015/09/15(火) 06:00:08.67
ずっとやるに決まってるだろw
っていうかもうすぐ次スレか

938 :仕様書無しさん:2015/09/15(火) 17:47:06.04
settergetter1つ1つに詳細設計が必要でフローチャートも書かなきゃいけない

939 :仕様書無しさん:2015/09/15(火) 20:55:33.27
オブジェクト指向の原点であるSmallTalkにはアクセサはない。
それがすべてを物語っている。アクセサ厨は胃の中の蛙であることを知れ。

940 :仕様書無しさん:2015/09/15(火) 21:14:52.56
>>938
それも仕事のうちだからいいんじゃないの?

941 :仕様書無しさん:2015/09/15(火) 21:49:10.71
Javaは自明を省略可とする流れだから、アクセサも決まり切った所は省略可として欲しいね。
APEXみたいに、
String name {get;set;}
でスッキリ済ませられば。

942 :仕様書無しさん:2015/09/15(火) 22:23:53.07
JavaだとLombokかな?
1人だけのプロジェクトで使った事あるけど
IDEがLombokに完全対応してないと色々と辛い

943 :仕様書無しさん:2015/09/15(火) 23:00:28.07
へぇ、こういうのが有るのか。

944 :仕様書無しさん:2015/09/16(水) 00:36:39.79
書くのを省略できるのと、publicで公開するのはまた別の話だからなあ、
それが理解できないのが居座っているんだな。

945 :仕様書無しさん:2015/09/16(水) 04:34:19.26
>>939
> オブジェクト指向の原点であるSmallTalkにはアクセサはない。
そりゃ原点だからなw

それからどんどん発展していくわけで、
古いものないのは当たり前。

古代兵器が究極兵器なのは
SFの世界だけの話だよw

946 :仕様書無しさん:2015/09/16(水) 06:18:42.34
マシン語

947 :仕様書無しさん:2015/09/16(水) 06:57:52.42
究極っちゃ究極だな。

948 :仕様書無しさん:2015/09/16(水) 06:59:40.96
Smalltalk, Lisp, C
プログラム言語は最初のものこそ最強説

949 :仕様書無しさん:2015/09/16(水) 07:55:19.03
何を作るかによる
どうでもいい物ほどスクリプト最強
まともなものほどネイティブ最強

950 :仕様書無しさん:2015/09/16(水) 19:39:14.48
古なるコボル。

951 :仕様書無しさん:2015/09/16(水) 20:28:44.75
LispとCは最後まで残るな。

何の最後か知らんけど。

952 :仕様書無しさん:2015/09/16(水) 20:57:14.45
すべての言語潰える時

デデデデン!

953 :仕様書無しさん:2015/09/16(水) 22:53:37.95
変な社食

954 :仕様書無しさん:2015/09/16(水) 22:56:27.28
香典規約

955 :仕様書無しさん:2015/10/13(火) 19:47:00.01
(ΦωΦ)フフフ…
LispとCしか使えない俺は人類最強

956 :仕様書無しさん:2015/10/24(土) 09:05:22.43
転職の際は要チェック。
下記の条件が全て当てはまる会社にご注意下さい。

・IT系 in Tokyo
・転職会議で2.5点
・転職会議の「その他>2ch情報」の欄で過去の2chスレが表示される

957 :仕様書無しさん:2015/10/24(土) 10:54:43.51
プリントアウトしたコードを手作業で塗りつぶして品質チェックして納品・・・
は受取拒否されるけど、作業した証拠は残さないといけないので
大量の紙束を閉まっておくだけに別の事務所借りて物置にしてる

958 :仕様書無しさん:2015/10/24(土) 13:57:16.45
>>957
pdfにして、zipにして、cloudに挙げとけ。

959 :仕様書無しさん:2015/10/24(土) 21:31:19.73
>>957
これは酷いなw

960 :仕様書無しさん:2015/10/25(日) 06:10:21.02
管理者「ソースは全部バージョン管理システムで管理、チケットと結びつけてコミットするように。それ以外は認めません

部下「まあ、これは分かる

管理者「開発完了後、整理します。構成変えました。ソースコミットしてください。

部下「はぁ?

開発中に全部管理してて、開発完了してる
バージョン勝手に触ってなにやってんの
しかもそんなこと認めないと言ってる本人が

凄いオレオレ規則、これが半年ごとにあるからみんなまいってる

961 :仕様書無しさん:2015/10/25(日) 10:17:27.88
>>960
整理、構成を変えるって、いまさら何をcommitするの?
長い文章の割に、話が全然見えん

962 :仕様書無しさん:2015/10/25(日) 12:12:37.16
ネジ飛んでるんだろ。近づいちゃ駄目よ

963 :仕様書無しさん:2015/10/26(月) 01:51:02.38
日本語おかしいね

964 :仕様書無しさん:2015/10/26(月) 06:13:36.29
これがカギカッコを閉じない病か……

965 :仕様書無しさん:2015/10/26(月) 22:11:41.47
病気か、気味悪いな

こういう文章を書く人は狂ってる
 こういう文章を書く人は狂ってる
  こういう文章を書く人は狂ってる

↑みたいにインデントが無限に増えていく病気もあるね

966 :仕様書無しさん:2015/10/27(火) 16:32:02.59
俺も先輩も徹夜続きで疲れていたんだけどさ、
レビューを始めた瞬間、ソース先頭にある

#define XX_NUM 1000

みたいな行を見て
「あ、マジックナンバー発見、ダメだね、やり直し、はい終了」
っていきなりレビューを打ち切られた時はどうしようかと思ったね。

967 :仕様書無しさん:2015/10/27(火) 19:00:16.51
define使うなconst使えってことですね

968 :仕様書無しさん:2015/10/27(火) 21:58:42.86
早くレビュー終わりたかったんだよ

969 :仕様書無しさん:2015/10/28(水) 21:05:44.11
>>966
まあ、マジックナンバーじゃないしな。

用語が間違っている。

970 :仕様書無しさん:2015/10/31(土) 06:43:40.14
じゃあ何だよ?マジカルニューメリックストリングか?

971 :仕様書無しさん:2015/11/04(水) 13:25:42.21
マジレスしたら敗けな流れなのか?

972 :仕様書無しさん:2015/11/04(水) 19:30:18.00
>>971
いやマジレスくれよ
こっちはずっとモヤモヤしてんだから

973 :仕様書無しさん:2015/11/04(水) 19:58:53.15
>>966はマジックナンバーに対抗するアンチマジックだよ。
それをマジックナンバー言われたら>>966も浮かばれまい。

974 :仕様書無しさん:2015/11/04(水) 21:44:29.50
はたしてこれが俺が望んだ答なのだろうか?
モヤモヤするぅ〜

975 :仕様書無しさん:2015/11/04(水) 23:27:00.12
966 仕様書無しさん sage 2015/10/27(火) 16:32:02.59
俺も先輩も徹夜続きで疲れていたんだけどさ、
レビューを始めた瞬間、ソース先頭にある

#define XX_NUM 1000

みたいな行を見て
「あ、マジックナンバー発見、ダメだね、やり直し、はい終了」
っていきなりレビューを打ち切られた時はどうしようかと思ったね。

976 :仕様書無しさん:2015/11/04(水) 23:37:23.23
プログラム上、何の説明もなく1000と出てきたらマジックナンバー。

これを回避しようとしたのに、レビュアーがマジックナンバーと言いはった。

こういうのは案外ありがちで、無知は正反対、常識はずれのこと言う。

呼ばれるプログラムに対して、呼ぶプログラムの説明を書かせたりといったこともある。

977 :仕様書無しさん:2015/11/05(木) 00:54:32.61
#define XX_1000 1000

みたいなのも、ある意味マジックナンバーだよな
なんで定数値とほぼ同じ定数・・・?

978 :仕様書無しさん:2015/11/05(木) 01:32:48.23
>>977
それはマジックナンバーじゃないから

979 :仕様書無しさん:2015/11/05(木) 01:43:41.17
レビューアーとレビューイっていうのは上下関係じゃないんだよ。

レビューする人が偉いわけじゃないし
レビューする人が許可を与えるわけじゃない。

だからレビューアーには判断した理由の説明責任が伴う。
理由を求められたらその理由を言わないといけない。

ただしそのレビューが教育目的である場合は除く。その場合は理由を言う代わりに
理由を言わないのは教育目的であることを伝え、そして自分で考えさせたあと答え合わせをすること。
頭ごなしにこれじゃダメだ。自分で考えろというだけの放置はダメ。
そういうレビューアーは教育もせずに時間だけを無駄に使ってるわけだから、会社に損害を与えている事になる。

判断理由の説明責任というのは、必ずしも代案を示すということではない。
このコードはよくないがレビューアーにもどうするのがいいかわからないことはある。
その時は「どうすればいいかわからないが○○という理由で良くない。
もっといい方法がないか考えてくれ」という相談をすればいい。

980 :仕様書無しさん:2015/11/05(木) 01:44:09.20
むしろマジックナンバーより凶悪。

981 :仕様書無しさん:2015/11/05(木) 01:45:19.07
>>978
変則的なXX_1000はマジックナンバーだよw

XX_1000とは何の値ですか?と言われてXX_1000です!
と答えられないようなものは数値に名前をつけてることになっていない。

982 :仕様書無しさん:2015/11/05(木) 05:18:08.12
Cなら#defineマクロでもなくconst intでもなく
enum定数使うのが一番問題が起きないのでオススメなんだよなあ
C++ならconstでいいけど。

983 :仕様書無しさん:2015/11/05(木) 05:51:15.13
>>979
レビューアーに対する鬱憤が溜ってるんだなwわかるw

984 :仕様書無しさん:2015/11/05(木) 06:03:34.99
>>989
いやいや、俺がレビューアになることが多いからw
これは心構えだよ。

985 :仕様書無しさん:2015/11/05(木) 06:12:41.09
>>984
早朝からちっさい見栄はんなw

986 :仕様書無しさん:2015/11/05(木) 07:26:06.88
レビュッ! あ、いい♂!

987 :仕様書無しさん:2015/11/05(木) 09:03:25.03
>>984
未来アンカ振られてドヤ顔されても…。

988 :仕様書無しさん:2015/11/05(木) 12:47:32.10
>>984
書き込む前にセルフレビューくらいしろよ

989 :仕様書無しさん:2015/11/05(木) 13:17:47.59
俺が何言ったんだよ。

990 :仕様書無しさん:2015/11/05(木) 14:03:28.79
>>989
自分の股間に手を当ててよく思い出してみろよ

991 :仕様書無しさん:2015/11/05(木) 18:28:29.80
こういう茶化すしか能がない人間っているよなw

992 :仕様書無しさん:2015/11/05(木) 19:25:01.65
そりゃ、いるかいないか、ということであればいるだろうな。
で、だから何なの?
無能すぎて言いたいこともいえないの?

993 :仕様書無しさん:2015/11/05(木) 19:27:55.08
誰が誰を茶化しているのかよく分からんけど俺は決してアスペではない

994 :仕様書無しさん:2015/11/05(木) 21:02:39.29
>>990

ポゥ!ダッ!ヒィ〜ヒィ〜ア〜ウ!

995 :仕様書無しさん:2015/11/05(木) 21:03:29.19
XX_1000なんて命名は一般的にはNGだけど、明らかに変わりえない値なら有りかね。

変わりえない0をstatic final int ZERO = 0;とかするし。
まぁ、0の直書きでいーじゃんとも思うけど。

996 :仕様書無しさん:2015/11/05(木) 21:42:09.07
>>995
ZEROって何のゼロか分からない
定数を見ても意味が伝わってこない
全然ダメじゃん・・・

997 :仕様書無しさん:2015/11/05(木) 22:01:40.92
>>996
何のゼロって、数字のゼロに決まってんじゃんwww
いちいちCOUNT_ZEROとかNUM_ZEROとかやんねって。

998 :仕様書無しさん:2015/11/05(木) 22:04:11.33
>>995
> 変わりえない0をstatic final int ZERO = 0;とかするし。

int a = ZERO を int a = ERO に書き換えれば
a は EROになるじゃんw

ZERO(定数部分)は書き換えませーん。っていうのなら、
int a = 0 の 0を書き換えなければ、a = 0だよね?


マジックナンバーっていうのは数字がダメって話じゃなくて、
数字に名前がついていないことがダメってことなんだよ。

999 :仕様書無しさん:2015/11/05(木) 22:11:15.81
コカ・コーラゼロの事かもしれんだろ

1000 :仕様書無しさん:2015/11/05(木) 22:16:09.42
同じ役割をする定数を役割名で定義するんだけど、
言って見れば、環境変わって値を変えても機能するか、がミソだな。
だから、単なる0をZEROになんて置き換えない。
配列Aの中身が無い事を表したいならEMPTY_Aとかにする。
当然、配列Bの中身が無い事を表したいならEMPTY_Bだ。

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

1002 :1002:Over 1000 Thread
2ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 2ちゃんねる専用ブラウザからの広告除去
★ 2ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
http://premium.2ch.net/
http://pink-chan-store.myshopify.com/


246 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)