これからコードを書く人に絶対やって欲しいこと★2

1 ：仕様書無しさん：2013/04/07(日) 02:26:29.92

もしくはやって欲しくないこと
先輩方のアドバイスをください

前スレ
これからコードを書く人に絶対やって欲しいこと
http://kohada.2ch.net/test/read.cgi/prog/1362887297/

2 ：仕様書無しさん：2013/04/07(日) 02:31:59.48

宗教論争が激化する傾向にあります．ご注意ください．
http://www.bugbearr.jp/?プログラミング言語%2F宗教論争

3 ：仕様書無しさん：2013/04/07(日) 08:15:57.65

糞スレになっちゃったしどうでもいいわー

4 ：仕様書無しさん：2013/04/07(日) 10:02:21.14

スレタイが漠然としてて論争になりがちだよな

5 ：仕様書無しさん：2013/04/07(日) 11:00:39.42

馬鹿が馬鹿な論争しかしないスレをまた立てたんか。
おまいら、このスレに専念していろよな。

隔離スレ決定

6 ：仕様書無しさん：2013/04/07(日) 11:21:30.58

以下の三冊は必読。
『コードコンプリート』
『リーダブルコード』
『達人プログラマ』

7 ：仕様書無しさん：2013/04/07(日) 11:37:12.25

また1文字変数の話題で1000目指すの？

8 ：仕様書無しさん：2013/04/07(日) 11:52:27.62

三項演算子って書き方で随分とみやすさが変わるよな。
みんなどんな書き方をしてる？

9 ：仕様書無しさん：2013/04/07(日) 11:54:58.75

よくある三項演算子の書き方例

スタンダード
value = cond1 ? value1 : value2

value = cond1 ? value1 :
　　　　cond2 ? value2 :
　　　　cond3 ? value3 :
　　　　　　　　　　value4

10 ：仕様書無しさん：2013/04/07(日) 11:57:47.78

条件や値が長くなった場合
value = condcondcondcondcondcond1
　? valuevaluevaluevaluevaluevalue1
　: valuevaluevaluevaluevaluevalue2

11 ：仕様書無しさん：2013/04/07(日) 11:58:32.30

ただ問題は、三項演算子は見やすい書き方があるが
これに対応したフォーマッターがないということ。
カスタマイズも難しい。

12 ：仕様書無しさん：2013/04/07(日) 11:59:48.76

>>9の二つ目は分かるけど>>10みたいに三項のうち一つでも改行するなら俺はifを使うなぁ

13 ：仕様書無しさん：2013/04/07(日) 12:11:45.91

またフォーマッタの話題か。
スレ立ててやったからこっちでやれ

フォーマッターを使う人と使わない人の違い
http://toro.2ch.net/test/read.cgi/tech/1365304270/

14 ：仕様書無しさん：2013/04/07(日) 12:13:40.83

value = if cond1 then value1 else value2

15 ：仕様書無しさん：2013/04/07(日) 12:14:11.44

>>12
こう書くって話？

int value;
if(condcondcondcondcondcond1) {
　value = valuevaluevaluevaluevaluevalue1
} else {
　value = valuevaluevaluevaluevaluevalue2
}

「変数の再代入は禁止」という考え方には反してるな。

16 ：仕様書無しさん：2013/04/07(日) 12:14:49.50

>>14
ifが戻り値を返す言語だね。
その書き方は、三項演算子と同じだよ。

17 ：仕様書無しさん：2013/04/07(日) 13:54:02.54

>>15
宣言しなければよくね？って言語によるのか俺がアホなのか

18 ：17：2013/04/07(日) 13:59:30.01

つーか再代入禁止するとi++とかどうすんだよｗ
って思う俺はやっぱりアホなのか

19 ：仕様書無しさん：2013/04/07(日) 14:34:03.07

>>13
いちいちクソスレ立てんなカス

20 ：仕様書無しさん：2013/04/07(日) 17:31:53.21

>>6
リーダブルコード以外読んで無いからよんでみようかな

21 ：仕様書無しさん：2013/04/07(日) 17:32:41.21

変数名つけるときの単語力が乏しいんだけど
実際に命名された変数名まとめみたいなのないのかな

22 ：仕様書無しさん：2013/04/07(日) 19:07:45.98

俺もそういうの欲しい
hoge1
hoge2
fuga
とかになる

23 ：仕様書無しさん：2013/04/07(日) 19:21:20.36

『アプリケーションを作る英語』という本がお薦め。
もともと、ローカライズするときのUIとかメッセージに使う英語の話題を扱ったものなんだけど、シンボルの名前を決めるときの参考にも十分なるよ。

24 ：仕様書無しさん：2013/04/07(日) 19:57:54.26

>>23
早速買ってみる

25 ：仕様書無しさん：2013/04/07(日) 20:03:01.21

変数名こそググってコピペろよ。

26 ：仕様書無しさん：2013/04/07(日) 20:08:40.81

良し悪しが判断できないのよ...
もっと良い表現があるのではないかと

27 ：仕様書無しさん：2013/04/07(日) 20:41:04.74

変数名なんて適当でいいんだよ、コードが分かりにくいのは名前のせいじゃない。

28 ：仕様書無しさん：2013/04/07(日) 20:46:08.61

>>27
名前は大事

29 ：仕様書無しさん：2013/04/07(日) 21:00:15.21

変数名に限らず関数名やマクロ定義もそうだけど、リテラルの名前付けは重要。
無駄にコメントの量ばっか増やさなくても、読んで理解しやすいリテラル名を考えろ。

30 ：仕様書無しさん：2013/04/07(日) 21:03:13.90

リテラル名てお前

31 ：仕様書無しさん：2013/04/08(月) 02:44:55.60

今思えばCの関数とかきもい名前ばっかりだ

32 ：仕様書無しさん：2013/04/08(月) 03:49:06.31

UNIXのシステムコールと連携してるからな。
昔のFORTRAN時代は、パンチカードの制限からラベルは6文字以内の制限が有った。
creat(2)は何とかして欲しかった。

33 ：仕様書無しさん：2013/04/08(月) 20:29:38.10

あえていうが（プレフィックス抜きにして）Win32APIの命名は好き

34 ：仕様書無しさん：2013/04/08(月) 22:20:00.93

あれは半分Smalltalkだ。

35 ：仕様書無しさん：2013/04/08(月) 23:25:45.12

対抗してBigMouth

36 ：仕様書無しさん：2013/04/09(火) 01:17:25.05

前スレまとめ

11 ：仕様書無しさん [↓] ：2013/03/10(日) 16:43:56.60
短いコードであってもパッと見て意味がわからないのなら
関数（メソッド）を作れ。

コメントを書くぐらいなら
適切な名前の関数を作ったほうが良い。

例えば、正規表現を書くよりも、その正規表現で
やりたいことを意味する関数を作ったほうがいい。

12 ：仕様書無しさん [↓] ：2013/03/10(日) 16:47:33.91
動的型付け言語なら高機能なテキストエディタを使え
静的型付け言語ならIDEを使え。

なぜなら、動的型付け言語ではIDEのサポートが十分に得られない。重いだけ。
静的型付け言語はコード自体は冗長になるが、IDEのサポートで大幅に生産性が上がる。

13 ：仕様書無しさん [↓] ：2013/03/10(日) 16:49:32.42
人力テストは極力なくせ。

人力テストとは、ブラウザを開いてフォームに値を入れてクリックするとか
アプリを起動してメニューを選んでクリックするとか、
出力ファイルを眺めておかしい所がないかチェックするとか、
そういうことを人間が毎回操作してテストすることだ。

37 ：仕様書無しさん：2013/04/09(火) 01:18:01.01

14 ：仕様書無しさん [↓] ：2013/03/10(日) 16:53:02.79
理由が書いてない（納得出来ない）
コーディング規約はゴミだ。作るな。従うな。

初心者のためのコーディング規約は糞だ。
（難しくてわからないから）○○機能は使わないこと。

糞な規約の例として
三項演算子は使わない。
クラスは作らない。
継承は使わない。
等がある。

15 ：仕様書無しさん [↓] ：2013/03/10(日) 16:55:11.95
コードは書くことよりも、読む時のことを考えろ。
短く書いたとしても、読みにくければそれは駄目なコードだ。
コーディングにかける時間の8割は、コードを読むことに使わている。

18 ：仕様書無しさん [↓] ：2013/03/10(日) 17:01:08.92
循環的複雑度。これを早い段階で計測できるようにしろ。
客観的にコードの汚さ、目安が計測できる。
これは各言語ごとにツールが有るはずだ。

19 ：仕様書無しさん [↓] ：2013/03/10(日) 17:05:02.98
警告は有効にし、警告レベルは最大にしろ。
エラーはログに表示させ、そのログを見ることを覚えろ。
場合によっては、それができる仕組みを作れ。

あれ？なぜか動かない？原因がよくわからない。などという時
実はちゃんと設定やコードを書けば、起きてるエラーが取得できる事が多い。

余談だが、データベースの設定に警告レベルがあったりもする。

38 ：仕様書無しさん：2013/04/09(火) 01:18:49.37

860+1 ：仕様書無しさん [↓] ：2013/04/06(土) 10:28:35.30
1. ifとforを多用したコードを書くのはやめよう。よく使う処理は既に汎用的なものがないか調べよう。
　判定や繰り返しは別の解決法がないかを考えよう。
　ただし再帰はバグの温床だから、ループの変わりに使うのだけは気をつけて。

2. 重複コードを書くのはやめよう。
　同じような処理をする場合共通化を図ろう。
　最初から完璧に共通化を図る必要はないが、汎用的に使える処理かは常に検討しながら書こう。

3. 重複コードを減らすためにリファクタリングは必ずやろう。
　ちなみに、リファクタリングは多少時間を置いてから見たほうが捗ることもある。
　実装直後だと、まだ覚えてるから簡単に読み解ける処理がある。
　後からみても仕様がすぐ頭に入るようなコードを心がけておくと、後の修正量が少なくてすむよ。

4. リファクタリングのために単体テストの設計、実装はやろう。
　単体テストが作りやすいコードは見通しが良い。できるだけテストと平行して開発するように心がけよう。

動いてるコードを修正するなっていう老害が多い業界だけど、
UTがきちんと実装できていない、書いたコードは読み直せないほど汚いってのが理由だから、
これからコード書く人は、同じ轍は踏まないように、そういった馬鹿発言が飛び出すことのないようなコードを書けるようになろう。

39 ：仕様書無しさん：2013/04/09(火) 01:43:03.72

循環的複雑度ってやつ気になる
やってみよ

40 ：仕様書無しさん：2013/04/09(火) 01:49:53.63

これ、ちょっと極端な部分も多いけど、なかなかよかった
ttp://www.slideshare.net/MoriharuOhzu/ss-14083300
実務だと色々な制約からもう少し大きいクラスになりがちだけど。

41 ：仕様書無しさん：2013/04/09(火) 01:51:21.65

>>15
俺ならその判定処理をメソッドにして、代入ではなくreturnするな。

42 ：仕様書無しさん：2013/04/09(火) 01:53:05.52

>>40
内容もだけどスライドのセンスが素晴らしい...

43 ：仕様書無しさん：2013/04/09(火) 06:20:38.85

>>40
1クラス状態変数2つまでってのは守れそうもないわｗ

44 ：仕様書無しさん：2013/04/09(火) 07:49:23.82

スライドは綺麗だけど、内容はコピペじゃね？

45 ：おじゃばさま：2013/04/09(火) 08:17:37.05

処理が長くなったからと言って、無闇に関数化するのは問題があるだろう。
関数分割の基本は変数に着目し、
そのスコープか最小になるように分割する事だか、
分割した関数の引数が多くなってしまっては、
スコープかが小さくなったとは言えない。
通常はあくまでも基本を優先すべきだろう。

46 ：おじゃばさま：2013/04/09(火) 08:33:07.22

JUnitのような物は注意がひつようだ。
本当に単体試験の代わりに使うと、開発コストが3倍になる。
あれは機能変更後のデグレ確認用の結合試験を自動化しているのを見て、
単体試験をしていないどこかのバカが、単体試験用に適用した物だ。
もし使えと要求があらなら、単体試験は通常に実施し、デグレ確認用に軽く作る程度がいいだろう。

47 ：仕様書無しさん：2013/04/09(火) 08:39:01.00

JUnitはJavaが言語的にウンコすぎて
超絶的に使いにくく冗長になってるんだよね
SmalltalkのSUnitから輸入したけど、JavaはSmalltalkじゃないから

だからxUnitは悪くない。悪いのはウンコすぎるJava

48 ：おじゃばさま：2013/04/09(火) 08:40:54.26

コーディング規約は仕様だ。
納得いかなければ、コーディング規約を変更すべきである。
変更出来なけれは従うしかない。
勝手に無視して作り直しを要求されても、文句は言えない。

49 ：仕様書無しさん：2013/04/09(火) 08:59:44.04

>>40
いいねこれ、特に次の二つ。
・省略したいほど長い名前がつく原因を考える
・複雑度１０まで
実業務でも数％程度の例外を除けば、十分達成出来る目標だ。

50 ：仕様書無しさん：2013/04/09(火) 16:35:23.75

>>40
いやあ、見応えあった
凄いね
紹介ありがとう

51 ：仕様書無しさん：2013/04/09(火) 18:21:09.43

>40
それまさに今日業務中にみたスライドだ
神クラスで検索したら出てきた

52 ：おじゃばさま：2013/04/09(火) 19:05:05.28

単体試験を行う上で最低でも3種類の試験が必要になる。
1.ルート試験：全ての分岐、繰り返しに想定した条件で入るか確認する。
2.入出力試験：想定した条件の時、リターン値、出力パラメータ、データベース等に想定した値が出力されるか確認する。
3.メッセージ、ログ試験：画面、ログ等に出力されたメッセージが正しいか確認する。また、ログに不要なメッセージが出力されていないか確認する。
重要度は記載順だか、たまに2しか実施しない者がいる。
最近はさらに2すら実施しない者がいる。

53 ：仕様書無しさん：2013/04/09(火) 19:22:36.08

カチカチの命令型脳だなw

54 ：おじゃばさま：2013/04/09(火) 19:25:32.20

JUnitは基本的に2を自動化するツールで、
簡単に1を試験出来ない以上、
中途半端と言わざるを得ない。
まあ、単体試験を実施しない人が使えば、
何もしないよりはマシだが。

55 ：仕様書無しさん：2013/04/09(火) 19:27:43.68

JUnitみたいな劣化コピーを基準にして何がうれしいのだろう？

56 ：おじゃばさま：2013/04/09(火) 19:36:24.68

>>55
SUnitはルート試験を簡単に出来るのか？

57 ：仕様書無しさん：2013/04/09(火) 19:38:36.16

>>52
1.2.の違いが分かんねー
2って全部の結果を試すことじゃないの？

58 ：仕様書無しさん：2013/04/09(火) 20:45:14.97

>>57
一般的なソフトウェア工学の用語に当てはめれば，
　1.ルート試験がホワイトボックス試験で、
　2.入出力試験がブラックボックス試験
ではないかと思われ

59 ：仕様書無しさん：2013/04/09(火) 21:00:39.04

xUnitを使わないで単体テストしてる人ってどうやってるのか興味ある。
今まで聞いたのは、IDEでステップ実行してますとかで話にならない。
UIがない場合はコードで呼び出す必要があるんだが、だったら例外を発生するテストができたり、管理機能があったり、結果出力機能があったり、豊富なアサーションが用意されてるxUnitを使うのがいいと思うんだけど。

60 ：仕様書無しさん：2013/04/09(火) 22:31:24.97

>>58
なるほど、納得です！

61 ：おじゃばさま：2013/04/09(火) 23:31:50.74

>>59
デバッガでステップ実行だ。
それ以前にルート試験の試験項目表を手動で作る。
これが重要で、この時に半分以上のバグが取れる。

62 ：仕様書無しさん：2013/04/10(水) 00:07:29.42

>>61
それ、バグ修正したりリファクタリングしたらまたやり直すの？
仕様変更があったら、また項目表から作り直す？
それと、テストがOKだったかどうかの確認はどうやるの？

63 ：仕様書無しさん：2013/04/10(水) 00:10:12.08

ステップ実行するにしても、xUnitでテストコード書いてから実行した方が楽だと思うんだけど、どうかな。

64 ：仕様書無しさん：2013/04/10(水) 00:24:17.93

皆さんがxUnitの入門に使われた文献を知りたいです

65 ：仕様書無しさん：2013/04/10(水) 01:32:46.20

xUnixに見えて仕方が無い。

66 ：仕様書無しさん：2013/04/10(水) 02:35:34.36

『JUnitでテストしています!』　の実態が、
JUnitをランチャーがわりにステップ実行し、
結果を目視確認することだった時の衝撃は大きかった。

67 ：仕様書無しさん：2013/04/10(水) 03:44:57.32

>>66
あるあるｗｗｗｗｗｗｗ

あるある・・・
いくら提案しても頭の硬いジジイどもが
最終的には人間がその目で確認しないとダメだとか抜かしやがる畜生め

68 ：仕様書無しさん：2013/04/10(水) 04:58:08.40

>>67
人間がｗその目でｗｗヒューマンエラーｗｗｗ

69 ：仕様書無しさん：2013/04/10(水) 05:34:55.91

そんな人はさすがに見たことないが、IN/OUTデータをハードコードする人多すぎる
お願いだから外部リソースにしてくれ

70 ：仕様書無しさん：2013/04/10(水) 06:29:46.73

>>69
どういうこと？
ハードコードするから良いんだと思ってるけど。

71 ：仕様書無しさん：2013/04/10(水) 07:18:06.23

xUnitは各コードが単独で完結していることが大事。
当然データはハードコードするべきだな。

72 ：仕様書無しさん：2013/04/10(水) 07:22:19.08

おじゃばはじゃば名乗ってる割に未だにじゃばに向いてない考え方通してるよな

73 ：仕様書無しさん：2013/04/10(水) 07:25:31.82

仕様書をハードコードしたのがテストコードだと思うよ
仕様が変わったらテストも変わる

74 ：仕様書無しさん：2013/04/10(水) 07:31:17.88

>>59
Web系だと、単体とか言いながら結合して画面ポチポチして単体テストしました！とか未だに言ってる職場多いよ
猿かよ

75 ：仕様書無しさん：2013/04/10(水) 08:02:32.99

>>45
どこに向けたレスかわからんので気になったんだけど、「無闇な関数化」ってどこに向かって言ってるの？
そういう話題が出てきた箇所はないような気がするんだけど、単なる主張？

76 ：おじゃばさま：2013/04/10(水) 08:15:19.61

>>62
バグ修正はバグ票で修正確認まで対応。
修正が多い場合や仕様変更は、修正箇所分のみ試験仕様書を新規作成。
基本的に単体試験仕様書は使い捨てで、変更があった場合は追加する。
そうしないと進捗管理が困難になる。
テストのOKは目視で確認。

77 ：仕様書無しさん：2013/04/10(水) 08:25:38.61

JUnitがホワイトボックスに使えないわけないよ。
ケース作成が大変だっていうなら、それはテスト対象のメソッドが冗長すぎるだけだと思う。
IOしかみないブラックボックステストを後付けで作るならそうなるんだろうけど、別にそれだけしかできないツールじゃなかろう。
なんとかと鋏は、みたいな話。

78 ：仕様書無しさん：2013/04/10(水) 08:26:28.88

>>64
Javaがメインのプログラマだけど、
JUnitでぐぐっていくつか拾い読みしたくらいだ。

あとは使ってみて、自分なりに効率よくテストできる方法を構築してく感じ。

参考にならなくてスマソ

79 ：仕様書無しさん：2013/04/10(水) 08:27:15.90

ここも結構よかった
http://objectclub.jp/technicaldoc/testing/stack_tdd.pdf/view

がちがちにTDDする必要はないと思うけど、
テスティングペアを使ってメソッド単位で動確とりながら実装するのは品質上がるから
これからコード書く人にもお勧め

80 ：おじゃばさま：2013/04/10(水) 08:32:59.06

>>63
66の言うように紛らわしくなるから止めた方がいいだろう。

>>68
JUnit使っても1回目はヒューマンエラーは起きる。
起きないのは同コードの2回目以降。

>>72
俺はJUnitの犠牲者だ。
俗に言う人柱だな。

>>74
確かに多い。
つーか、試験仕様書書かずに試験完了って何だよ。

81 ：仕様書無しさん：2013/04/10(水) 08:33:43.87

>>78
自分もそんな感じ
あとは実際に使われてるソースみたりとか、くらい

っていうかネットで何でも調べれる今日日、技術書買う必要性感じてないな

技術書を否定するわけじゃないけど、本は閉じられた情報だから、
間違いや過去の情報が更新されることもないってデメリットもあるしね
あと本買うとそれで満足しちゃいそうだからってのもあって、自分はめったに技術書自体を買ってない

英語苦手だから英語サイトにしか情報がないとしんどいけど、
技術系文章なら用語が多いから機械翻訳でも割と何とかなるぜ

82 ：おじゃばさま：2013/04/10(水) 08:36:46.33

>>75
40のスライドとか、一文字変数の所で、行数が多いなら分割しろと出てた。

83 ：仕様書無しさん：2013/04/10(水) 08:43:58.69

>>82
なる

確かに意味のない単位での分割はダメだと思う
だけど、さすがにそんな単位で分割する人はいないと思うし、書き忘れなだけな気はする

20行ずつとか適当な単位でメソッド分けて

処理1();
処理2();
処理3();

とかやられてたらブチきれかねない

84 ：仕様書無しさん：2013/04/10(水) 08:58:18.88

>>80
たしかにJUnitでもヒューマンエラーは起きる
テストの方の数字間違えてたりするし

85 ：仕様書無しさん：2013/04/10(水) 09:09:27.80

>>45
そうじゃなくて、冗長になるような実装そのものがおかしいってこと。

そもそもそういう「大きな」処理が出てきた時点で
処理全体の捉え方がオブジェクト間の連携じゃなくて
手続き中心になってんじゃないの、って話な。

86 ：仕様書無しさん：2013/04/10(水) 09:58:47.44

GUIのテストってどーすんの
マウス動作の自動化ツールとか使うんか

87 ：おじゃばさま：2013/04/10(水) 20:39:02.26

>>77
ホワイトボックスに使うとひどい目にあう。
だから使う時は、結合試験のデグレ確認用に使っている。

>>79
これからコードを書く人にはお勧めできない。
まず基本のルート試験（ホワイトボックス試験）、入出力試験（ブラックボックス試験）を、
試験項目表を書いて実施するのを覚えて欲しい。
大手企業なら通常は単体試験実施要項と言う資料があり、
最低でも上記2種は行う事になっているだろう。
ただ、結構無視して以前の試験項目表をサンプルにして実施される事も多いが、
一度は目を通しておいても損はないだろう。

88 ：おじゃばさま：2013/04/10(水) 20:44:52.86

>>85
前にも書いたが、入力チェックや、項目の多いDBテーブルの登録更新処理、帳票出力処理などは、長くなる事が多い。

89 ：仕様書無しさん：2013/04/10(水) 20:52:01.52

>>88
入力チェックがアホみたいに長くなるのは
全部の項目を一括してチェックしてるからだろ

90 ：仕様書無しさん：2013/04/10(水) 21:06:47.50

内部処理用のメソッドのテストを対象にしてxUnit使ってるからホワイトボックスのほうがコストかからん
むしろブラックボックスにxUnitって、業務系だとテスト対象メソッドの機能が重くなりすぎてテストケースろくに作れんやん

91 ：おじゃばさま：2013/04/10(水) 21:34:00.77

>>90
ちなみに、コード修正したらテストコードも修正だよな。

92 ：仕様書無しさん：2013/04/10(水) 21:38:14.51

老害から悪習を引き継ぐオッサンになってしまったら、いつまで経っても環境は良くならん。
Excelベースの試験仕様書とか作るような全時代の手法は、少しずつでも改善していくべき。
めんどくさい作業を簡単にするための道具は次々に発明されてるんだし、学ぶことを辞めたらマは終わりだと思うわ。

ttp://www2.ocn.ne.jp/~cheerful/develop/waterdev/test_diff_UT_FT.html
A～E全てのモジュールで全ケース網羅できるテストをJUnitなりで作るのは容易い。
それができないようなら、メソッドなりクラスなりがピザすぎるのが原因だろう。

おじゃばがJUnitを使って作成してるテストケースは、上記サイトでいうとこのXの単体テストを作ろうとしてるんじゃね。
そんなんやったら下の図のようになって自滅もするだろう。
機能テストに単体テストツールを使うのが間違いだったってことだろう。

93 ：仕様書無しさん：2013/04/10(水) 22:25:45.28

>>91
その質問は、コード修正したらテストするよな？って聞いてるのと同じレベルだと思う

94 ：おじゃばさま：2013/04/10(水) 22:54:10.44

>>93
メンテナンスの放棄された大量のテストケースコードがあるのだか、
どうすればいいんだ、これは。

95 ：仕様書無しさん：2013/04/10(水) 22:57:38.04

おじゃばの言う単体テストって、対象はどの単位で考えてるの？
それと、テストは具体的にはどうやってるの？対象をステップ実行するためには、それ呼び出す何かが必要だよね。
あと、IDEがない言語の場合は単体テストはどうやるの？goとか。

96 ：仕様書無しさん：2013/04/10(水) 23:00:39.80

そうそう、おじゃばはTEST PRESSとか読む？
NTTDみたいな大手もJUnit使ってるよ。

97 ：おじゃばさま：2013/04/10(水) 23:11:45.07

>>92
単体試験ツールが出る度に期待して試すが、デバッガ以降に期待に応えてくれた物はない。
残念ながら現在、俺の知る限りExcelの手書き試験項目表に代わるものはない。
JUnitはガキのオモチャ。

98 ：仕様書無しさん：2013/04/10(水) 23:20:26.23

テスト設計と管理は別にExcelでやってもいいが、実装でxUnitを避ける意味がわからない

99 ：仕様書無しさん：2013/04/10(水) 23:29:42.00

100 ：仕様書無しさん：2013/04/10(水) 23:31:38.65

言語の構文を理解したからといっていいコードが書けるわけではないのと同様に、xUnitの使い方が分かったからといっていいテストコードは書けないよ。ドシロウト時代にメンテ不能なテストコードを大量生産するのは仕方ない事かもしれない。

101 ：おじゃばさま：2013/04/10(水) 23:33:13.18

>>95
単体試験だからメソッド単位で、ルート試験、入出力試験、メッセージ試験を行う。
メインから順に試験を行う。メインがない場合は、ダミーメインを作る。
gdbなどのデバッガを使う。今はデバッガがない事は殆どないが、もしなければログを入れる。

>>96
読んでない。
使われているのは知っているが、みんな適当にやってる。
ひどいのはOK返してるだけとかある。

102 ：仕様書無しさん：2013/04/10(水) 23:33:17.72

>>97
馬鹿と鋏は使いようってことだな。

103 ：仕様書無しさん：2013/04/10(水) 23:35:24.21

テストコードを書くのが大変っていってるやつは、単にテストコードを書くのに慣れていないか、テスト容易性のことを考えていないか、テスト対象が糞コードのどれかだろう。
いずれにせよ、継続してテストコードを書かないと、慣れないし、テスト対象のコードも良くならない。

104 ：仕様書無しさん：2013/04/10(水) 23:40:01.72

テスト対象が糞コードってのが一番多いと思う
実装してからさあテストだみたいな思い込みで実装してる奴はここから抜け出せない
そういうコードを書く奴は、プログラミング初心者と、不勉強なおっさんにすごく多い

105 ：仕様書無しさん：2013/04/10(水) 23:40:04.89

>>101
適当にやってるってのは想像じゃないの？
俺はテストプレスにも良く執筆してるNTTDの町田氏が単体テスト行程の責任者の一人だった、docomoの新料金システムってのに参加してたんだが、結構まともにやってたぞ。

106 ：おじゃばさま：2013/04/10(水) 23:41:45.59

>>98
ソースの量が3倍になる。
メンテナンス放棄されたテストコードが残る。
通常の単体試験の代りにはならないため、
単体試験もやる事になるが、単体試験をやればJUnitは不要。

107 ：仕様書無しさん：2013/04/10(水) 23:49:47.35

>>106
何の三倍なのか良くわからないが、君が実装している独自のテストハーネス部分をJUnitにするだけでもメリットはあるよ。結果確認部分もJUnitのassertionにできればベスト。
JUnitにしとくだけで、第三者が君のテストコードを理解するのが容易になるし、各種ビルドツールとも統合しやすくなるし、CIツールにも組み込みやすくなる。

108 ：仕様書無しさん：2013/04/10(水) 23:54:11.45

保守が必要なドキュメントの量が格段に増える。
メンテナンス放棄されたドキュメントが残る。
自動化できないので、修正が発生するたびに無駄な時間を費やすことになる。
JUnitは単体テストツールなので、単体工程で正しく使えば
ステップ実行なんてアホな作業はやる意味が皆無になるぞ。

そういう環境で開発してると再テストが実質実施不可と同じ状態になるから
「動いてるコードは触るな」みたいなアホ発言とかが飛び出して来るしな。

109 ：仕様書無しさん：2013/04/10(水) 23:56:30.65

盛り上がってるみたいなので、テストに詳しい人いたら
http://kohada.2ch.net/test/read.cgi/prog/1365314038/21n
コメントくだちい

110 ：おじゃばさま：2013/04/10(水) 23:58:39.75

>>104
基本的にどんなコードでもテスト出来なけれはならない。

>>105
JUnitだけでやってたのか？
カバレッジ100%も条件になってなかったか？
もしなってなければ、NTTのナントカさんに、自社の単体試験実施要項を読めと伝えてくれ。

111 ：仕様書無しさん：2013/04/11(木) 00:06:00.91

>>110
質問の意味が良くわからないが、Javaを使うチームは単体テスト工程ではJUnitでテストするのが必須で、C1カバレッジ100%を目標にするというかなりアグレッシブなものだった。
なお、その町田氏が、単体テスト工程の実施要項を決める立場の人だったんだけどね。

112 ：仕様書無しさん：2013/04/11(木) 00:06:11.05

複数社とか大人数とかでやるプロジェクトで単体テストが必要なのはわかるが
小規模プロジェクトでも単体テストするものなの？

仕様テストだけで十分じゃないの？

113 ：仕様書無しさん：2013/04/11(木) 00:08:32.72

つまり何が言いたいかというと、少なくとも俺が参加したプロジェクトではまともな運用がなされてたわけで、君の全員が適当にやってるというのは想像じゃないのかってこと。

114 ：仕様書無しさん：2013/04/11(木) 00:15:09.03

>>112
バグは早く見つければ修正工数も少なくてすむ。
だから、どんな規模のプロジェクトでも単体テストはやる。

115 ：仕様書無しさん：2013/04/11(木) 00:17:01.06

だから>>92で既に言われてるけど、
おじゃばは機能テストにUTツール使って使えねぇって言ってるただのおばかさまだから

大きいプロジェクトになるほど、大抵は機能単位で担当者縦割りにしてるから、
その機能単位での結合テストを「単体テスト」なんて呼んでる事が多い
だからドキュメントベースでの手作業テストなんて時代遅れな事になる
ちなみに、純粋な単体テストは行わない事も多く、名前がついてないケースも多い

で、半端な知識から純粋な単体テストを、上記の単体という名前で呼ばれてる結合テストに当てはめようとして、
網羅率だとかホワイトボックスどうのとか言いはじめたりして、アホみたいなテスト工数がかかるようになって、自爆する

開発関連の用語は職場によって使い方がまちまちで、話がかみ合わない事も多いんだよな
多くの職場を経験して違いを知った人じゃないと、自分の世界の呼び方が全てだって思い込んじゃうし

116 ：仕様書無しさん：2013/04/11(木) 00:18:08.71

まあ、未だにエビデンスがーとか言われてる人は、御愁傷様と言わざるを得ない

117 ：仕様書無しさん：2013/04/11(木) 00:32:39.90

ブラックボックステストを自動化したいなあ( ´・ω・｀)

118 ：仕様書無しさん：2013/04/11(木) 00:36:08.84

>>112
メソッド単位での動作確認をとりながら実装できるから作って損しないよ
全部実装してからテスト、じゃなくて、テストとメソッドを同時に実装する感じ
簡単な処理からどんどん複雑な処理に修正してく感じで実装していく

慣れるまで多少手間かかることもあるけど、終了時点で動作確認まで済んでる状態になるから
ガチガチなテストをしてるレベルの品質のコードが、実装の作業だけで出来上がるようになるから
トータルで見たら時間はかからないよ

全部作ってからテストコード書くのは絶対手を抜きたくなるから、作るならテストを平行してやったほうがいいよ
Javaだったら、EclipseにQuickJUnitいれておくと、テスティングペアとの往復が楽になるのでおすすめ
コードテンプレにテストメソッドの生成用のものを用意しておくのも捗る

119 ：おじゃばさま：2013/04/11(木) 00:38:22.55

>>111
いたいた、JUnitでカバレッジ100%とか言うフザケた奴が。
結局、通らない所はデバッガで通して、スクリーンショットで代用した。
結局、従来の単体試験に加えて、テストコードとカバレッジデータの提出資料が増えただけ。
試験責任者は喜んでいたようだか意味ない。
結合試験でバグ修正してもテストコードは修正しないから、結局ゴミテストコードが残った。

120 ：仕様書無しさん：2013/04/11(木) 00:41:16.03

でたで、スクリーンショットエビデンスの糞職場ｗ
テストコード修正しない阿呆ばかりの開発環境は今も大変そうだな

121 ：おじゃばさま：2013/04/11(木) 01:28:34.75

だから結局、ホワイトボックス試験はやってないんだろ？
ブラックボックス試験をJUnitで自動化しているだけだろ？

122 ：仕様書無しさん：2013/04/11(木) 01:43:53.31

>>121
C1カバレッジという時点で、ホワイトボックステストなのは明らかですね。
もう少し考えてからレスしてくれないかな。
それと、君はxUnitを使った単体テストの素人だってことを忘れちゃダメだよ。メリットを知る前にやけちゃったんだから。

123 ：仕様書無しさん：2013/04/11(木) 01:47:51.67

オブジェクト指向をちょろっとかじって、これは使えんとdisりまくる
staticおじさんと似てるな

124 ：仕様書無しさん：2013/04/11(木) 01:50:33.44

>>121
それと、C1カバレッジ100%を目指すのがさもダメなことみたいに書いてるけど、docomoの携帯の料金システムなんだよ？十分なテストが必要なのは、火を見るより明らかですね。

125 ：仕様書無しさん：2013/04/11(木) 01:53:44.47

>>119
どちらかというと、コードを修正してテストを省略するのは、マニュアルテストの方じゃないかな

126 ：仕様書無しさん：2013/04/11(木) 01:55:14.47

気分はstatic懐かしいｗ

ttp://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html
これからコードを書く人は、こうはならないようにしないとだね

127 ：仕様書無しさん：2013/04/11(木) 02:53:35.17

つか、ステップ実行したエビデンスってどんなのだろう？

128 ：仕様書無しさん：2013/04/11(木) 02:55:18.93

>>126
何これ怖い

129 ：仕様書無しさん：2013/04/11(木) 02:57:25.65

>>126
一度だけ見たことあるが、ブレークして分岐に入ってるとこのSSを取って保存を繰り返してたよ
気でも狂ったのかと思ったよ

130 ：仕様書無しさん：2013/04/11(木) 04:29:21.32

メッセージ試験とか、そんなカビが生えたようなw

131 ：仕様書無しさん：2013/04/11(木) 04:30:24.98

>>126
実名あげてて大丈夫か？と思ったが最後にホッとしたｗ

132 ：仕様書無しさん：2013/04/11(木) 04:32:29.95

>>119って、C1の意味を理解しているとは思えないw

133 ：おじゃばさま：2013/04/11(木) 07:36:24.89

>>124
いや、本当にJUnitだけで品質が保てるなら結構な事だよ。
JUnitでC1カバレッジ100%出来たのか？
関数のエラーはどうやった？
大量のスタブとドライバ作ったのか？

134 ：仕様書無しさん：2013/04/11(木) 08:59:06.93

DIすらできてないだけな気がする
今日日依存性バリバリな設計とかかわいそすぎる

135 ：仕様書無しさん：2013/04/11(木) 11:04:28.16

>>133
あのさあ、君の>>101
> 使われているのは知っているが、みんな適当にやってる。
の反例として俺が参加したプロジェクトの話をしてるんだけど、君の発言は想像で言ってたの？そうじゃないの？

君が俺にできる反論は、「NTTDの新料金システムでJUnitが使われたが、実際はみんな適当でひどいのはOK返してるだけ」という証拠を出すことだね。

JUnitの品質に与えるインパクトは、ここで君と話すことじゃないね。
君は知識と経験がなさすぎて、議論にならない。

136 ：仕様書無しさん：2013/04/11(木) 11:32:41.50

>>134
xUnitを使うメリットはそこにもあるね。
実際にテストコードを書いていると、普通ならテスト容易性が重要だということに気づき、
テスト対象のコードの設計にまで思い至る。
…のが普通だと思うんだ、理想論かも。

137 ：仕様書無しさん：2013/04/11(木) 11:36:06.07

つまりは、xUnitを使わずとも上手くやれる連中が、xUnitを使えばもっと上手くやれるということにすぎない
もともと上手くやれてない連中は、xUnitを使っても上手くやれない

138 ：仕様書無しさん：2013/04/11(木) 14:47:14.49

なかなかの良スレ

139 ：仕様書無しさん：2013/04/11(木) 16:30:33.93

>>133
> 関数のエラーはどうやった？
> 大量のスタブとドライバ作ったのか？

ステップ実行のマニュアルテストが、mockitoやQuick JUnitを使ったユニットテストに勝るとは到底思えないが。

140 ：仕様書無しさん：2013/04/11(木) 16:31:59.12

>>131
ヒント：コメント欄
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html

元ネタが有名になってそれを真正面からネタにした記事だから話題になった話なんだよコレ

（4）で出てくる
「失礼だが、君は専門学校卒という経歴で、私に対してひがみを感じているのではないかね？」
はこの記事のコメント欄の
「非常に失礼なのですが、あなたは九州大学農学部卒という経歴で、何か私に対しひがみを感じているのではないのすか？」
が元ネタ

ググればすぐに元ネタに辿り着くし、実名挙げてるも同然だよｗ

141 ：仕様書無しさん：2013/04/11(木) 16:33:29.42

おじゃばは、「自分はテストのプロであり、JUnitの最高の使い手である。その俺でさえ、JUnitは
ステップ実行に劣るのだから、世のプログラマがJUnitを使ってメリットがあるはずがない」とか
思ってたりするのか？

142 ：仕様書無しさん：2013/04/11(木) 16:37:17.21

>>126
最終回のコメント欄がカオスすぎるwww

143 ：仕様書無しさん：2013/04/11(木) 16:45:02.53

>>141
どちらかといえば、JUnitを『銀の弾丸』だと思って失敗したように見える。

144 ：おじゃばさま：2013/04/11(木) 20:49:52.45

>>135
別のプロジェクトでJUnitでカバレッジ100%を要求されるプロジェクトがあって、
通信エラーやファイル書き込みエラーやメモリエラーのルートが、
出来ないしパターンも増えるため、
通常の単体試験を終えた後に、提出資料作成用に、
正常ルートのみのテストケースを作って、異常ルートはデバッガのキャプチャで出した。
Nの了解は取ってあるので問題はない。
試験を適当にやったのではなく、しっかり試験をした後に、
JUnitのテストケースを適当にやった。
スケジュール通りだった俺達は一応理論上100%で出したが、
遅れてたチームは超適当。最後には100%「目指す」だから、100じゃなくていいって事でうやむやになった。

145 ：おじゃばさま：2013/04/11(木) 20:55:39.71

>>136
テストの容易性のために、テストしにくいエラールートを作らないとかにならないようにな。

146 ：おじゃばさま：2013/04/11(木) 21:04:00.67

>>139
回線接続後の通信エラーはどうやった？
ファイルオープン後のライトエラーや、
リソース不足エラーは？
ループの入出条件チェックはどうやった？
少なくとも俺が使ってた頃は出来なかった。
今は出来るのか？

147 ：仕様書無しさん：2013/04/11(木) 21:57:13.26

>>144
君の経験を聞きたいわけじゃないってのがわからないかな。

>>145
テスト容易性についてもっと勉強してね。

>>146
mockが何か知らないってことだけは分かったよ。

148 ：仕様書無しさん：2013/04/11(木) 22:00:23.04

つかさ、テストに関する書籍も読んでないし、ムックも読まないし、Webの記事もチェックしてないし、経験も少ないんだろ？
何でテストに詳しげな態度取るかなあ。

149 ：仕様書無しさん：2013/04/11(木) 23:31:36.40

>>146
テスト云々より、設計が糞すぎて引くわ

150 ：おじゃばさま：2013/04/11(木) 23:57:36.02

>>149
設計がクソって何で？

151 ：おじゃばさま：2013/04/12(金) 00:07:27.16

>>148
じゃ、オススメの本を教えて下さい。
勉強して参ります。

152 ：仕様書無しさん：2013/04/12(金) 01:14:45.77

>>150
お前Java歴どのくらいだよ？
Cみたいな設計してんじゃねーぞ

153 ：仕様書無しさん：2013/04/12(金) 01:33:11.30

おじゃばコテハンにこだわるなら鳥付けたらいいのに

154 ：仕様書無しさん：2013/04/12(金) 01:38:49.87

おじゃばって結構長いし、歳もそこそこいってるよね30前半くらい？もっとかな？
同一人物なのかは知らんけど結構マ板暦長いのに、まだそんなところでうろうろしてるのは良くないと思うぜ。

あと、自分語りよりこれからコードを書く人にやって欲しいことを書こう。

155 ：仕様書無しさん：2013/04/12(金) 03:39:33.25

>>145
テストしやすいようなエラールート設計は非常に大事だが？

156 ：仕様書無しさん：2013/04/12(金) 04:25:21.49

偽物じゃないかと疑われるほど、レベルの低いレス。
もし本物だったら、その事を十分噛みしめるように。

157 ：仕様書無しさん：2013/04/12(金) 05:02:04.10

これからコード書く人は、かならずUTやれ。
結合テストの効率が全然違う。UT混みでもテスト時間が短くてすむ。

できれば、xUnitでいつでもテストできるようにする。

ちょっとした変更でも広範囲を簡単にリグレッションテストできるから、
バグ修正でデグレの可能性がかなり下がる。

修正したところの周辺だけUTやってリリースしたあと、
見落としたルートでバグ出すのは情けないからね。

158 ：おじゃばさま：2013/04/12(金) 07:49:08.62

>>152
CとJavaとShellの混合プロジェクトで、CとJavaでカバレッジ100%目指すだから仕方ない。

159 ：おじゃばさま：2013/04/12(金) 08:05:36.42

で結局、
1.ホワイトボックス+ブラックボックス+試験項目表
2.ホワイトボックス+ブラックボックス+テストケース
3.ブラックボックス+テストケース
4.単体試験しない
のどれなんだ？

160 ：仕様書無しさん：2013/04/12(金) 08:41:26.15

あまりスレ趣旨に沿ってない話題続けるのはどうかと思うぞ
なんかstaticオッサンと同じような雰囲気かもし出してる

161 ：仕様書無しさん：2013/04/12(金) 09:13:16.64

うわ、本人だったのか？
見苦しいからもうやめなよ。

162 ：仕様書無しさん：2013/04/12(金) 10:21:46.29

>>159
はいはい2

163 ：仕様書無しさん：2013/04/12(金) 10:36:34.61

>>151
『基本から学ぶソフトウェアテスト』
『ソフトウェアテスト293の鉄則』
『体系的ソフトウェアテスト入門』
『ビューティフルテスティング』
『レガシーコード改善ガイド』
『実践テスト駆動開発』
『JUnit実践入門』

164 ：仕様書無しさん：2013/04/12(金) 10:37:50.31

おっと忘れてた。
『ソフトウェア・テスト PRESS 総集編』

165 ：仕様書無しさん：2013/04/12(金) 11:35:32.93

>>158
>>133からの流れなのに、>>150はCの話でした、ということにしたいのか？

まあそれならそれでいいが、俺が「Cみたいな設計」と表現したのは、Cしか
知らない（オブジェクト指向のメリットを全く知らない）経験1年くらいの初心者が
やりそうな設計＆もちそうな疑問だからだよ。

C++やJavaを経験して、テストをコードで書き、自分なりにいろいろ調査し
試行錯誤してれば、Cでも>>150みたいなアホな疑問は抱かないわ。

166 ：仕様書無しさん：2013/04/12(金) 11:36:39.38

>>150じゃなくて、>>146だった。

167 ：仕様書無しさん：2013/04/12(金) 12:40:11.81

そもそも、JavaやJUnitの文脈で関数とか言う奴は信頼できんわ

168 ：仕様書無しさん：2013/04/12(金) 18:28:02.44

そもそもは>>46から始まった話なんだが、おじゃばはJUnitやmockの事をよく知らないのはおろか、
プロダクトコードの方の設計スキルも無いことを露呈してしまったというオチ。

169 ：仕様書無しさん：2013/04/12(金) 20:13:12.51

>>163
テンプレマーカー発動

170 ：おじゃばさま：2013/04/12(金) 21:33:43.88

>>165
本当にデバッガより便利なら喜んで使うよ。

ところで、オブジェクト指向の利点って何？

171 ：仕様書無しさん：2013/04/12(金) 22:06:26.77

>>170
なんだ、オブジェクト指向のメリットもわかってないのか。
つか、お前このスレで何がしたいわけ？
何か言えば言うほど墓穴掘るだけだぞ。

172 ：仕様書無しさん：2013/04/12(金) 22:07:44.46

あとお前の為に書籍を厳選してやったんだが、ガン無視かよ

173 ：おじゃばさま：2013/04/12(金) 22:14:04.29

>>172
いや、明日読んでくる。

174 ：おじゃばさま：2013/04/12(金) 22:15:34.59

>>171
オブジェクト指向のメリットは、変更に強い事だよ。

175 ：仕様書無しさん：2013/04/12(金) 23:46:25.05

オブジェクト指向を学ぶのに良い書籍ご存知ないでしょうか

176 ：仕様書無しさん：2013/04/12(金) 23:52:30.39

ステップ実行最強とか言ってる時点で、もう何を言っても無駄なんですけどね。
狭い世界でこれからも生きていけばいいさ。

177 ：仕様書無しさん：2013/04/13(土) 01:05:05.08

>>175
オブジェクト指向のこころ
オブジェクト指向における再利用のためデザインパターン(GoF本)
Java言語で学ぶデザインパターン入門

GoF本は必読だがとっつきにくかったら他のから入った方がいいかも

178 ：仕様書無しさん：2013/04/13(土) 17:31:45.42

おじゃばは非を認めようとも反論しようともしないで逃げるあたりもstaticオッサンと同類だな
これからコードを書く人は、歳くってもこうはならないようにして欲しい所だ

179 ：おじゃばさま：2013/04/13(土) 23:02:03.69

>>151
『基本から学ぶソフトウェアテスト』在庫なし
『ソフトウェアテスト293の鉄則』読んだ
『体系的ソフトウェアテスト入門』在庫なし
『ビューティフルテスティング』在庫なし
『レガシーコード改善ガイド』在庫なし
『実践テスト駆動開発』読んただ
『JUnit実践入門』在庫なし
『ソフトウェア・テスト PRESS 総集編』3/10読み中

今の所、俺の意見を肯定する記述ばかりだ。

180 ：仕様書無しさん：2013/04/13(土) 23:45:15.49

>>179
読んでくれて嬉しいよ。
できれば、今の考えを理論武装するためにではなく、新しい知識や新しい視点を見つける為に読んでほしい。

ところで、Amazonを使わないのは何か理由があるの？

181 ：仕様書無しさん：2013/04/14(日) 04:46:51.00

10ページぐらい立ち読みしただけだからだろw

182 ：おじゃばさま：2013/04/14(日) 10:13:12.40

>>180
アマゾンでは全部読めないだろう。
ツタヤではタダで読み放題だからな。
CDROMのやつは仕方なく買ったが。

183 ：仕様書無しさん：2013/04/14(日) 12:03:37.56

>>181
当たってた…

184 ：仕様書無しさん：2013/04/14(日) 22:57:05.43

デザインパターンの勉強ってみんなするものなのでしょうか

185 ：仕様書無しさん：2013/04/14(日) 23:33:17.83

>>184
知っておいて損はない。

186 ：仕様書無しさん：2013/04/15(月) 00:20:53.14

しかし知ったところで使い道は無い

のは俺だけか

187 ：仕様書無しさん：2013/04/15(月) 00:23:32.70

シングルトンは良く使う。

188 ：仕様書無しさん：2013/04/15(月) 00:39:24.57

シングルトンとファクトリーとストラテジーはよく使う
他に使えるやつある？

189 ：仕様書無しさん：2013/04/15(月) 00:51:00.20

アダプタ、プロキシ、ファサードなんかも結構使う。

190 ：186：2013/04/15(月) 00:52:33.90

>>187-189
なるほど勉強になります
シングルトンは使ってたわ

191 ：仕様書無しさん：2013/04/15(月) 02:05:03.82

シングルトンってただのギミックだよな
デザインパターンと呼ぶほどの規模ではない

192 ：仕様書無しさん：2013/04/15(月) 02:14:27.59

だからデザインパターンは、
「シングルトン」という名前一つで
何を意味するか定義した所が凄いのだと。
実装がどうとかいう話じゃねーよ。

193 ：仕様書無しさん：2013/04/15(月) 02:21:33.08

デザインパターンは知られていたことばかりだったかも知れないけれど
それを体形化して命名してくれたところに価値があるんじゃないかな
概念として共有出来る様になったからね

194 ：おじゃばさま：2013/04/15(月) 08:12:55.10

まず残念だったのは、やはりJUnitがデバッガのステップ実行に代わるものではなかったという事だ。
単にブラックボックス試験を自動化するものであり、
ホワイトボックス試験の全てを自動化すれば、
テストコードが増大し、開発工数が増え、またメンテナンスが困難で現実的ではないと書かれている。
結局、自動化テストも手動テスト重要で、
テストを全て自動化するのは間違いだという事だ。
はっきりと、
『ソフトウェアテスト293の鉄則』
にも書かれている。
何でオススメの本に明記されているのだろう？

195 ：おじゃばさま：2013/04/15(月) 08:39:47.92

次に俺も間違えていたが、他の人も間違えていた、
テスト駆動開発について。
テスト駆動開発は単体試験を同時に行うのではなく、
プログラム設計に単体試験の手法を利用する設計技法だという事だ。
つまり、普通の単体試験が検証型試験だとすると、
テスト駆動開発は設計型試験で、
テスト駆動開発で作成したプログラムに対しても、
検証型試験が必要だとの事だ。
これに関しては
『ソフトウェア・テスト PRESS 総集編』のCD内でも誤解している人がいる。
しかし、本文の方には明記されている。
また、『実践テスト駆動開発』にも書かれているか、
この本は非常にわかりにくい。
少なくとも翻訳者は内容を理解していない。

196 ：仕様書無しさん：2013/04/15(月) 10:20:19.00

>>195
設計型試験なのは分かってたことだと思うけど…

197 ：仕様書無しさん：2013/04/15(月) 10:59:41.60

>>194
そのｓ「手動テスト」って、ステップ実行のことじゃないと思うよ

198 ：仕様書無しさん：2013/04/15(月) 11:05:21.05

>>194
ホワイトボックステストを100% xUnitでやるのがお勧めでは無いというのはその通りだが、
だからといって、xUnit 0%、マニュアルテスト100%がお勧めなんてどこにも書かれてない
と思うが。

そもそも、ブラックボックス視点でxUnitでテストを書けば、ある程度のカバレッジは達成
できるはずで、そこに簡単にホワイトボックス視点を追加できるなら追加するのが良い。

そうすれば、リファクタリングの時にも、単体テストの時にも、リグレッションテストのときにも
使えるテストスィートになる。

そして、第三者(CIツールも第三者）も実行可能なテストになる。

199 ：仕様書無しさん：2013/04/15(月) 11:15:59.81

Javaの文法を覚えたからといって、良質なコードをすぐに書けるわけではないことは
万人が納得するところだろう。

しかし、なぜだかxUnitの場合は、使い方がわかった時点で良質なテストが書けると
勘違いする人が多い。
良質なテストが書けるようになるのは、段階がある。

例えば、このxUnit成熟度モデルで言えば、
http://d.hatena.ne.jp/cero-t/20111210/1323457069
レベル2まで進んで使えないと判断する人が多いように見受けられる。

そして、その人達は、なぜだか精力的にxUnitを卑下するのに必死になるような気がする。

200 ：仕様書無しさん：2013/04/15(月) 12:54:09.84

俺2かもしれん

201 ：仕様書無しさん：2013/04/15(月) 13:39:34.32

最近はdjUnitで全ステップがテスト対象になってるか確認するとかしないのか

202 ：仕様書無しさん：2013/04/15(月) 14:45:57.04

それただのカバレッジな気が

203 ：仕様書無しさん：2013/04/15(月) 14:48:51.67

>>195
俺用語を使って欲しくないからテスト関連の書籍を紹介したのに、さっそく俺用語使ってるな。
自分の言葉で説明するというのは、俺用語を発明することじゃないよ。

204 ：仕様書無しさん：2013/04/15(月) 15:15:58.75

>>195
> テスト駆動開発は設計型試験で、
> テスト駆動開発で作成したプログラムに対しても、
> 検証型試験が必要だとの事だ。
その通りなんだけど、TDDで書いたテストが単体テストで全く使えないとか思ってないよな？
TDDで書いたテストだけでは、単体テストで行うべきケースを網羅できてないから、
その足りない分は別途テストする必要があるってことだよ。

205 ：仕様書無しさん：2013/04/15(月) 16:23:04.42

>>199のリンク先を読んで、最低でも

> ・モックライブラリを使わずともモック化しやすいような設計・実装を浸透させる。
> ・継承ではなく委譲
> ・メンバ変数よりも引数
> ・ステートレス化
> ・protectedメンバ、protectedメソッドの活用

の段階まで、チームメンバ全員が到達して欲しいと思った。

xUnitが駄目だって言ってる人は、この辺のテスト容易性を全く考えないから使いづらいんじゃないかなぁ。

206 ：仕様書無しさん：2013/04/15(月) 18:44:43.51

テストコードもコードだからな。
コードの量が跳ね上がる。

やっぱりコード書きたくないんだよ。

207 ：仕様書無しさん：2013/04/15(月) 18:50:48.01

いや、やれよ

208 ：おじゃばさま：2013/04/15(月) 20:00:31.79

まずコード量の問題。単体試験レベルの項目を設計時に行うと、
コード量が増大し、修正時にはテストコードの修正も必要になる。
次にメンテナンスの問題。上で作成されたテストコードは、
他人が使用するのが非常に困難。
この2点はソフトウェアPressでも問題として繰り返し上がっている。
これはどうする？

209 ：おじゃばさま：2013/04/15(月) 20:10:51.80

ちなみに、テスト駆動開発におけるテストケースは、
『実践テスト駆動開発』によると、
必ずEnd to endで行えとある。
実際の例ではオークション自動入札ソフトを作るに当たり、
入札とかのレベルで作っている。
単体試験レベルではない。

210 ：おじゃばさま：2013/04/15(月) 20:20:52.60

ちなみに、テストの容易性の意味は、
『ソフトウェアテスト293の鉄則』によると、
可視化する事だとある。
つまり端的に言えば、ログを入れる事である。

211 ：仕様書無しさん：2013/04/15(月) 20:29:13.29

駄目だこいつ

212 ：仕様書無しさん：2013/04/15(月) 20:35:31.86

function test() {
ans = add(2, 3);
assertEquals(5, ans);
}
のどこがわかりづらいんだろうか。

213 ：おじゃばさま：2013/04/15(月) 20:51:33.31

『実践テスト駆動開発』を読む限り、
テスト駆動開発は実務には使えない。
驚きの開発手法だ。
まず、要求仕様からホワイトボードに簡易モデル図を書く。
次にサーバも含めた開発環境を構築する。
次に経験とカンでインタフェースを決めて、
空の本体を作る。
インタフェースに従い、エラーになるテストケースコードを作る。
この本体にコードを追加し、テストケースが
正常になるようにする。
モジュール分割とエラー処理実装は、経験とカンで行う。
上記方法は完璧でないので、自分がいいと思う事を取り入れる事。

これ新人に教えるのか？

214 ：仕様書無しさん：2013/04/15(月) 21:18:55.08

>>213
新人やお前にはできないよ。

215 ：仕様書無しさん：2013/04/15(月) 21:42:15.63

ずっと継続開発を受注できるなら必要だけど
作って終わりならテストコードなんていらんよ

216 ：おじゃばさま：2013/04/15(月) 21:51:41.68

>>212
実際保守されてないし、無理だろう。
『ソフトウェアテスト293の鉄則』
にはもっと簡単なスクリプトでも、
保守は難しいとあるぞ。

>>214
じゃ、無理じゃね？

217 ：仕様書無しさん：2013/04/15(月) 22:16:42.29

TDD中心でやるのに慣れてると、このスレ笑ってしまう
いや、失笑か…

218 ：おじゃばさま：2013/04/15(月) 22:28:26.45

>>217
それは単体試験やってないのを、
テスト駆動開発だと言っているだけだろう。

219 ：仕様書無しさん：2013/04/15(月) 22:49:09.36

>213
また君の悪い癖が出てるよ。

TDDがどのようなものかがわかっても、TDDで上手く開発することなんてできない。
xUnitしかり。
Javaしかりだ。

実践してみて計面を積み、人それぞれの気付きを得ながらプロセスを改善してみないと、意味があるかどうかなんてわからない。
もちろんTDDは君に合わない可能性がある。いやその可能性は大きいだろう。
だが、君に合わないからといって、誰にも意味のないプロセスかどうかは別問題だ。

220 ：仕様書無しさん：2013/04/15(月) 22:53:15.02

>>216
>>212のどこが保守不能なのだろうか。
因みに、変更がない部分は保守せずとも良い。
実行さえ出来ればいいんだ。それがリグレッションテスト。

221 ：仕様書無しさん：2013/04/15(月) 23:10:59.56

TDDこそ、できる奴しか道具としては使えないね。
万人向けのものじゃない。

222 ：仕様書無しさん：2013/04/16(火) 01:40:42.25

>>210
テスト容易性とは、文言通りテストのしやすさのことで、ISO9126にもTestabilityとして定義されている。
何が容易なのかというと、テストを実行することが容易であることと、テスト結果の判定が容易であること。
どちらも自動化されていることが望ましい。
テストを実行してログが出力されても、テスト結果を人が目視で判定するなら、それは容易とは言えない。
その出力されたログを自動判定してくれる仕組みがあるなら、容易と言える。

223 ：仕様書無しさん：2013/04/16(火) 01:42:19.22

そして、テストを自動化するにあたり、ターゲットコードがテストしやすい仕組みになってなければならない。
DIの概念は、その最たるものだね。

224 ：仕様書無しさん：2013/04/16(火) 02:23:34.90

テストコードが保守ないってのは、テストを軽視し過ぎだよ。
リリースサイクル考えてる？

ステップ実行はデバッグであってテストじゃないし、
可視化っていうのは、本人だけ判るものを言うんじゃない。

もしかしてディベートの練習のつもりなんだろうか。

225 ：仕様書無しさん：2013/04/16(火) 02:27:28.13

TDDはクラスとかの設計能力とかがある程度ないと無理だと思うよ
ある程度の完成形が見えるレベルの人じゃないと取っ掛かる事ができないと思う
先にたたき台を作って…って工程を経て本実装に行くようなことしてるようだと、TDD無理

226 ：仕様書無しさん：2013/04/16(火) 02:30:09.75

>>224
アサートで済むことを一々目視確認とか死ねばいいとか言うツッコミは置いておいて、
アサート項目のリストを別に用意してアサートの代わりに目視確認すれば、ステップ実行もテストになる

227 ：仕様書無しさん：2013/04/16(火) 02:32:13.42

テストコードの保守が出来ないってのは、その開発チーム全体のスキルレベルが低く、
保守できないレベルの低いテストコードやテスト対象クラスの設計をしてる事が原因だって事、
そろそろ理解できないとちょっとヤバイんじゃないかおじゃば。
単体テストツールや単体テスト手法に問題があって保守できないコードが出来ると本気で思ってるなら、あたまおかしい。

228 ：おじゃばさま：2013/04/16(火) 08:32:54.28

>>219
いや、これからコードを書く人に勧める事ではないだろう。
何で普通の単体試験を勧めない？
ホワイトボックス、ブラックボックスの試験項目表を作って、デバッガで確認。
ブラックボックス内でリグレッションに使えるやつは、JUnitを使用。
まずこれが基本だろう。
実務では試験項目表やバグ票、試験結果報告書も提出物だし、
項目数出して試験のスケジュール管理もするのだから。

229 ：おじゃばさま：2013/04/16(火) 08:52:27.65

>>222
例えば、GUIの表示確認。
ウィンドウの位置や状態によっても変わるし、色の判定なども困難。
手動の物を出来るだけ自動にするのではなく、
自動に適している物を自動化する。
自動化に適しているのは、繰り返し確認する必要がある物や、
手動操作が不可能だったり、膨大な手間がかかるもの。
293の鉄則にも書いてある。
ちなみに293の鉄則では、ツールの教育コストやツールのバグ問題まで言及している。

230 ：おじゃばさま：2013/04/16(火) 09:00:30.79

>>223
新規でゼロから作る事は少ない。
テストのために基本設計を変えるなんて現実的でない。
テストで使うツールはどんなコードにも使用出来る物でなければならない。

231 ：仕様書無しさん：2013/04/16(火) 09:10:59.95

おじゃばはassertとか知らなさそう

232 ：おじゃばさま：2013/04/16(火) 09:18:19.49

>>227
メンテナンス出来ないのは人の問題だか、
実際問題としてメンテナンス出来る人をずっと残せないだろう。

233 ：仕様書無しさん：2013/04/16(火) 09:58:23.06

>>232
お金の問題です

234 ：仕様書無しさん：2013/04/16(火) 10:37:06.59

>>228
> いや、これからコードを書く人に勧める事ではないだろう。

このスレでは、誰もTDDをできない人には勧めてないけど。

> 何で普通の単体試験を勧めない？

その「普通の単体試験」を、100%ステップ実行から卒業して、自動テストを取り入れましょうということなんだが。

> ホワイトボックス、ブラックボックスの試験項目表を作って、デバッガで確認。

もちろん、個々人がデバッガで動作を確認するのは自由で、それをするなとは言っていない。

> ブラックボックス内でリグレッションに使えるやつは、JUnitを使用。
> まずこれが基本だろう。

やっとそこまで来たか。

> 実務では試験項目表やバグ票、試験結果報告書も提出物だし、
> 項目数出して試験のスケジュール管理もするのだから。

バグ票を作成しないとは誰も言ってないよ。まあ普通はBTS使うけど。
「試験結果報告書」も、クライアントに求められれば作るよ。
スケジュール管理もするさ。しないとでも思った？

235 ：仕様書無しさん：2013/04/16(火) 10:39:52.58

>>229
> 自動に適している物を自動化する。

君の書き込みを見てると、自動化に適しているものまでステップ実行で確認してるようなのでみんな反応してるんだが。

> ちなみに293の鉄則では、ツールの教育コストやツールのバグ問題まで言及している。

だからさ、何でそれを誰も考慮してないなんて思うんだよ。
そんなことみんなちゃんと考えてるって。

236 ：仕様書無しさん：2013/04/16(火) 10:41:46.03

>>230
> 新規でゼロから作る事は少ない。

まず、新規でゼロから作る事が少ないなら、自動化されたテストの存在は多大なるメリットがあるよね。
そして、君の所では新規でゼロから作る事は少ないのかもしれないけど、他の人もそうだとは思わないように。

237 ：仕様書無しさん：2013/04/16(火) 10:46:53.49

>>228
項目数を出せば、テストの工数が算出できると思ったり、それでスケジュール管理できると思うところがド素人なんだよ。

238 ：仕様書無しさん：2013/04/16(火) 10:52:57.68

>>229
> 293の鉄則にも書いてある。
自説を補強する材料を見つけるために読書するからお前は駄目なんだよ

239 ：仕様書無しさん：2013/04/16(火) 10:59:14.42

>>232
メンテナンスできない人を残せないのであれば、自動化されたテストの有用性は高まる。
メンテナンスはできないが、実行はできるだろうから。

240 ：仕様書無しさん：2013/04/16(火) 14:35:11.14

>>232
『テストコードをメンテナンス出来る人間を残せない。』と、いうことは、
被テスト対象のコードをメンテナンス出来る人を残せないということ。

入出力の仕様がわからないのに、プロダクトコードのメンテやるの?

241 ：仕様書無しさん：2013/04/16(火) 20:01:44.54

おじゃば支離滅裂

242 ：おじゃばさま：2013/04/16(火) 20:34:50.06

>>234
単体試験やってないのだろう？
少なくともホワイトボックスはやってない。
発言を見ると、それなら納得いく。

>>235
誰かが、デバッガのステップ実行なんて使わないとか言っていたぞ。
ホワイトボックス試験もJUnitとか言っていたが、自動化向きじゃないな。

>>237
では何で管理する？

>>240
作った人は残せないという意味。

243 ：おじゃばさま：2013/04/16(火) 20:41:39.81

結局、単体試験の全てをJUnitでやった場合の、
コード増大とメンテナンスの問題をどうする？
コード増大はツールと根性でカバーし、
メンテナンスは優秀な人てカバーとか言ってる？

244 ：仕様書無しさん：2013/04/16(火) 20:45:10.08

テストコードもメインのコードも自分がわかっていることを書くというところは同じ。
どちらも間違いはあり得る。

245 ：仕様書無しさん：2013/04/16(火) 22:04:34.56

>>243
JUnitをなくせば解決できる。
コードをなくして人力でやれば
コード増大とメンテナンスの問題が無くなる。

あとは、人力テストをしなければ、
テストにかかる工数は0だ。

246 ：仕様書無しさん：2013/04/16(火) 23:11:00.91

やっとわかった。
おじゃばはホワイトボックステストが何なのか良くわかってない。

247 ：仕様書無しさん：2013/04/16(火) 23:12:47.96

>>245
テストもしなくて済むなんてすげえな(棒)

248 ：仕様書無しさん：2013/04/16(火) 23:18:08.65

>>243
普通はコードでテストしやすい所だけコードでテストする。
テストしづらいところはマニュアルだよ。
ただし、テストしやすい部分がお前の想像以上だけどね。

結局お前はテスト容易性も考えてない糞設計のコードに、稚拙なテストコードを量産した
計面しかないから、メンテナンス工数がーとしか言えないんだよ。

俺からしたら、仕様変更や仕様追加、バグフィックスで、何度も同じテストをマニュアルでやる
ほうがよっぽど工数かかると思うが。

249 ：仕様書無しさん：2013/04/16(火) 23:22:58.16

何度も言うが、テストドシロウトが初めてxUnitで何もわからずテストコードを書けば、
そりゃめちゃくちゃ工数がかかって、結果メンテ不能な糞テストコードしか残らない
かもしれない。

でもそれは、スキルと経験が足りてないだけ。

プロダクトコードだって同じだろ？
プログラミングセンスのない奴が、覚えたての言語でなんとか書き上げたコードは糞コードで
メンテもままならないものにならないか？

250 ：仕様書無しさん：2013/04/16(火) 23:29:20.10

そもそもステップ実行だとカバレッジツールと相性悪いだろ。
おじゃばの所はカバレッジツール使ってないのか？

251 ：仕様書無しさん：2013/04/16(火) 23:36:55.19

カバレッジツールも知らなそうで

252 ：仕様書無しさん：2013/04/16(火) 23:37:34.60

みんな親切だなあ。
おじゃばがステップ実行がいいって言ってるんだからやらせとけよ。
俺らにはおじゃばがどういう開発してようと関係ないし。
勘違いもそのまま勘違いさせとけよ。見てて面白いじゃん。

253 ：仕様書無しさん：2013/04/16(火) 23:45:31.98

>>250
印刷したソースコードにラインマーカーで線を引いてそうな悪寒。

254 ：仕様書無しさん：2013/04/17(水) 01:43:13.10

>>232
引継ぎできないような成果物を生み出してるような程度の低い職場なのか、可哀想に

255 ：仕様書無しさん：2013/04/17(水) 01:55:37.78

>>252
いや、ひたすらレベル低い中身のない話続けてるだけじゃん
いつまでも続けられても面白くない話題が続くだけだし、さっさと退散して欲しい

つか、糞コテの話はもういいから、これからコードを書く人向けの話題なんかないかなー

256 ：仕様書無しさん：2013/04/17(水) 02:39:05.46

え、あれでしよ
テストを丁寧に(笑)

257 ：仕様書無しさん：2013/04/17(水) 04:55:09.85

プログラミングセンスのない奴でも
Python使えばインデントがきれいになって
だれでも同じようなコードを書けるよ。
素人でもプロと同じコードを書けるよ。
インデントの力ってすごいね。

258 ：仕様書無しさん：2013/04/17(水) 05:04:42.83

よかったね

259 ：おじゃばさま：2013/04/17(水) 08:16:27.86

>>248
仕様変更、使用追加、バグ修正でテストするだろう。
JUnit使っても単体試験レベルで作っていれば、
テストコードも作り直しのははずだ。
仕様変更してもテストコードをそのまま使えるなら、
それは単体試験レベルでないし、
修正コード以外の単体試験レベルのテストが必要と言うなら、
それこそ設計の問題だろう。

>>249
その通りだ。
だから「これからコードを書く人」に、
手動はやめて全て自動化とか言うのはおかしい。

>>250
使ったがその条件で通ったか分からないし、
個別のケースで見るならデバッガのほうが便利だから、
提出物用にしか使わなかった。

>>254
単体試験項目表は基本的に使い捨てで、
変更があった追加する物だよ。
たから保守不要なんだよ。
何故そうしているか分かるか？

260 ：仕様書無しさん：2013/04/17(水) 08:17:33.93

ステップ実行でテストって、そもそもステップ実行できるIDEが無い言語はテスト不能ってことですか。

261 ：おじゃばさま：2013/04/17(水) 08:24:24.37

>>260
IDEなくても大抵はステップ実行出来るデバッガがある。
どうしてもない場合は、デバックログを入れる。

262 ：249：2013/04/17(水) 08:26:28.99

全然おかしくない。
誰でも最初は初心者で、その初心者の視点では評価は難しい。
やり始めなければ永遠に初心者のままだ。
そして、xUnitは初心者が手におえないほど難しいものではない。
誰でも始められる。ただ、良いテストコードを書ける所まで到達するかどうかはわからない。

xUnitの使用は、設計に好影響を与える。
その意味でも、初心者にも薦められる。

263 ：おじゃばさま：2013/04/17(水) 08:27:45.91

何で俺が「これからコードを書く人」に、
単体試験項目表を書いて、ステップ実行でテストしろと言っているか、
分からないか？

264 ：249：2013/04/17(水) 08:29:24.32

>>259
修正コード以外に影響が出ていないかを確認するテストをリグレッションテストと言うのだ。
リグレッションテストはやらないのか？

265 ：おじゃばさま：2013/04/17(水) 08:31:16.42

>>262
確認だか、ホワイトボックスもJUnitでやれと言ってる？

266 ：249：2013/04/17(水) 08:32:11.97

>>263
私何歳に見える的な言い方は、レスの往復分無駄だから、言いたいことがあるならそのレスで明言しろ。

267 ：おじゃばさま：2013/04/17(水) 08:33:23.60

>>264
回帰テストは結合試験レベルの試験だ。

268 ：249：2013/04/17(水) 08:37:33.55

>>265
ホワイトボックスとブラックボックスは、単に視点の違いにすぎない。
やるのはユニットテストで、それ以上でも以下でもない。
ブラックボックス視点で書いたテストと同じ枠組みでホワイトボックス視点のテストケースも
実装できるならやる。

269 ：おじゃばさま：2013/04/17(水) 08:37:51.34

>>266
ホワイトボックスの試験項目表を作る事で、
処理矛盾や不要な処理等がわかる。
ステップ実行する事で、実際の動作イメージがつかめる。

270 ：249：2013/04/17(水) 08:38:49.90

>>267
お前がそう思っているだけだ。
リグレッションテストはいつやっても問題ないし、早く実行できるならそうした方がいい。

271 ：249：2013/04/17(水) 08:41:35.57

>>269
処理矛盾や不要な処理がわからない程の低スキルな人間は何をやっても駄目だ。
其ほどの低スキルな人間が、きちんとしたテスト設計ができるとは思えない。

272 ：249：2013/04/17(水) 08:43:57.07

xUnitでプロセスを回したことが無いから、テストコードの修正工数の規模感がわからないんだろう。
お前が思っているほど修正工数はたいしたことない。

273 ：おじゃばさま：2013/04/17(水) 08:47:59.58

>>270
回帰テストは単体試験後に一回やればいい。

>>271
君だってやればみつかるよ。

274 ：249：2013/04/17(水) 08:54:03.13

>>273
頻繁にテストを実行出来ないから、そんな考え方から抜け出せないんだろう。
なん行か修正後、1秒でそのクラスの100個のテストが実行できるなら、その考えも変わるだろう。
これもリグレッションテストだ。

275 ：仕様書無しさん：2013/04/17(水) 08:58:48.74

伸びてると思ったらコテハン二人に増えてた
ID制にならんかなこの板

276 ：仕様書無しさん：2013/04/17(水) 10:01:15.96

だからおじゃばを説得しようなんて無駄だって。
どんだけ同じ事ループさせれば気が済むんだ。

277 ：249：2013/04/17(水) 10:12:15.19

悪い。つい反応したくなってしまう。
おじゃばさまをNGに登録したから、もう反応はしない。

278 ：仕様書無しさん：2013/04/17(水) 14:16:42.55

テストが整ってる前提で、
リファクタリングの話に広げたい

279 ：仕様書無しさん：2013/04/17(水) 14:47:41.09

開発プロセスの改善を放棄した段階で老害なんだ。
これから先のある連中の足を引っ張りたがるなよ……

280 ：仕様書無しさん：2013/04/17(水) 17:17:19.69

言ってることが新しい理解できないモノを拒否してるだけでまともな論拠が無い
staticじじい並にゴミ
マジで老害

281 ：仕様書無しさん：2013/04/17(水) 18:20:12.58

なんだか、ホワイトボックステストだとテストケースが滅茶苦茶増えるような発言してるけど、
減る場合だって多いんだからね。

例えば、get_file_contents(fileName)というメソッドがあったとき、open/close/readを提供する
URIクラスがあってそれに完全に委譲してれば、ホワイトボックステストでは異なるfile schemeは
同値と見なしてテストしなくていい。

ブラックボックステストなら、"./abc.txt"とか"file:///abc.txt"とか"http://hoge/abc.txt"とかを
テストしなきゃならない。それがテスト対象クラス内部で同じ位置づけなのかどうかわからないから。

282 ：おじゃばさま：2013/04/17(水) 21:42:32.54

>>272
昔JUnitが日本に入ってきた頃に、人柱として実務で使わされた。
コーディング後に単体試験レベルでテストコードを作ったが、
結合試験に入ってひどい目に会った。
バグ修正でもテストコードを見直さなけれはならないし、
自分の作った所のテストコードも見なければならない。
他人の所などは最初から動かないのか、環境なのか、
修正の為なのか分からない。
少人数のプロジェクトだからどうにかしたが、
大人数でやると思うと身の毛がよだつ。

>>274
何で回帰テスト毎回やるの？
ムダだろ。

>>281
ホワイトボックス試験と言うのは、制御文の数に左右され、
端的に言えばif文で2件、for文で3件増えるのだが、
影響するのか？

283 ：おじゃばさま：2013/04/17(水) 21:46:19.35

結局、単体試験にJUnit使ってもそんなにコードは増えないから、
修正は大した事ないって言ってんの？

284 ：仕様書無しさん：2013/04/17(水) 22:43:48.54

JUnitの話しなんだから
単体テストの話をしようぜ。
おじゃまがいってるのは
単体テストではない。

285 ：おじゃばさま：2013/04/17(水) 23:42:04.82

俺：単体試験＝ルート試験＋入出力試験＋メッセージ試験
君達：単体試験＝入出力試験
と言う事かな。
まあ、単体試験は社外秘になってる事が多く、
雑誌にもあまり出ないから、知らないのかな？
でもNの最も厳しい所は、俺のがルート試験＋入出力試験＋メッセージ試験の3種類に対して、
内容は忘れたが7種類あるからな。
気をつけろ。

286 ：仕様書無しさん：2013/04/17(水) 23:50:31.41

ルート試験＋入出力試験＋メッセージ試験
なんて言葉が出てくる時点でおかしいんだよな。

JUnitにおける単体とは、
一つのクラスのこと。

287 ：仕様書無しさん：2013/04/18(木) 00:25:13.90

経験不足、知識不足でユニットテスト全否定してる様はstaticおっさんと同じレベルだな
っていうか本人なの？

288 ：仕様書無しさん：2013/04/18(木) 00:29:50.30

おじゃばの井の中の蛙っぷりが酷い
何年業界やってんのか知らんが、視野広げて勉強してこなかったツケが回ってきてるんだろうな
自分の経験した職場でのローカルルールや慣習がどこでも通用すると思ってそう
うちの職場にもにたような(更にレベル低いけど)オッサン何人かいるから、なんともいえない気分になるわ…

これからコードを書く仕事に就くような人は、こうならないように仕事以外での勉強を怠らないようにしたほうがいいよ

289 ：仕様書無しさん：2013/04/18(木) 00:36:38.42

>>286
JUnitにおけるっていうか、一般的な意味でのユニットテスト(単体試験)は基本的にその単位だよ

それ以外の意味で使われてる場合は、職場毎に内容が異なるから、一般的ではない
こういう場所で話に出すときはきちんと詳細を説明しないと齟齬が出るから、普通はそういう使い方しないと思う
外部(基本)設計、内部(詳細)設計、とかと同じ感じ

290 ：仕様書無しさん：2013/04/18(木) 00:44:24.75

どこでそんなアホな知識仕入れたのかと、
"ルート試験" "入出力試験" "メッセージ試験"
でググったら、ヒット1件。このスレwww

291 ：仕様書無しさん：2013/04/18(木) 00:47:29.03

これからコードを書く人に絶対やってほしい事
結論を他人に頼るな、誰かが言った言葉をそのまま鵜呑みにするな
言われた情報も参考に加えつつ、自分で調べ、試してから、自分の信じれる結論を導き出せ
そうやって調べ試したことは後々まで役に立つ

言われたことだけやるような人間のままじゃ、30くらいで頭打ちだ

292 ：仕様書無しさん：2013/04/18(木) 00:55:40.34

ダミーメインとか書く暇があったら、なんでそこをJUnitで書かないのかねぇ。
JUnitで書けば、ビルドツールやCIツール、デプロイツールとも親和性高いのに。
それにexceptionが発生してもテストは止まらないし、テストメソッドは独立して実行される。
また、少々assertionが少なくてもカバレッジツールがちゃんと使えるようになるのに。

293 ：仕様書無しさん：2013/04/18(木) 01:03:24.65

JUnitだとメンテナンスできないのにダミーメインだとメンテナンスできるのか。

294 ：仕様書無しさん：2013/04/18(木) 01:13:20.94

釣りスキルだけは認める

295 ：仕様書無しさん：2013/04/18(木) 01:21:50.26

UTコードのメンテナンスできないのは、ユニットテストツールの問題じゃなくてそれを使った人間のバグだと思う。
理解する前に投げちゃった人じゃ多分今後も使うの無理なんじゃないのｗ

これだけじゃあれだから、これからコードを書く人に絶対やってほしい事でも。

ソース管理使おう。
これからはGitが主流になってくから、触ったことないならまずこれを使ってみるといいと思う。
国内じゃまだSVN(Subversion)使ってるとこも少なくないけど、今もどんどん廃れて行ってるし
集中管理型のSVNなら分散管理のGitよりも単純なので覚えるのは楽なので、必要になってから覚えれば十分。

ttp://git-scm.com/book/ja
ここ読むだけでだいたいの事は覚えれる。
初めてソース管理に触る人にはちょっと難しい部分も多いけど、わからないことはぐぐれば解決するはず。

コマンドで解説してる情報の方が多いから、コマンドラインでの操作も一通り目を通しておいたほうが良い。
どういうコマンドがあって、それがどういう事をやるのかを知っておくと、GUIツールの動作が簡単に理解できる。

GUIツールは、GitExtensions、TortoiseGit、EclipseプラグインのEGitあたりが俺のオススメ。
マージ、DiffツールはWinMargeが使いやすいと思ってる。

296 ：仕様書無しさん：2013/04/18(木) 01:24:01.20

ドザかよ

297 ：仕様書無しさん：2013/04/18(木) 02:17:15.71

開発機がWindowsで実行機がLinuxとか珍しい話でもないと思うが。

298 ：仕様書無しさん：2013/04/18(木) 03:45:34.34

おじゃばとは住んでた世界が違うようだ
向こうの世界は大変そうだ…

299 ：おじゃばさま：2013/04/18(木) 08:18:46.93

>>288
単体試験は企業によって少しずつ内容が異なる。
大手なら単体試験実施要項と言うのがあって、
試験観点が書かれているから、見てみるといい。

ちなみに、JUnitで入出力試験だけやって、
単体試験完了にする所があるのも知っている。
結局、結合試験や総合試験で問題が出て、
通常の単体試験やるより、数倍のコストがかかったりしてる。

300 ：おじゃばさま：2013/04/18(木) 08:27:41.73

>>298
多分、大変なのは君達だと思う。
単体試験で手を抜いても、後の工程で数倍の苦労をするだけだからな。

301 ：仕様書無しさん：2013/04/18(木) 10:11:59.44

>>300
>単体試験で手を抜いても、
だめだ、こいつの言ってることが分からん

302 ：仕様書無しさん：2013/04/18(木) 12:49:22.45

>単体試験実施要項
ああ
あの下手なギャグ漫画より笑えるドキュメントね

303 ：仕様書無しさん：2013/04/18(木) 13:27:40.31

>>299
> 大手なら単体試験実施要項と言うのがあって、
> 試験観点が書かれているから、見てみるといい。

ほんと重症だわ。
自分以外は、このスレの誰もその類いの資料を見たことが無いという思い込み。

その単体試験実施要項は、孫、曾孫受けくらいの玉石混淆のプログラマ達でも
なんとか品質を担保できるようにするための、要するに低レベル向けの奴だよ。

304 ：仕様書無しさん：2013/04/18(木) 13:30:45.67

NってNECのことだと思うが、さもその単体試験実施要項に「ステップ実行で確認すること」と
書かれてるような発言をするのって、何か法律に引っかかったりしないのか？

305 ：仕様書無しさん：2013/04/18(木) 13:46:28.17

ヲレJUnit使うようになってから、デグレも皆無だし
そもそも結合でしょうもないバグも出なくなったけどなぁ。

紙書いてブレークポイントはったりしてなんて世界にはもう戻れないよ。
作業効率も品質も違う。

306 ：仕様書無しさん：2013/04/18(木) 14:10:05.94

Javaのことよく知らないけど、Javaってビルドして*.jar作るんだよね。
その中のMain()は一個だけ？

だとしたら、テストの種類毎にダミーメインを作ってたりしたら、何十何百の*.jarが必要なるってことか？

307 ：仕様書無しさん：2013/04/18(木) 16:55:45.84

>>306
おじゃばさん名前忘れてるよ

308 ：仕様書無しさん：2013/04/18(木) 17:30:13.77

１つのjarにmainメソッド持ってるクラスを複数入れてもいい。
起動時にjarだけじゃなくてクラス名も指定すれば、
希望するクラスのmainメソッドを呼び出せる。

IDE使ってると、jar作るって意識がないから、ダミーのメインを
いっぱい作ってもjarにはしてないと思うけど。

309 ：仕様書無しさん：2013/04/18(木) 18:21:45.80

なるほど

310 ：仕様書無しさん：2013/04/18(木) 19:52:15.09

ほうほう

311 ：仕様書無しさん：2013/04/18(木) 20:48:19.30

●じゃあのさん新人公演●
開演時間未定

231:以下、名無しにかわりましてVIPがお送りします[sage]
2013/04/18(木) 16:08:20.57 ID:1BeWLVki0
グッドアフタヌーンおまいらｗｗｗｗｗ

なんかよぉ、パンダデモに妨害めいた嫌がらせがあったらしいんだわｗｗｗｗｗ
ものすごく間抜けな嫌がらせなんだけどなｗｗｗｗ

今晩それの詳細を落としに来るわ。じゃあのｗｗｗ

--- 以下スレ情報 ---
高岡さんがフジ韓流ゴリ押し批判したら干されたのでウジテレビ凸
http://hayabusa.2ch.net/test/read.cgi/news4vip/1366222344/

312 ：おじゃばさま：2013/04/18(木) 20:52:07.50

>>303
確かに細かすぎるから、慣例に従って無視される事も多いが、
一応読んで、突っ込まれた時の対処はしておいた方がいい。
それに真面目に読めば参考になることもあるからな。
ちなみに、レベルは関係なく基本的には従わなければならないからな。
低レベル向けの仕様書なんてないよ。

313 ：仕様書無しさん：2013/04/18(木) 20:52:57.13

>>299
企業によって用語のニュアンスが異なる事は知ってるし、このスレで話題振ってる人も分かってるだろう。
しかし、そういう異なるって事を知っているのであれば、ローカルな用語をさも一般的なもののような言い回しはしない。
だから井の中の蛙だと言ったまでだ。ちゃんと読み取ることも出来ないのか。

つか、事あるごとに「大手なら～」ってｱｯﾋﾟﾙを繰り返してるのは、自分はすごいって主張をしたいという気持ちの表れ？
大手だから正義だって思ってるようなら、やっぱ海を知らない蛙でしかないわ。

つか、知ってる知ってないじゃなくて、JUnitや(一般的な意味での)単体テスト手法に対する知識もろくにないのに、
自動テストは保守できないだの、ステップ実行が最良のテストだのみたいな事ばっか言ってるから、
頭おかしいって非難されてること、まだ気付いてないの？staticハゲなの？

>>304
NTTの事をNと略したりする所もあるで。
まぁそういうのをこんなとこで主張するあたり、リテラシーの低いとこに所属してるってことだろう。
普通は伏せてもこんな場所にエンドの名前を挙げる様なガキみたいなことはしないし。

314 ：おじゃばさま：2013/04/18(木) 20:55:06.98

>>305
マジで？！
そりゃ、スゲー！
聞いたか、みんな。

315 ：仕様書無しさん：2013/04/18(木) 21:04:46.90

>聞いたか、みんな。

すごいのか?
いや、このスレの大半はそっちの世界の住人だろ……

316 ：仕様書無しさん：2013/04/18(木) 21:11:21.91

気になる奴はNGつっこんどけ、昔からいる頭のおかしい糞コテだからな
ただのキチコテだから言いくるめようとかするだけ無駄だぞ
得るものないし触れるだけ時間の無駄

317 ：おじゃばさま：2013/04/18(木) 21:16:47.23

>>313
つーかさ、コード増大と保守の具体的な対策が、
全然出て来ないのだが。

318 ：仕様書無しさん：2013/04/18(木) 21:59:02.90

JUnitだとメンテ不能でダミーメインだとメンテできるのは何で？

319 ：仕様書無しさん：2013/04/18(木) 22:34:02.06

コードが書けない低能でも可能な
数少ない開発関係の作業が
試験項目表 + デバッガ目視テストなんだよ

ただでさえ仕事が無い低能（おじゃば含む）から
仕事を奪ってるんだから、おじゃばがxUnitを憎むのも分かるよ
仕事奪われる側は何時だって技術革新を憎むもんだよ

320 ：仕様書無しさん：2013/04/18(木) 22:53:01.52

「単体テスト」の意味が各社で違うから、
JUnitでいうユニットテストの定義で話せといったんだよ。

321 ：仕様書無しさん：2013/04/18(木) 22:56:22.44

>>318
そもそもメンテしてないし再テストもしない使い捨てなんでしょ
既存コードは触るなみたいなお達しの出る職場だと思うｗ

322 ：仕様書無しさん：2013/04/18(木) 23:06:23.30

テストをしてないのにしたと嘘を付けばいい。
キャプチャ画像なんて、修正前の画像を使えばいい。

そうすれば、どんな大変なテストも
かなりの工数が減らせる。

323 ：仕様書無しさん：2013/04/18(木) 23:15:59.34

>>321
ソース修正するときは、申請してソース払い出してもらうんですね。
わかりますん。

324 ：仕様書無しさん：2013/04/19(金) 01:59:41.51

>>305
JUnitじゃないけど昔テストツール導入しようとしたとき
上司に「そのツールが正しく動いてることをどう説明できるんだ？」と言われ
不採用になって目視確認作業に戻った
人間の目のほうがよほど信用ならないと思うけどな

325 ：仕様書無しさん：2013/04/19(金) 02:55:42.83

ソースは触るな修正はするなバグは取り除け

どーしろと

326 ：仕様書無しさん：2013/04/19(金) 02:57:56.83

仕様書にそれを仕様として書き加えて運用で回避

327 ：おじゃばさま：2013/04/19(金) 08:13:47.87

>>319
妄想乙としか言えないな。

>>322
それはダメだな。
バグが出まくって、大変な工数になる。

>>324
検証して結果を見せればいい。

>>325
よく分からんが、修正が必要なら修正するし、必要なけれは修正しない。
自動化しても修正箇所の試験が不要になる訳ではないだろう。

>>326
仕様書は普通は客の許可がないと修正出来ないから難しいな。

328 ：仕様書無しさん：2013/04/19(金) 13:52:39.09

>>324
そんなの言い出したら言語仕様もコンパイラもCPUそのものも疑っていかないと

329 ：仕様書無しさん：2013/04/19(金) 14:46:08.45

>>325
観測されない事象は存在しない。

330 ：仕様書無しさん：2013/04/20(土) 01:33:56.60

汎用的な難しい処理は殆どライブラリとかあるし、研究するのはいいが再発明するのは時間の無駄
これからの時代、複雑なロジックよりも、保守しやすい簡単な処理を、綺麗に組み合わせていくスキルが重要
フレームワークとかツールとかの仕組みをきちんと勉強することは欠かさずやって欲しいな

職場の老害連中は勉強不足なのを棚に上げてフレームワークわからないと文句言い続けててマジでアレ
DIできるのに全部自分でnewしようとするし、UTは実装しないというか理解すらしてない
そしてスパゲッティを生み出してデグレを頻発しながら、程度の低いクローンコードを沢山作ってる

これからコードを書く人は、こうはなっちゃダメだぞ

331 ：仕様書無しさん：2013/04/20(土) 02:03:54.88

下ばっかみてんのな？オマエ

332 ：仕様書無しさん：2013/04/20(土) 02:11:09.95

>これからの時代、複雑なロジックよりも、保守しやすい簡単な処理を、綺麗に組み合わせていく
なんかΣプロジェクトを連想したわ

333 ：仕様書無しさん：2013/04/20(土) 02:44:05.65

なんぞそれ

334 ：仕様書無しさん：2013/04/20(土) 03:07:25.02

Σぷろじぇくと...

335 ：仕様書無しさん：2013/04/20(土) 04:06:38.48

>>333
国内の情報技術レベルを国が支援して高めようってことで始まって大ゴケした大規模プロジェクト

初期の提言の技術者同士の情報交換や再発明の防止などを出来る文化や場所を作ろう的な話が曲解され、
ソフトウェアを部品化を集積し組み合わせで全ソフトウェアを賄いコストを下げる(プログラマ不要論)的な話となり、
最終的に用途も互換性もない専用コンピュータの開発などで大量の税金を大手メーカが浪費して中断・消滅、
その後ΣプロジェクトはIT業界において禁句的な扱いとなった・・・

とかなんとか

336 ：仕様書無しさん：2013/04/20(土) 05:01:20.95

この業界でも知らんヤツ居るんだな…

337 ：仕様書無しさん：2013/04/20(土) 05:02:46.40

金のことしか考えてないじじいどもに食い物にされて速攻でぽしゃった糞プロジェクトな

338 ：おじゃばさま：2013/04/20(土) 07:09:02.18

>>330
DIの利点が実感できません。

339 ：仕様書無しさん：2013/04/20(土) 08:48:07.05

一生糞コード書いてステップ実行してろ

340 ：おじゃばさま：2013/04/20(土) 10:40:39.16

>>339
DI出来るのにnewするの意味がよく分からんが、
全クラスDIにするって言ってんの？

341 ：仕様書無しさん：2013/04/20(土) 10:53:39.78

>>340
ケースバイケースに決まってるだろ。
何でいきなり全部とか言い出すんだよ。全部なわけないじゃん。

342 ：おじゃばさま：2013/04/20(土) 11:09:51.78

そのDIにする単位については説明しないのか？

343 ：仕様書無しさん：2013/04/20(土) 11:27:40.08

>>335
Σプロジェクトの考え方でダメだったことの一つは
ソフトウェアにとっての部品が何か、そしてプログラマの仕事が
部品を作っていることだけだと思っていたから。

ソフトウェアを部品化することはできても、
その部品というのはユーザーが求める機能（○○編集画面等）ではなくて
もっと小さな部品（データベースへの保存メソッド）

そしてその部品は共通部品（汎用ライブラリ等）と
専用部品（プロジェクトごとの部品）に別れる。
汎用ライブラリだけではプログラムはできない。

電子機器だって、部品とは別に部品同士をつなぐものがある。部品は置くのではなくて使うもの。
部品も作るが部品を使って機能を作るのがプログラマが普段やってることなわけで。

そこを見誤ったのがΣプロジェクト。

小さい部品に分割するってこと自体は間違いじゃないよ。

344 ：仕様書無しさん：2013/04/20(土) 11:28:32.53

>>342
DIにする単位ってなんだ？
単位はDIを使わない場合と一緒だろ？

345 ：仕様書無しさん：2013/04/20(土) 11:54:02.78

DIという概念とJavaのDIコンテナの違いも分かってないようだが、それはそれとして、このスレはおじゃばの疑問を解消するスレじゃないんだから、質問はマ板のJavaスレなんかでやってくれ。

346 ：仕様書無しさん：2013/04/20(土) 12:12:16.74

DIは不要。技術力の低いプログラマーを
大量に寄せ集めた場合は統制が取れるから有用だけど
そうじゃなければ足かせにしかならない
それなりに技術力あるのに使ってるやつらは流行りもの好きかただのマゾ

347 ：おじゃばさま：2013/04/20(土) 12:31:08.00

>>346
俺もDIは不要だと思う。
初心者に使わせたら、それこそカオスになるし、
オブジェクト指向のクラス分割の基本を知っていれば、
変更しやすさが落ちることはない。
DIを勧めるのは雑誌の提灯記事記者ぐらいだろ。

348 ：仕様書無しさん：2013/04/20(土) 13:32:44.82

まあmock使わないならDIコンテナは不要だろうな

349 ：仕様書無しさん：2013/04/20(土) 13:41:00.15

DIコンテナを使うかどうかは人それぞれだろうが、依存性注入や依存性逆転の概念は重要で、別にDIコンテナを使わずとも実現できる。

350 ：仕様書無しさん：2013/04/20(土) 13:50:46.65

コード内でnewすると、そこで静的に束縛され相手と強固に結合してしまうのが駄目。
テスト容易性という観点からも、その結合はよろしくない。

351 ：仕様書無しさん：2013/04/20(土) 13:58:28.73

今度は、結合度は高くてもいいだろっていう議論したいの？
低い方がいいに決まってるじゃん。

352 ：仕様書無しさん：2013/04/20(土) 14:02:13.49

だんだんOOなんか意味ない、むしろ害悪と言ってるstaticおじさんレベルになってきてるぞ

353 ：仕様書無しさん：2013/04/20(土) 14:13:50.29

だからJava屋は生産性低いんだよ
たいして効率の上がらないツールに学習コストかけてる

354 ：仕様書無しさん：2013/04/20(土) 14:37:36.88

>>353
だから、DIコンテナとDI, DIPをいっしょくたにするなって

355 ：おじゃばさま：2013/04/20(土) 17:29:58.22

全クラスにインタフェースのついた、
悪夢のようなシステムの改修を頼まれた事がある。
IDEの呼び出し元ジャンプは使えないし、
XMLの設定は見にくいし、構造理解するのに、
かなり苦労した。
構造変えられないから、同じように継承なしの1クラス1インタフェースで修正したよ。

356 ：仕様書無しさん：2013/04/20(土) 17:50:55.24

おっと、今度はポリモーフィズムdisですか。

357 ：仕様書無しさん：2013/04/20(土) 17:59:24.97

>>355
で、結局、Concreteクラス同士の結合が強固な構造になりましたとさ。

358 ：仕様書無しさん：2013/04/20(土) 18:09:34.04

も、もう釣られないぞっ！！

359 ：仕様書無しさん：2013/04/20(土) 18:11:06.97

もうOOやめりゃいいじゃん

360 ：仕様書無しさん：2013/04/20(土) 18:14:10.55

別に結合なんて強くていいんだよ
ソース書き換えるコストとXML書き換えるコストなんてたいして変わらん

361 ：おじゃばさま：2013/04/20(土) 18:28:37.22

OOとDIは直接関係ないだろう。

362 ：仕様書無しさん：2013/04/20(土) 18:34:30.68

そういうことにしたいのですね

363 ：仕様書無しさん：2013/04/20(土) 18:57:45.92

つい最近までDI知らなかったくせに良く言うわ

364 ：仕様書無しさん：2013/04/20(土) 19:02:47.59

おじゃばの発言の一個前に、なぜだかおじゃばを擁護するような発言があるのは気のせいか

365 ：仕様書無しさん：2013/04/20(土) 19:09:34.76

mockも知らなかったみたいだしな

366 ：仕様書無しさん：2013/04/20(土) 19:11:28.31

タグジャンプができないから設計が糞って、どういう思考回路なんだか。

367 ：おじゃばさま：2013/04/20(土) 19:22:07.52

>>363
mockは知らなかったが、知った早さから言えば、
DIもEJBもJUnitも俺の方が早いんじゃないか？

368 ：おじゃばさま：2013/04/20(土) 19:24:17.54

>>366
でDIにはどんな利点があるんだ？

369 ：仕様書無しさん：2013/04/20(土) 19:25:25.78

お前の知ってるってのは単語を聞いたことあるってレベルだろ？
全然理解できてないからダメなんだよ

370 ：仕様書無しさん：2013/04/20(土) 19:33:25.25

俺は実際に何度も使ったけどな
費用対効果が悪すぎるだろあれは

371 ：仕様書無しさん：2013/04/20(土) 19:41:08.91

インターフェイスから型階層なりで実装みりゃいいし、インターフェイスだから実装ジャンプできないってのは馬鹿だと思う
そもそもちゃんと設計されてるなら実装なんて気にしなくてもいいわけだしな

DIは依存性注入を有効活用できないなら無駄だと思う
まともなUTしてなんぼ

372 ：仕様書無しさん：2013/04/20(土) 19:43:52.82

おじゃばは単語の意味を知る事と、理解を深めて使いこなせる知識やスキルを得ることを、
早かったか遅かったかだけで比較しようというのがまずアレだって事に気付いてから発言したほうがいいよ
DIの利点が分からないなら、理解力がその程度ってことだろ。向いてないから諦めろ

373 ：仕様書無しさん：2013/04/20(土) 20:36:16.82

DIコンテナが大げさすぎるという意見はわかるが、DIやDIPが駄目だというのには同意できない。

374 ：仕様書無しさん：2013/04/20(土) 20:39:27.98

Javaがダメだから、DIするだけで大げさなDIコンテナが必要になる

375 ：仕様書無しさん：2013/04/20(土) 20:41:49.33

>>374
自前でDIしたっていいんだよ？

376 ：仕様書無しさん：2013/04/20(土) 20:53:22.35

普通にnewしろよ。見えない部分に処理を任せるのはトラブルの元。

377 ：仕様書無しさん：2013/04/20(土) 20:57:30.94

えっと、デザパタとかは全否定ということですか？

378 ：仕様書無しさん：2013/04/20(土) 20:59:01.91

ええ、何をいまさら？

379 ：おじゃばさま：2013/04/20(土) 21:27:15.44

DIを使えば、スパゲティプログラムにならないとか、
JUnitを使えば、結合試験で大したバグが出ないとか言っている時点で、
理解しているとは思えないが。

380 ：おじゃばさま：2013/04/20(土) 21:53:52.75

デザインパターンと言うのは、大量のコードを分類し、
そこから何かを発見するという学問的な物で、
OOコードのサンプル集ではない。
本当にデザインパターンを勉強したいなら、
大量のコードを自分で分類すべきで、
誰かの分類したのを暗記しても、大した効果はない。

381 ：仕様書無しさん：2013/04/20(土) 21:56:35.32

そういうことにしたいのですね

382 ：仕様書無しさん：2013/04/20(土) 22:21:35.46

>>376
理解力のないオッサンが同じようなこと言ってたな
口だけで勉強しないでわからないことを全否定するってスタンス
でも、そいつの書くコードは絵に書いたような糞コードっていうアレ
もう居ないけど

383 ：仕様書無しさん：2013/04/20(土) 22:52:01.92

>>382
おまえは業界のすべての技術を勉強しきってるのか？
俺はDIにその価値は感じなかったので勉強時間は別のことに使ってるよ

384 ：仕様書無しさん：2013/04/20(土) 22:53:15.13

俺もRubyには価値を感じなかったのでJavaを勉強してる。

385 ：仕様書無しさん：2013/04/20(土) 22:53:50.03

最新技術に価値を感じなかったので、古い技術を使ってるよ。

386 ：仕様書無しさん：2013/04/20(土) 22:56:16.59

DIコンテナとかなくても困らないもの勉強するより
iOSアプリやAndroidアプリ勉強したほうが100倍いいよ

387 ：仕様書無しさん：2013/04/20(土) 22:56:48.42

iアプリ勉強してます。

388 ：仕様書無しさん：2013/04/20(土) 22:59:36.20

>>385
技術は目的ではないからね、正しい判断だよ。

389 ：仕様書無しさん：2013/04/20(土) 23:02:44.43

>>388
じゃあ、目的は何なの？

390 ：おじゃばさま：2013/04/20(土) 23:03:20.36

俺はTitanium Mobileやろうと思ってる。
誰かやってる人いるか？

391 ：仕様書無しさん：2013/04/20(土) 23:03:54.11

目的さえ達成出来れば、手段は関係ないからね。

飛行機でも船でもアメリカに行くという目的は達成できる。

この間プロジェクト開発という目的を達成したよ。
10年かかった。

392 ：仕様書無しさん：2013/04/20(土) 23:06:09.65

>>391
お前頭悪いなｗ

393 ：仕様書無しさん：2013/04/20(土) 23:08:54.05

>>392
褒めるなよｗ

目的には、前提となる条件があることに
気づかない馬鹿を演じてるんだからさ

394 ：仕様書無しさん：2013/04/20(土) 23:14:04.74

>>389
愚問

395 ：仕様書無しさん：2013/04/20(土) 23:15:51.70

俺も言い返せなくなくなったら、愚問っていおうｗ

396 ：仕様書無しさん：2013/04/20(土) 23:20:17.27

へらず口の才能はピカイチだからそんな心配はいらんよｗ

397 ：仕様書無しさん：2013/04/21(日) 00:12:31.75

愚問

398 ：仕様書無しさん：2013/04/21(日) 00:14:05.75

愚問は流行る

399 ：仕様書無しさん：2013/04/21(日) 03:34:06.32

愚問ブラック2とか愚問ホワイト2だな。

400 ：おじゃばさま：2013/04/21(日) 11:47:11.16

DIの利点について検証しよう。
1.依存性を分離する事で、再利用性が高まる。
→正しくインタフェース設計が出来ていれば、再利用性は高まる。
ただし通常のシステムでそれほど再利用性が必要な場面は多くない。
また依存性の設定ファイルの記載が面倒。
2.修正が入った場合、設定ファイルを修正するだけで修正出来る。
→修正を考慮して設計してあれば、そういう場合も、あるかもしれないが、
基本的に修正の手間は変わらない。
また、インタフェースの設計が適切でないと、
修正コストは通常のOOよりかなり高くなる。
3.横断的関心事の実装が容易。
→確かに便利。
4.テストが容易。
→JUnitのユニット試験には便利。
ただし単体試験のコストは変わらない。
5.スケーラビリティに優れる。
→論理的にはスケーラビリティに優れるという意見もあるが、
実際には処理コスト、通信コストのため、
スケーラビリティは落ちる。

401 ：仕様書無しさん：2013/04/21(日) 11:51:39.23

結論：DIは糞

402 ：仕様書無しさん：2013/04/21(日) 11:55:43.44

>>401
なんで理解できないの？

403 ：仕様書無しさん：2013/04/21(日) 11:56:20.69

>>402
愚問だな。

404 ：仕様書無しさん：2013/04/21(日) 12:00:31.81

>>400
俺が言いたいことをすべて言ってくれたわ
これからコード書く人にはDIなんてやめて
他のこと勉強することをオススメする
勉強しないといけないことは無限にあるからな

405 ：仕様書無しさん：2013/04/21(日) 12:02:12.57

>>402
いいえ、理解したうえで糞なのです。

406 ：仕様書無しさん：2013/04/21(日) 12:59:03.91

>>405
理由の説明は？
あ、愚問でしたっけ。くすくすｗ

407 ：仕様書無しさん：2013/04/21(日) 13:39:04.96

少しは身になる事も聞けよ

408 ：仕様書無しさん：2013/04/21(日) 14:04:32.31

また独自用語作ってるし、自分の日記帳でやってろよって感じ

409 ：仕様書無しさん：2013/04/21(日) 14:09:53.43

いつまでたってもDIコンテナと設計概念としてのDIの区別が付かない奴がいるな。
どんだけ頭固いんだよ。

410 ：仕様書無しさん：2013/04/21(日) 14:18:04.06

DIなど言語やツールの制約を回避するためのテクニックにすぎん

411 ：仕様書無しさん：2013/04/21(日) 14:30:52.13

まあ、自分が知らなかったり使えない物は、駄目なものとして整理すれば楽だわな。

412 ：仕様書無しさん：2013/04/21(日) 14:32:53.17

利用する、便利じゃん。
否定するのはただアホだよ。
便利に使える状況か判断して利用することに意味がある。
0か1で判断しようってのがそもそも頭悪い。

413 ：仕様書無しさん：2013/04/21(日) 14:37:52.88

実クラスをnewする駄目さがわからないのなら、DIは必要ないな

414 ：仕様書無しさん：2013/04/21(日) 14:39:24.67

馬鹿ですね。客がその価値を理解していないものは
いくら便利だろうがやっても無意味なんですよ。
そんなものをつかってサボられるより、２倍の項目を
やってもらったほうがいいんです。
どうせやるのは奴隷たちだしね。

415 ：仕様書無しさん：2013/04/21(日) 14:43:52.42

まあ、自分が何でも知っていると思っていれば幸せだわな。

416 ：仕様書無しさん：2013/04/21(日) 14:46:23.71

>>414
その結論が、ステップ実行で単体テストのエビデンス地獄ですか。

417 ：仕様書無しさん：2013/04/21(日) 14:55:07.07

たとえ地獄でも客が望むものを作れればいいでしょ？
ぶっちゃけ同じシステムを作れるのなら。
素人がやっても問題ない。時間がかかるだけの話。

418 ：仕様書無しさん：2013/04/21(日) 14:55:59.54

>>414
奴隷根性が染み付いてしまってるな、可愛そうに。

ツールを利用するのはザボりで手抜きだから手作業でやれって、
奴隷が歳をとって手に負えないような老害に発展したタイプがよく言ってる。
実益を伴わず、程度の低い場所で立ち止まってしまって、先がない。

419 ：仕様書無しさん：2013/04/21(日) 14:56:00.85

納期、品質、コストまで含めて「価値」だろｗ

420 ：仕様書無しさん：2013/04/21(日) 14:57:10.76

納期、品質、コストは根性さえあれば解決できる問題。

無給、無休ではたらく奴隷なら
何千人もいる。

421 ：仕様書無しさん：2013/04/21(日) 15:01:12.20

>>416
客がそれを望むなら、そうなるね。
奴隷側に選択権があると思うなよ。何様のつもり？

422 ：仕様書無しさん：2013/04/21(日) 15:02:51.40

>>418
客に有益性を主張して採用してもらうより
労働を放棄しようとする奴隷を入れ替えるほうが
コストが安い。

423 ：仕様書無しさん：2013/04/21(日) 15:04:58.91

>>418
キミが奴隷を使役する立場になれるんだったら、好きすればいい、という話。
使役できずに逆に使役される立場だから、こんなところで一生懸命愚痴ってるんでしょ。

424 ：仕様書無しさん：2013/04/21(日) 15:06:45.24

なんか今日臭い奴が居るな。
俺は使う側だからとかそんな事思いながらマ板で鼻高くしてる。
目糞なの？

425 ：仕様書無しさん：2013/04/21(日) 15:13:19.92

論理で勝てないことが分かったから権力に頼るようになっただけ。
ただの敗者の設定変更に過ぎない。

426 ：仕様書無しさん：2013/04/21(日) 15:14:38.48

鼻糞にも鼻糞なりの論理があるんだね

427 ：仕様書無しさん：2013/04/21(日) 15:23:24.84

>>425
納得した

428 ：仕様書無しさん：2013/04/21(日) 15:25:58.69

staticハゲもどきの次は、客の信頼も得られず交渉能力もない
無能なSEだかSIだかが湧いてきたのか。ここはいつも賑わってるな。

429 ：仕様書無しさん：2013/04/21(日) 16:22:44.90

ようは他よりも高い金額で
質が劣るものを売ればいいだけの話。

430 ：仕様書無しさん：2013/04/21(日) 16:28:22.64

SIerには関わらないように

431 ：仕様書無しさん：2013/04/21(日) 16:29:59.42

似たようなもの大量生産する場合と
トリッキーな組み方で特殊な動きを出す場合じゃ使うものが違うってだけで
両方使えた方がいい

432 ：仕様書無しさん：2013/04/21(日) 16:37:14.03

作業が簡単にできるようになると、
値段の根拠がなくなるだろ。

効率化すると、
ほら見て、こんなに一生懸命頑張ってるんだ。
だから、金ちょうだいね。って言えなくなる。

客からスレば、ものさえ出来ればいいわけだし。

433 ：仕様書無しさん：2013/04/21(日) 16:49:19.68

自分からみて馬鹿にみえる人間が馬鹿な事を言ってるので
馬鹿な事を分からせる為に馬鹿な人間のふりをしてもっと
馬鹿なことを言ってみても傍から見ると馬鹿な人間が馬鹿な事を
しているだけであるという馬鹿げた事実

434 ：仕様書無しさん：2013/04/21(日) 16:53:42.45

>>433
意味がよくわからんので、
目的と結果だけ書いて

435 ：仕様書無しさん：2013/04/21(日) 16:54:58.52

目的・・・馬鹿がいるとみんなに思わせる
結果・・・馬鹿なことをしているとみられる

想定通り？

436 ：仕様書無しさん：2013/04/21(日) 17:07:11.06

スレタイから大きく離れているぞ
やってほしいこと、のスレだ

437 ：仕様書無しさん：2013/04/21(日) 17:08:25.76

>>436
結論出てるだろ。
「無給で、大量のテスト項目を淡々と消化しろ。効率化とか余計なことを考えるな。」

438 ：仕様書無しさん：2013/04/21(日) 18:10:28.98

つまりまとめると、これからコードを書く人は
>>437みたいな頭悪い発言をする老害にはならないようにして欲しいって事だな

439 ：仕様書無しさん：2013/04/21(日) 18:43:13.44

>>438
コードを書く人は、
こういう指示系統の上流に立つ人間には
なりたくてもなれないんだよ。
残念ながら。

440 ：おじゃばさま：2013/04/21(日) 18:50:45.38

ビジネスはWIN-WINの関係でなけれは存続できない。

441 ：仕様書無しさん：2013/04/21(日) 18:52:33.67

>>440
お客様WINーSE WINー奴隷PG死ね
の関係でおｋ。

442 ：おじゃばさま：2013/04/21(日) 19:14:58.25

プログラマの使い捨ては、プログラマを0.5人前で使うより、
トータルコストがかかる。

443 ：仕様書無しさん：2013/04/21(日) 19:16:20.62

>>442
なんのコストがかかるんだ？奴隷を使うのに。

444 ：仕様書無しさん：2013/04/21(日) 19:23:30.16

>>443
奴隷はトイレにこもる性質があるから、
トイレットペーパー代と水道代がすごいぞ。

445 ：仕様書無しさん：2013/04/21(日) 20:05:24.12

板違いの話題続けるなら他所でやれ

446 ：仕様書無しさん：2013/04/21(日) 20:11:05.56

>>444
富○通によく行くんだけど、中○・小○・蒲○どこいっても
トイレの個室があいてるの見たことないんだよな。

447 ：仕様書無しさん：2013/04/21(日) 20:17:21.90

まじか　そんな世界か

448 ：おじゃばさま：2013/04/21(日) 20:26:40.78

>>443
採用の経験も権限も責任もない者が、
軽々しく使い捨てなどというべきではない。

449 ：仕様書無しさん：2013/04/21(日) 20:30:59.80

>>448
じゃあ俺は経験も権限も責任もあるので
言いたい放題で構わないということですね。

450 ：おじゃばさま：2013/04/21(日) 20:46:01.98

>>449
どうぞ

451 ：仕様書無しさん：2013/04/22(月) 01:19:35.24

>>446
おい生々しいぞ

452 ：仕様書無しさん：2013/04/23(火) 20:33:15.98

何をどう直したかわかるようにテキストでもExcelでも何でもいいから資料にしてくれ
上司への報告も、自分が何してるかも把握できるから捗るぞ

大体一人ひとりのソースなんかみっちりチェックする時間ないし、
口頭で言われても都合が悪くなると水掛け論なるから回避の意味でやってくれ

453 ：仕様書無しさん：2013/04/23(火) 20:37:40.04

>>452
コミットコメントで十分だろ

454 ：仕様書無しさん：2013/04/23(火) 22:05:52.28

>>452
しょうもな

455 ：仕様書無しさん：2013/04/23(火) 22:26:19.32

他人が見てコミットコメントだけじゃ
どこにどんな機能があるかわからんだろ

456 ：仕様書無しさん：2013/04/24(水) 00:29:35.71

コメントちゃんと書いてドキュメント生成ツール使えよ

457 ：仕様書無しさん：2013/04/24(水) 00:57:20.13

コミットログ確認して他人の修正確認してってやってくれる良Pほとんどいないな
それどころか自分のコミット内容すら確認せずpushしてくるクズが腐るほど居る
底辺

458 ：仕様書無しさん：2013/04/24(水) 07:37:21.34

>>453-454
こういうやつらがいると現場が混乱する

459 ：仕様書無しさん：2013/04/24(水) 08:31:08.48

>>452
修正レベルの話であれば、コミットコメントをちゃんと書けで終わり。
新規コードの話であれば、それは後付けの詳細設計書を書けと言ってるのと同じで、今時流行らないよ。
各種ドキュメント生成ツール用のコメントをきちんと書かせて、さらにコード内にも適切なコメントを書かせ、ツールでドキュメント作るのがいいよ。

君、ひょっとしてプログラマじゃないんじゃない?
プログラマはそういう資料を作らされるのが最も嫌な作業で、モチベーション下がりまくるよ。
顧客提出資料として必要ならしかたないけど。

460 ：仕様書無しさん：2013/04/24(水) 08:38:02.07

そもそも、品質の悪いコードしか書けない奴を管理するのが目的だとしたら、それはそんな資料作らせても無駄で、結局コードレビューするしかないよ。

461 ：仕様書無しさん：2013/04/24(水) 09:10:28.90

底辺ばっかやな

462 ：仕様書無しさん：2013/04/24(水) 11:42:09.00

>>452
これ思い出したわ。

冷たい方程式（11）マイクロマネジメント
http://el.jibun.atmarkit.co.jp/pressenter/2012/03/11-84d1.html

俺だったらそんな非生産的なこと絶対やりたくないね。

463 ：仕様書無しさん：2013/04/24(水) 11:45:52.67

ちなみに、>>452みたいな足かせがあると、こんなことが起こり得る。

・機能追加をするとき、あるメソッドを少し変更すれば実現できるが、既存コードを修正すると
なにかとうるさいのでメソッドを丸ごとコピペして変更し、新規にコードを書いたことにする。

・既存コードのバグを見つけたが、変更すると面倒なので見逃した。

・リファクタリングしたいけど、なにかと面倒なのでしない。

464 ：仕様書無しさん：2013/04/24(水) 12:50:19.40

ありすぎて困る
privateメソッドのシグネチャどころかロジックまで書かせる詳細設計書とかもそうだな

465 ：仕様書無しさん：2013/04/24(水) 20:45:39.91

>>456
コメントちゃんと書けってのはわかるわ
doxygenやらjavadocとかは途中内容変わるしめんどくさ
最後に書くわって言って時間足らなくて適当に書くこと多々ｗｗｗ

466 ：仕様書無しさん：2013/04/24(水) 21:31:47.67

こんなとこ来てるヒマあったら新しい入門書を１冊読みきれ

467 ：仕様書無しさん：2013/04/24(水) 23:35:34.51

ゲーム機の仕事とかやるとネットも本も糞程の役に立たなくて困る。

468 ：仕様書無しさん：2013/04/24(水) 23:52:52.75

>>459
物作りは遊びじゃねえんだよ
好き嫌いでモチベーション下げるとか社会人未満だろ

469 ：仕様書無しさん：2013/04/25(木) 00:11:50.61

>>468
下がるものはしかたがない。
下げないようにするのもマネジメントだ。

470 ：仕様書無しさん：2013/04/25(木) 00:38:45.29

非生産的な命令でモチベーション下がる奴が悪いとか言う奴は、無意味に穴掘って埋める拷問も問題ないとか言い出しそうで怖いな

471 ：仕様書無しさん：2013/04/25(木) 01:10:24.34

それが社畜クオリティ

472 ：仕様書無しさん：2013/04/25(木) 01:57:57.84

古い考えだけで非効率な仕事してたら取り残されんで

473 ：仕様書無しさん：2013/04/25(木) 07:34:25.89

>>470
テストとかドキュメント作成とかちゃんとやらなそうだね君は。
好きなことだけやれる職業なんてないぞ。

474 ：仕様書無しさん：2013/04/25(木) 07:46:32.39

>>473
ということにしても、>>452の駄目さ加減とは関係ないけどね。

475 ：仕様書無しさん：2013/04/25(木) 09:22:21.70

>>473
そのための自動化だろ

476 ：仕様書無しさん：2013/04/25(木) 10:43:44.14

>>473
わかってないねぇ。
テストをきちんとやり、必要なドキュメントもきちんと作る人達のモチベーションをも下げてしまうから
>>452は駄目なんだよ。

テストも必要なドキュメントもやりたくねー、なんて奴らはもともと駄目駄目。

477 ：仕様書無しさん：2013/04/25(木) 11:51:03.79

つか、俺>>452の内容がさっぱり理解できないんだが。

>上司への報告
これ何？何を報告するんだ？

>口頭で言われても
何を口頭で言うんだ？

>水掛け論なるから
何に関して水掛け論になるんだ？

478 ：仕様書無しさん：2013/04/25(木) 14:51:42.96

つうか、>>452の言う上司ってなんだ？
前半は、ソース読めなくて日本語で説明欲しがってるような気がするが、
後半は、いちいちソースレベルで中身確かめる前提になってる。

479 ：仕様書無しさん：2013/04/25(木) 14:55:09.14

ソース読めないレベルの奴に何の説明をするんだか

480 ：仕様書無しさん：2013/04/25(木) 16:04:51.30

このスレはエセエンジニアが多いから空想プロジェクトに妄想上司が出てくる

481 ：仕様書無しさん：2013/04/25(木) 17:01:42.26

空想やったらテストでもドキュメントでもなんぼでも書いたるで

482 ：仕様書無しさん：2013/04/25(木) 17:14:19.97

No ticket, No commit.

これだね。

483 ：仕様書無しさん：2013/04/25(木) 17:16:45.59

trivial change禁止とか
fix a bug禁止だと
ちょっと辛いかも。

484 ：仕様書無しさん：2013/04/27(土) 07:39:39.74

あ

485 ：仕様書無しさん：2013/04/27(土) 11:21:49.71

ほ

486 ：仕様書無しさん：2013/04/27(土) 11:40:32.78

げ

487 ：仕様書無しさん：2013/04/27(土) 12:44:58.43

萌

488 ：仕様書無しさん：2013/04/27(土) 16:20:23.96

ゆ

489 ：仕様書無しさん：2013/04/27(土) 17:32:53.52

↑休日はこういうことをやらず勉強するかレジャーに出かけること>>1

490 ：仕様書無しさん：2013/04/27(土) 19:07:10.55

↑というコメントを休日にしないこと

491 ：仕様書無しさん：2013/04/27(土) 21:15:21.29

↑

492 ：仕様書無しさん：2013/04/28(日) 02:50:06.99

↓

493 ：仕様書無しさん：2013/04/28(日) 09:27:28.06

↑

494 ：仕様書無しさん：2013/04/28(日) 12:48:37.44

↓矢印厨

495 ：仕様書無しさん：2013/04/28(日) 13:11:10.40

私のおいなりなんたら

496 ：仕様書無しさん：2013/04/28(日) 18:08:39.03

>>126

＞　「……こんな具合に、staticを使えばインスタンス宣言などしなくてもいいんだよ。
＞どっちが楽か分かるだろ？いちいちインスタンス宣言するなんておかしいよ」

これの意味を教えていただけませんでしょうか？
ローカルで、変数やらクラスを宣言毎回宣言するのではなく
グローバルで変数やらクラスを宣言してしまえばいいじゃんと言ってるのでしょうか？

497 ：仕様書無しさん：2013/04/28(日) 18:30:52.94

↑というコメントを休日にしないこと

498 ：仕様書無しさん：2013/04/28(日) 21:31:39.74

↑オマエがなｗ

499 ：仕様書無しさん：2013/04/28(日) 21:32:38.95

◎じゃあの野間まつり◎
第二弾来ました！

251:以下、名無しにかわりましてVIPがお送りします[]
2013/04/28(日) 21:09:36.73 ID:Vr/xxrpV0
ようｗｗｗｗおまいらｗｗｗｗそろそろ始めっか？ｗｗｗｗ
今回はよおｗｗｗしばき隊構成員全般対象にすっからｗｗｗｗ
連帯責任なｗｗｗあーあｗｗｗ野間のせいだｗｗｗ全部野間が悪いｗｗｗ

--- 以下スレ情報 ---
高岡さんがフジ韓流ゴリ押し批判したら干されたのでウジテレビ凸
http://hayabusa.2ch.net/test/read.cgi/news4vip/1367118004/

500 ：仕様書無しさん：2013/04/29(月) 00:08:05.20

↑レス番㌧㌦

501 ：仕様書無しさん：2013/04/29(月) 00:29:40.82

>>496
そのバカは「Cで複数の関数を複数のファイルに分ける」代わりに「Javaで複数のメソッドを複数のクラスに分ける」という使い方を想定してるんだよ。
sin関数みたいなプリミティブなデータ型を変換するだけの場合はJavaでもMath.sinっていうstaticメソッドで実装されてるからアレなのかもしれん。

とりまデータと操作がワンセットな物で考えるとわかりやすい。
Cのfputs的なのはそのままオブジェクト化すると、
class FILE{public int fputs(...){...}...}
的になってfo=new FILE()してからfo.fputs(...)として使うが、こいつの場合、
class stdio{public static int fputs(...){...}...}class FILE{...}
とやってfp=new FILE()してからstdio.fputs(fp,...)と書く…ということになる。
結局newしてる上にデストラクタによる後始末が無いなど良いところがない。

オブジェクト指向の教科書ってアホみたいにdogだのcarだの意味不明なクラスを作ってるから、
教科書範囲のコードを書くだけなら確かにstaticで良いんだが…実用考えるとそうじゃない訳だ。

502 ：仕様書無しさん：2013/04/29(月) 01:08:36.27

ほうほう

503 ：仕様書無しさん：2013/04/29(月) 02:35:59.08

日本人の払った貴重な血税から
ゴキブリ在日朝鮮人に生活保護が支払われている

ゴキブリ在日朝鮮人の一家族で年間６００万円である

ゴキブリ在日朝鮮人の２人に１人は生活保護だ

これより安い給料で働いている日本人が
少ない給料から支払った税金が
ゴキブリ在日朝鮮人の生活保護になっている

ゴキブリ在日朝鮮人は生活保護をもらって
毎日パチンコをして遊んで暮らしてる

ゴキブリ在日朝鮮人の犯罪者も非常に多い
ヤクザの２人に１人はゴキブリ在日朝鮮人だ

日本社会の寄生虫　ゴキブリ在日朝鮮人
日本から出て行け！　ゴキブリ在日朝鮮人

504 ：おじゃばさま：2013/04/30(火) 18:45:58.24

オブジェクト指向プログラミングの利点について説明しよう。
オブジェクト指向の利点は、修正に強い事だ。
以前の構造化プログラミングには問題があった。
それは変更を考慮して設計しておかないと、
修正の度にコードが複雑化し、スパゲティコードと呼ばれる物になる事だ。
構造化では修正が入った場合、基本的にはif文を追加し、
そこに新しいコードを追加する事になる。
この些細と思われる事が大問題を引き起こす。
修正が多岐に渡ると、基本構造が崩れ、既存の処理にも影響し、
スパゲティコードと化す。
修正を考慮した設計であれば想定内の修正には耐えるが、
想定外の修正には弱く、しばしば設計変更が発生する。
これを解消するのがオブジェクト指向だ。

505 ：仕様書無しさん：2013/04/30(火) 19:13:16.08

再利用や修正が容易な設計に"利用可能な"仕組みがある、というだけ
スパゲティ書くようなスキルでオブジェクト指向したらもっとカオスなスパゲティになるだけだよ
オブジェクト指向プログラミングは構造化プログラミングでまともなコードが書けることが前提みたいなもんだ

修正内容と既存の実装の相性が悪かった時(初期設計時の見通しが甘かった場合)の修正難易度は、オブジェクト指向プログラミングの方が高くなる事もある
複数のクラスを縦断して修正を迫られたりするからね

506 ：仕様書無しさん：2013/04/30(火) 21:40:08.45

オブジェクト思考とかプログラム修正入れたときの影響範囲の調査と報告が面倒なのが
構造化プログラミングの共通処理をまとめるってのものやりたくない
このへんの手法って呼び元を意識しなくていいって聞いてたのに騙された

507 ：おじゃばさま：2013/04/30(火) 23:05:13.78

オブジェクト指向の修正パターンは3つある。
1.メソッドを追加する。
2.メソッドをオーバライドする。
3.共通要素を親クラスに移動し、
メソッドをオーバライドする。
基本的に構造化のような、
if文を追加してのコード追加は、
出来るだけ行わないようにして、
2、3で対応する。
これにより大きな利点が発生する。
まず、既存の処理に修正が殆ど入らないため、
既存の機能が失われる事がない。
以前の機能に戻すのも容易だ。
次に、3を行うことにより、
共通要素が親クラスに、
固有の要素がそれぞれのクラスに分離される。
親クラスには抽象化され、さらに使いやすくなる。
構造化が変更により複雑化するのに対して、
オブジェクト指向では、変更により、洗練され使いやすくなる。

508 ：仕様書無しさん：2013/04/30(火) 23:23:29.13

それって実装の継承とis-a関係ってこと?
だとしたら、それ10年前の流行りだよ。

509 ：おじゃばさま：2013/05/01(水) 00:14:54.80

>>505
構造化の場合は、変更を予測する必要があるが、
オブジェクト指向の場合は、ある一定のルールに従えばいい。
それがクラスのオブジェクト化なのだが、端的に言えば、
1.マネージャ化
2.データアクセスオブジェクト化
である。
1はクラスを「～する人」として設計する事だ。
ファイルの書き込みならFileWriterのように、
クラス設計する。
2はクラスを「データ＋アクセスサ」とする事だ。
キー＋値なら、HashTableのように、
DBテーブルレコードなら、
項目とゲッター及びセッターのように、
クラスを設計する。
基本的にこのどちらかでクラス設計すれば良い。
ただし、変換クラスInteger.parseIntなどのような例外もあり、
これは構造化と同じような設計になる。

最初は厳密でなくても良い。
オブジェクト指向のクラス設計で、
オブジェクト指向の変更方法で行えば、
修正の度にコードが洗練されていく。
これが実感できれば、オブジェクト指向の基礎が、
習得出来たと言えるだろう。

510 ：仕様書無しさん：2013/05/01(水) 00:26:36.31

ブログでやって

511 ：仕様書無しさん：2013/05/01(水) 01:04:36.18

>>504-509
テンプレマーカー

512 ：仕様書無しさん：2013/05/01(水) 01:44:47.05

>>509
でクラス設計の元になるデータ構図の設計ミスって変更の際に関連クラス全部再設計・・・と。
このへんは構造化プログラミングでも同様だから、オブジェクト指向プログラミングと構造化プログラミングで優劣がある部分ではない。
つまり、オブジェクト指向だ構造化だ以前の部分に問題があってスパゲティ化するんであって、どちらであっても上手く設計するスキルは必要。
そしてオブジェクト指向プログラミングでもメソッドの実装でどのみち構造化プログラミングは必須なんだよ。

構造化プログラミング∈オブジェクト指向プログラミング、そしてその前にアルゴリズムとデータ構造への理解が要る。
オブジェクト指向プログラミング＝構造化プログラミングよりバグが出にくく便利な技法、みたいなアホな考えはさっさと捨てれ。

513 ：おじゃばさま：2013/05/01(水) 08:16:53.93

>>512
確かに構造化とオブジェクト指向は対立する物ではなく、
オブジェクト指向でも構造化の知識は必要だ。
ちなみに、オブジェクト指向が構造化より
バグが出にくいという事は無い。

オブジェクト指向の利点は前から言っている通り、
修正に強いという事だ。
データ設計を間違えていたとしても、
オブジェクト指向の修正方法に従えば、
共通要素は親へ、個別要素は子へ分離されるので、
スパゲティ化しない。
その時の修正の手間は変わらないかもしれないが、
それ以降の修正の手間が大きく異なる。
そのため、とりあえず適当に作って、
修正により抽象化を進めて、完成させるという方法が出来る。

ここで重要なのは下手に拡張性を考慮しない事だ。
使うかもしれないが使っていない機能や拡張性は、
抽象化の妨げになる。
必要な機能のみでオブジェクト指向の修正方法に従えば、
勝手に拡張性にも優れたコードになる。
これがオブジェクト指向の特徴だ。

514 ：仕様書無しさん：2013/05/01(水) 08:30:55.33

委譲もDIもよくわかってない奴が何寝ぼけたこと言ってんだか。
OOだから自動的に設計や構造が洗練されるわけない。
OCPやLSPを意識しない実装継承やってると、容易にスパゲッティ化する。

515 ：仕様書無しさん：2013/05/01(水) 10:08:15.33

おじゃばの言うことが全然駄目とは言わないが、DogクラスがあってCatクラスが必要だから
汎化されたAnimalクラスを作りましょう、の域から出てない気がする。
その手の話は、もう20世紀中に終わった話だ。
GoFのデザパタ本が出たのが1995年だぞ。

516 ：仕様書無しさん：2013/05/01(水) 11:20:20.10

コード間に密結合を生むから全然ダメ
はっきり言ってウンコ

517 ：仕様書無しさん：2013/05/01(水) 15:34:21.63

なんでいきなり設計論を始めたのかしらんが、所詮お前のレベルはこれでもうばれてる

>>146
> 回線接続後の通信エラーはどうやった？
> ファイルオープン後のライトエラーや、
> リソース不足エラーは？

518 ：おじゃばさま：2013/05/01(水) 18:25:36.60

古いもなにも、これがオブジェクト指向の基礎だ。
この基礎だけでも、殆んどのシステムで事足りる。

しかしこの基礎とは異なる組み方を推奨する人達がいる。
DI、デザパタ、委譲を推奨する人達だ。
しかし未だに俺は、この組み方が基本の組み方より
優れている点を、聞いた事がない。
誰か優位点を説明してくれないか？

519 ：仕様書無しさん：2013/05/01(水) 18:26:28.99

【PV】さよならクロールダイジェスト映像 / AKB48[公式]

http://www.youtube.com/watch?v=K90F_aZBFZA

お前らこれ見て宿題しろ
オレはパン食べる

520 ：おじゃばさま：2013/05/01(水) 18:47:46.32

>>519
投票券、握手券商法のせいで、アイドルの笑顔が邪悪に見える。

521 ：仕様書無しさん：2013/05/01(水) 20:52:04.01

書けば書くほど恥の上塗り

522 ：仕様書無しさん：2013/05/01(水) 23:12:39.16

ステップ実行しないとテスト出来ないということから、結合度が高く変更も容易でないという結論にはたどりつかないのだろうか。
newしないほうがいいということが解らないアホには、何を言っても無駄かも知れないがね。

523 ：仕様書無しさん：2013/05/01(水) 23:56:16.65

GoFのデザインパターンは、よくある暗黙知を形式知にしたものにすぎないものが多い。
デザインパターンは不要だと言う奴をたまに見かけるが、多分その事を知らないんだろう。
あと、おじゃばはJavaプログラマだったらEffective Javaくらい読んどけ。
物を知らないにもほどがあるわn

524 ：仕様書無しさん：2013/05/02(木) 00:08:56.04

GoFの時代から継承よりコンポジションって言われてるのに、未だに実装継承万歳
差分プログラミング万歳的な奴を根絶できないな。

525 ：仕様書無しさん：2013/05/02(木) 00:45:55.31

親クラスって共通処理を書くところじゃないんですか？（ぼーよみ

526 ：仕様書無しさん：2013/05/02(木) 00:49:13.50

蜜結合で別にいいだろ
ダメというやつはトレンドに洗脳されてる

527 ：仕様書無しさん：2013/05/02(木) 01:05:13.99

別にステップ実行でテストしたいんなら密結合でもいいよ

528 ：仕様書無しさん：2013/05/02(木) 01:11:16.89

トレンドって、疎結合が良いというのは1970年代位からの共通認識で、もう40年くらいになりますが。

529 ：仕様書無しさん：2013/05/02(木) 01:19:54.91

>>528
だったらなんで80年代や遅くとも90年代までに蜜結合が駆逐されなかったんだ？

530 ：仕様書無しさん：2013/05/02(木) 01:29:28.72

>>529
オブジェクト指向だって1970年代に生まれたものなんだぞ。
そんなに早く普及しない。

531 ：仕様書無しさん：2013/05/02(木) 02:01:11.57

そうか？JavaもPHPもHTMLもjQueryもあっちゅう間に普及したが

532 ：仕様書無しさん：2013/05/02(木) 02:18:31.17

>>531
それらは考え方じゃないもの。

533 ：仕様書無しさん：2013/05/02(木) 04:56:50.69

継承が絶対悪じゃないから駆逐する必要ないじゃん。
継承信仰が良くないだけでしょ。

534 ：仕様書無しさん：2013/05/02(木) 04:58:26.81

is-a関係になっていれば継承でいい。
なってないものに対して継承を使うのが行けない。

535 ：仕様書無しさん：2013/05/02(木) 05:53:46.29

フレームワークは抽象クラスとインタフェースで固めたほうが良いしね。

536 ：仕様書無しさん：2013/05/02(木) 07:12:42.29

俺新参です。よろ。

書き方むかつきますが、疎結合が大切っていう意見は間違いないっすよ。
特に再利用って視点で考えたとき疎結合じゃなきゃ使えないですからね。
テストドライバだって再利用の一形態だから、テストドライバ作ろうとすると
必然的に疎結合が前提になるんですよ。そういう点でも527は正しい。

再利用って観点でみると、再利用できる抽象化された部分と、再利用できない
ベッタリ書く部分に分離することが大事なんですよ。
ここらへんの考えはあまり輸入されてないですが可変性分離というやつですね。

ベッタリ書く部分はファクトリにしたり、ベッタリ書く場所と分離するために
ブリッジで１層かましたり、ラップしたりしてそれ以外の抽象化を助けるんです。
逆に抽象化する部分は抽象クラスやインタフェースをそのまま使うか
DIで具象クラス使うかしなきゃ無理でしょ？

継承は、やりすぎると複雑で制御できないコードがいくらでもかけますからね。
このメソッドがどこから使われるのか、この変数がいつ変わるのか、
基底クラスのメソッドが呼ぶべきか、本当にわかりずらい。
過去動作したコードがオーバーライドによって保障できなくなる可能性もあるし、
コンストラクタで抽象メソッドを使用したら言語によって実行順まで変わってしまう。

要するにクラスによるカプセル化が壊れるんですよ。公開しすぎなんですよ。
じゃあ、公開したインタフェースしか使わない委譲で良いんじゃ？って考えですね。
もちろん、必ずしも同じ使い勝手ではないし、設計の意図も伝わりにくくなるので、
単純に置き換えるべきではないです。

537 ：仕様書無しさん：2013/05/02(木) 07:22:46.55

>>522
newしないほうがいいってのはhas aしろってこと？

538 ：おじゃばさま：2013/05/02(木) 08:11:39.03

>>522
前から言っているがJUnitの試験は、
単体試験としては不十分だ。
その不十分な試験の為に、設計を変える気にはならない。
newしない方がいいって何でだ？

>>523
デザパタはプログラムを分類する学問。
分類学ではレアケースに意味がある。
これをサンプルコード集として使えば、
8割が使えないコードとなり、不要論が出る。
そもそも目的が違う。
EffectiveシリーズはCを騙されて買ったが、
ただの小技集だった。
しかも古くて使えない技がいくつも混じっていた。
薦めた人に文句を言ったら、その人は読んでなかった。

539 ：おじゃばさま：2013/05/02(木) 08:19:02.32

>>525
共通処理ではなく、共通要素だ。

>>534
その通り。

>>535
フレームワークはその通りだが、
通常の部分にもインタフェースを
多用するDIの利点が分からない。

540 ：仕様書無しさん：2013/05/02(木) 08:44:23.62

ステップ実行万能主義か、面白いな
JUnitなんて不完全で、全てのバグを見つけるには
ステップ実行する必要があるから不要ってことか

でもその観点だと、開発効率は動的型言語が最強ってことになるな

静的型チェックなんてJUnitよりも発見可能なバグは限られるし、
どうせステップ実行すればバグは見つかる
型を書くのは時間の無駄

541 ：仕様書無しさん：2013/05/02(木) 08:48:09.10

具象クラスをnewしたら、そこでそのクラスと強固な結合が生じる。
それを防ぐのが、委譲でありオブジェクトコンポジションであり依存性注入だ。
それから、is-a関係だから実装継承してもいいなんて素朴なOO感は1995年頃に死に絶えた。
GoFとEffective Javaを読んでから出直せ。

542 ：仕様書無しさん：2013/05/02(木) 09:24:07.32

あ、さっきの新参です

おじゃばさまは初期のオブジェクト指向に造詣があるようですが、
最新の設計論もその頃と随分変わってきています。
あなたなら「オブジェクト指向のこころ」あたり、難なく理解できるはずなので
お勧めします。2005ですが。
デザインパターンについて学ぶべきものが単なる分類でないことがわかるはず。

単体テストについては、一番の利点はセンシングです。
一度つくったところは将来に渡って保証されるという点が科学的なのです。
バグは単体テストで見つけるべきものとそうでないものとがあります。
単体テストで見つけるべきものに限っても、テスト密度に左右されるので
完璧というものは存在しません。
逆に、テスト密度に関してはステップ実行より利が多いと思います。

newについては、インスタンスを生成する部分はどうしても抽象化できないので
”再利用する部分から分離する”ということは基本です。

543 ：仕様書無しさん：2013/05/02(木) 09:45:02.48

新参です。

説明のために、ちょっと例をつくってみました。
渡されたQueryをOperatorに変更して、Executorを使用してOperatorの
Operateメソッドを呼ぶコードです。

MyGeneratorを変更すると、全く別の操作系を生成できます。
MyExecutorを変更すると、逐次実行や並列実行など必要に応じて切り替えられます。
でもここで具象クラスをnewしたら、このクラスは再利用できないでしょ？
このクラスを再利用したいのであれば、これらnewしてる部分を排除すべきです。
で、newする部分は再利用しないファクトリなどに移動すればOKってことですよね。

public class QueryExecuter
{
public void Execute(Query query)
{
Generator generator = new MyGenerator();
Operation op = generator.Generate(query);

Executor executor = new MyExecutor();
executor.Executoe(op);

myOperationHistoryLog.Add(op);
}
}

544 ：仕様書無しさん：2013/05/02(木) 09:51:59.15

思うんだが、Javaのnew構文ってゴミだな、要らなすぎる
コンストラクタと普通の関数を区別する意味が分からん

コンストラクタを普通の関数のように扱えて、関数を引数に取れれば
ごっついDIコンテナ使わなくても簡単にDIできるのに
さらにデフォルト引数があれば、適当な具象クラスのコンストラクタをデフォルト値にすることもできる

545 ：仕様書無しさん：2013/05/02(木) 10:47:04.94

>>538
> その不十分な試験の為に、設計を変える気にはならない。
テスト容易性は工学の基本ですね。

> デザパタはプログラムを分類する学問。
と、あなたが思ってるだけです。

> 分類学ではレアケースに意味がある。
と、あなたが思ってるだけです。

> これをサンプルコード集として使えば、
> 8割が使えないコードとなり
実践を伴わない机上の空論ですね。

546 ：仕様書無しさん：2013/05/02(木) 17:56:53.57

>>533
is-aとかhas-aとかkind-ofとか見ると、90年代のOO議論を思い出す。
最近はほとんどそんな観点で説明する奴いないんじゃない？

継承してよいのは、リスコフの置換原則(LSP)を満たしている場合に限る。

その場合でも、実装継承すると、自分より上位（親側、規定側）のクラスの変更が
下位クラスに影響を及ぼす場合がある。つまり、その継承ツリー全体の仕様を
壊さないように変更する必要が出てくる。その意味でカプセル化が破られており、
結合度が高くなっている。

というようなことがEffective Javaを始めいろんな書籍に書かれてるから読め＞おじゃば

547 ：仕様書無しさん：2013/05/02(木) 17:59:57.56

それと、DIというとDIコンテナのことしか頭に思い浮かばない奴がまだいるようだが、
DIとDIコンテナは別物だ。
たとえば、ここを読め。
DI (Dependency Injection)とは
http://dann.g.hatena.ne.jp/dann/20080911/p1

548 ：おじゃばさま：2013/05/02(木) 18:17:13.16

>>536
どこをベッタリ書くべきか、
どこを共通化すべきかと言うのが難しい。
最初からインタフェースを定義してしまったら、
構造化時代の共通関数と変わらないだろう。

過去動作したコードがオーバライドにより、
保証できなくなると言うのは、分からない。
過去の呼び出しで使えば、オーバライドの影響はないはずだ。

549 ：おじゃばさま：2013/05/02(木) 18:53:15.46

>>540
JUnitが全てダメと言っているのではなく、
単体試験の代わりにはならないと言っている。
結合試験のリグレッションテストに
使うのは構わない。

>>542
前から言っている通り、コード増大と
メンテナンスの問題が解消しない限り、
単体試験には使えない。
ただ彼らの言う単体試験は、俺の言う結合試験の場合があるから、
それなら構わない。

550 ：新参：2013/05/02(木) 19:16:46.58

最初からインタフェースを定義するのではなくて、
ある処理についてその処理がどういう処理として汎化されるかを追求すると
大抵そのベースはインタフェースか抽象クラスになるわけなんですよ。

例えば構造化時代にif文でごちゃごちゃ分岐してロジックを書いていたものが、
実はそのロジックがあるモデルを更新するサービスとして汎化できるとわかれば
サービスという親と具体的なサービスを提供する各種派生クラスですね。
構造化時代の共通関数と同じなのはヘルパクラスです。

どこをベッタリ書くか、どこを共通化するかってところが設計者の腕の見せ所です。
例えば他社のライブラリを使うところはベッタリ書かなければなりませんが、
そのライブラリのバージョンが変わっても自分のコードを変更したくないですよね。
そういう場合にアダプタをかませてベッタリ書く部分と抽象的な部分を分離したり、
ブリッジで一層置いてベッタリ書く層と抽象的な層を分離するわけです。

オーバーライドされたら過去のコードが動作する保証なんて何もないですよ。
メソッドの仕様から変えられますからね。決まって壊すのは他人ですが。

551 ：おじゃばさま：2013/05/02(木) 19:19:06.06

>>543
面白い処理だが使いどころが分からないし、
クラス設計がオブジェクト指向的でない。
何で処理で分割する？

public class QueryManager
{
public QueryManager(Query query){
なんか生成
}
public void execute(){
逐次処理
}
public void executeThread(){
並列処理
}
}
て、内容変えたければQueryManager継承で、
操作を追加したければ、メソッド追加じゃないのか？

552 ：おじゃばさま：2013/05/02(木) 19:44:30.46

>>546
一回親クラス作ったら修正してはダメとは言ってない。
親クラスの修正が子に影響してまずいなら、
それは親クラスに持たせるのが間違いだ。
子クラスに戻せばいい。
これを繰り返すと最後には適切な位置に収まる。

>>547
読んだが利点は何？
キャッシュサーバ使ってたら、使わなくていいだけか？

553 ：仕様書無しさん：2013/05/02(木) 19:49:49.27

使いどころは明快です。
例えばドメインモデル層の一番上、というような層の境界です。
上位クラス群にモデルを直接変更させて安定性を損ないたくない場合に使用すると便利ですね。
外の層からはクエリーの発行しかできない。変更できるのは自分の層でのみインスタンス化できる
Operatorクラス群のみ。これも単に層やモジュール間でのカプセル化の一種なんですよ。

処理で分割するのは単一責任原則に則ったためです。
オブジェクト指向でないどころか、オブジェクト指向の基本原則の１つですよ～。
そのコードでも良いですよ。違いは分割したかしてないかだけです。

public class SomeClient
{
public void Execute(Query query)
{
IQueryManager manager = new QueryManager(query);
manager.execute();
}
}

ここで主題にしてるのはそこじゃなく、どこで具象クラスをnewするかってことですね。

554 ：新参：2013/05/02(木) 20:19:49.75

あ、553も新参です。

555 ：仕様書無しさん：2013/05/02(木) 20:31:26.07

ほうほう

556 ：新参：2013/05/02(木) 20:57:43.59

あれっすね、
リアルで職場でこの手の話したら引かれるのがオチなんであまりしませんが、
ここに来て結構詳しい人もいるんだなと思いました。ではーノシ

557 ：仕様書無しさん：2013/05/02(木) 21:24:05.86

おじゃばが言う共通要素というのがI/Fだと言うなら、派生ではそれぞれのオーバーライドした
メソッドで似たような少し違うコードが散乱することになる。
そうではなくて、共通処理を基底クラスの方に持っていくというのなら、それは実装継承になる。
つまり、どっちもダメ。

558 ：仕様書無しさん：2013/05/02(木) 21:29:34.14

ガチプロな新参降臨

559 ：仕様書無しさん：2013/05/02(木) 21:30:53.71

じかも、おじゃばの発想では、クライアントは具象クラスをnewすればいいやと
思っているので、もう全然ダメ。

560 ：仕様書無しさん：2013/05/02(木) 21:41:37.50

勉強になるわ

561 ：仕様書無しさん：2013/05/02(木) 21:43:40.77

継承爆発
継承地獄

562 ：仕様書無しさん：2013/05/02(木) 21:49:56.62

オブジェクト指向のこころは俺もお勧め。

563 ：仕様書無しさん：2013/05/02(木) 22:14:07.81

>>562
テンプレマーク

564 ：おじゃばさま：2013/05/02(木) 22:36:43.31

>>550
抽象化が進んだ後からインタフェース定義するなら異存は無い。
他社のライブラリをラップするのも問題ない。
ただ必要になってから変更できるのが、
オブジェクト指向の利点だから、
俺は現在必要のないラッパやインタフェースは作らない。
作らなくても大丈夫なのが、オブジェクト指向だ。

オーバライドでは壊れないだろう？
public class QueryManager{
public void execute(){
処理A
}
}

public class ExManager extends QueryManager{
public void execute(){
処理B
}
}

QueryManager manager = new QueryManager();
manager.execute();
処理Aは保証されているだろう？

565 ：おじゃばさま：2013/05/02(木) 23:44:50.49

>>553
public class SomeClient{
public void Execute(Query query){
QueryManager manager = new QueryManager(query);
manager.execute();
}
}
これがダメで、
public class SomeClient{
public void Execute(Query query){
QueryManager manager = Class.forName("QueryManager");
manager.execute();
}
}
これはOKだと言っている？

>>557
似たグループで階層化すれば、重複を最小限に出来る。

566 ：仕様書無しさん：2013/05/02(木) 23:55:31.77

誰かこの素人つまみ出せよ

567 ：仕様書無しさん：2013/05/03(金) 00:58:23.17

Oh...

568 ：仕様書無しさん：2013/05/03(金) 01:11:57.91

newのべったりはダメで設定ファイルに
べったりはOKってセンスないよ。
はっきりいって設定ファイル直すほうがコスト高いから。
だから俺は疎結合に反対。
疎結合じゃないと再利用できないというのもとんでもない。

569 ：仕様書無しさん：2013/05/03(金) 02:14:42.96

DIコンテナとDIは違うということが何故解らないんだ

570 ：仕様書無しさん：2013/05/03(金) 02:31:29.14

>>547
これかなり勉強になったわ

571 ：仕様書無しさん：2013/05/03(金) 02:40:19.98

>>569
何を使おうが注入のコストはゼロにはならない

572 ：仕様書無しさん：2013/05/03(金) 02:47:02.70

>>565
で、ExQueryManagerを使う似たような処理が必要な場合は、別のnew ExQueryManager()する
コード一式を書くのか？
さらに別のQueryManagerの派生クラスを作る場合、またまたその派生クラス用のクライアント
コード一式を書くつもり？

573 ：仕様書無しさん：2013/05/03(金) 02:48:18.03

>>571
誰がそんな話をした?
DIの話をするときにDIコンテナを使うことを前提とするなということだ。

574 ：仕様書無しさん：2013/05/03(金) 02:53:28.83

クライアントコードで具象クラスをnewするから、デバイスオープンエラーのテストをするのに
実デバイスが必要になったりデバッガーが必要になったりするんだよ。

575 ：おじゃばさま：2013/05/03(金) 09:38:35.47

>>572
managerをフィールド変数にして、
コンストラクタにnewの処理を移動し、
コンストラクタだけオーバライドすれば？

576 ：仕様書無しさん：2013/05/03(金) 10:06:14.58

>>575
SomeClientクラスでnewするなら、コンストラクタでやろうがどこでやろうが同じこと。
あと、コンストラクタをオーバーライドって何だよ？
ひょっとして、ExQueryManagerを使うExSomeClientをSomeClientから派生させるってことか？
糞設計にもほどがあるわ。

577 ：仕様書無しさん：2013/05/03(金) 10:09:14.22

newはどんなときでもダメ、みたいに凝り固まってるやつがいるな

578 ：仕様書無しさん：2013/05/03(金) 10:14:46.83

>>577
どんなときでも駄目とか誰が言ってるんだよ？

579 ：仕様書無しさん：2013/05/03(金) 12:07:40.76

こういう時に、ここはStrategyパターンでしょ、で話が通じる人達と俺は仕事がしたい

580 ：仕様書無しさん：2013/05/03(金) 14:49:44.68

おじゃばの自演で擁護レスしてるのかと思ったが、どうやらおじゃばよりも
相当レベルの低い他人のようだな

581 ：仕様書無しさん：2013/05/03(金) 16:32:51.16

こういう時に、ここはStrategyパターンでしょ、で話が通じる人達に仕事丸投げして帰りたい

582 ：仕様書無しさん：2013/05/03(金) 17:20:48.64

こういう時に、ここはStrategyパターンでしょ、で話が通じる人達に仕事丸投げされた...帰りたい...

583 ：おじゃばさま：2013/05/03(金) 17:52:19.48

>>576
その糞設計だが何が問題だ？
もしSomeClientがQueryManagerを
ラップしているだけなら、
ExQueryManagerを直接使うが。

584 ：仕様書無しさん：2013/05/03(金) 18:09:29.82

糞設計とわかったうえで、何が問題だ？とのたまう。
こいつとは一生分かり合えることはないと思う。

585 ：おじゃばさま：2013/05/03(金) 19:05:44.92

>>584
ExQueryManagerを直接使うなら、
糞設計とは思わない。
で、何が悪い？

586 ：仕様書無しさん：2013/05/03(金) 19:24:22.22

>>583
言っていることがさっぱりわからない。
まずは、コンストラクタをオーバーライドするの意味から説明してくれ。

587 ：仕様書無しさん：2013/05/03(金) 19:28:11.86

>>585
ExQueryManagerを使うクラスは何だ?
YetAnotherQueryManagerが定義されたらどうするのだ？

588 ：おじゃばさま：2013/05/03(金) 19:41:16.30

>>586
public class SomeClient{
protected QueryManager manager;
public SomeClient(Query q){
manager = new QueryManager(q);
}
public void execute(){
処理
}
}

public class ExSomeClient{
public ExSomeClient(Query q){
manager = new ExQueryManager(q);
}
}

しかしただラップするだけなら、ExQueryManagerを
直接編集するがな。

589 ：おじゃばさま：2013/05/03(金) 20:06:24.81

>>587
ExQueryManagerの代りに、
YetAnoterQueryMamagerを使うなら、
ExSomeClientを書き換えるし、
新しく作りたいなら、
ExSomeClientと同じように、
YetSomeClientを作るだろう。

590 ：仕様書無しさん：2013/05/03(金) 20:28:23.53

QueryManager,ExQueryManager,YAQueryManagerがあって、さらに別の
HogeManager,ExHogeManager,YAHogeManagerを使うClientクラスを
作るとき、全ての組み合わせが可能なら9つのxClientクラスが必要になる。
これが、具象クラスをnewする弊害。
そろそろわかってくれないか。

591 ：仕様書無しさん：2013/05/03(金) 20:43:28.57

>>590
横から聞くけど、それってDIまで行かずともファクトリで解決できる弊害だよね？

592 ：仕様書無しさん：2013/05/03(金) 20:48:50.79

>>591
なぜ「DIまで行かずとも」なんて表現をするのかわからない。
コンストラクタかセッターでDIすれば済む話。
生成手段をどうするのかはまた別の話。

593 ：仕様書無しさん：2013/05/03(金) 20:58:10.14

>>592
なぜ、デザパタ時代の方法で既に解決可能なネタがDIがどうのって話で引き合いに出されてるんかな、ってダケ

594 ：仕様書無しさん：2013/05/03(金) 21:18:41.46

>>593
あー、そういうことなら、Strategyパターンにしろでは話が通じない可能性があるから、
クラス外部から依存性を渡すという意味でDIしろと言ってる。
DIという概念はDIコンテナを使うことではないんだということをさんざんこのスレで
言ってきたから、そっちの方が話が通じるかと思って。

595 ：おじゃばさま：2013/05/03(金) 21:35:38.66

>>590
QueryManagerシリーズと
HogeManagerシリーズが543の
ように関連しているなら、
クラスを分けるのが間違いだし、
関連していないならパターンで
必要な処理にはならないだろう。

596 ：仕様書無しさん：2013/05/04(土) 00:06:24.68

>>595
SRPを意識して設計すれば、アプリケーションのどこかで複数のクラスを相手にする
クラスが必ず出てくる。
その相手にするクラスが直交していれば、全ての組み合わせ処理が発生するのは容易に
起こり得る。
その度に、相手するConcrete Class全体を意識してクライアントコードを書くような
設計では駄目だ。仮にその瞬間それで上手くいったとしても、その相手にするクラスの
派生クラスが増えたら、そこで破綻する。つまり、拡張性に乏しいということだ。

597 ：仕様書無しさん：2013/05/04(土) 08:39:17.93

おまえらおじゃばをバカにしたいだけなのか、教えてやりたいのかどっちだ？
前者ならスルーしろ、後者ならコーチングは無理だからティーチングで頼むわ。

598 ：おじゃばさま：2013/05/04(土) 09:25:11.26

>>596
継承の階層化と、コンストラクタへの
オブジェクト渡しで対応出来る。
ただしオブジェクト渡しは出来るだけ避ける事。

破綻どころかこれが適切な継承構造への
ヒントになる。

599 ：仕様書無しさん：2013/05/04(土) 10:33:51.83

>>598
コンストラクタへのオブジェクト渡しをしているということは、オブジェクトコンポジションや
委譲をしているということではないのか？

継承の階層化というのが複数回の実装継承だとするなら、それは避けるべき事態だ。
前述した通り実装継承するとその親子関係に強固な結合が発生し、カプセル化が破られ、
変更に弱くなる。

600 ：仕様書無しさん：2013/05/04(土) 10:46:27.07

設計の美しさにこだわるとどんどん業務から離れて行くのわかってんのかな

601 ：仕様書無しさん：2013/05/04(土) 10:54:42.53

デザインはたーん。

602 ：仕様書無しさん：2013/05/04(土) 11:07:25.42

>>600
世の中を見回してみろ。
継承より委譲、継承よりコンポジション、それが普通。
そして、そういう設計や実装をすることがコストを上げることにはならない。
逆に、テスト工数やメンテナンス工数を押し下げる要因になる。

603 ：仕様書無しさん：2013/05/04(土) 11:12:55.93

GoFのデザインパターンは、よくある設計パターンの暗黙知を形式知にしたものが多い。
言い換えれば、GoFなど知らずともGoFで定義されている設計パターンを使うことが多い
ということだ。
GoFのデザインパターンを何か高尚なものだとか難解な物と思っているのなら、それは
大きな間違い。

604 ：仕様書無しさん：2013/05/04(土) 11:16:27.21

破綻

605 ：仕様書無しさん：2013/05/04(土) 12:26:56.96

さすがに飽きてきた
新ネタないの？

606 ：仕様書無しさん：2013/05/04(土) 18:02:19.15

今までの話をまとめると、本読めってことかな。

607 ：仕様書無しさん：2013/05/04(土) 18:06:30.42

今まで読んだ本でおすすめの書籍ってなんですか？

608 ：おじゃばさま：2013/05/04(土) 23:46:52.90

>>599
コンストラクタのオブジェクト渡しは委譲だな。
ただ委譲を多用すると俺の組み方だと破綻する。
それで破綻しない方法は分からん。

俺のコードを君が書き直せば、
違いが分かるのではないか？
DBアクセスで、
ConnectionManagerはトランザクション管理、
QueryManagerを継承して、
各テーブルアクセスするクラスを
作る設計で作ってみた。

609 ：おじゃばさま：2013/05/04(土) 23:50:38.51

public class ConnectionManager{
public void commit(){}
public void rollback(){}
}
public class QueryManager{
public ConnectionManager connection = null;
public QueryManager(ConnectionManager conn){
connection = conn;
}
public List<Map<String, String>> search(String query){}
public int update(String query){}
}

public class Table1Manager extends QueryManager{
public List<Table1Dao> searchByName(String name){}
}
public class Table2Manager extends QueryManager{
public List<Table2Dao> searchById(String id){}
}
public class Client{
public void execute(){
ConnectionManager conn = new ConnectionManager();
Table1Manager tbl1 = new Table1Manager(conn);
tbl1.searchByName("AA");
Table2Manager tbl2 = new Table2Manager(conn);
tbl2.searchById("10");
conn.commit();
}
}

610 ：仕様書無しさん：2013/05/05(日) 01:42:57.33

有名なデータベースライブラリはよくできているので、直接使うべき。
データベースライブラリをラップして、オレオレデータベースライブラリを
作るってのは初心者が陥る罠。

なぜオレオレでラップするのか、
その理由は既存のデータベースライブラリが複雑だから。
実際は複雑ではなく理由があってそうなっている、
初心者故に単にそのこと理解していないだけ。

オレオレでラップしたものは、既存の必要な機能を備えた
データベースライブラリの劣化版になる。機能が制限される。

後々、それではダメだと気づき機能拡張することになるが、
そうしているうちに、直接使ったほうがいいと気づく。
気づいてオレオレデータベースライブラリを捨てればいいのだが、
あちこちで使い、手遅れになって劣化ライブラリに依存してしまうことも多々ある。

611 ：仕様書無しさん：2013/05/05(日) 01:48:50.32

下手なやつほど、継承を使い柔軟性を無くす。

何かの処理を楽にしたいのであれば
ユーティリティクラスを作れば良い。

継承ツリーにおける個々のクラスは
機能的にシンプルにしておけ

クラスのpublicインターフェースだけを用いて
実現できる処理はクラスに取り付けるのではなく
ユーティリティクラスとして外部にまとめたほうが良い。

612 ：仕様書無しさん：2013/05/05(日) 01:54:13.77

データベースライブラリにかぎらず
既存のライブラリを簡単に使えるだけの
ライブラリを作ろうぜーって
考えはたいてい間違い。

そんなもん作るぐらいなら
ライブラリの使い方を覚えたほうがいい。

613 ：仕様書無しさん：2013/05/05(日) 02:55:26.71

>>610
DBに限った話じゃなくよくある話としてそういうのは有ると思うけれど、
ライブラリの制作側が想定している文化と自分たちの文化が合わない場合には、
ラップし直すことで色々向上する場合もある。

Cを想定したライブラリをC++でラップする場合とかな

614 ：仕様書無しさん：2013/05/05(日) 03:27:46.41

>>613
それはCのインターフェースを
C++のインターフェースに合わせるという意味がある。
この場合、機能的には全く同じ事が出来るようにラップする。

これなら問題ない。

問題といってるのは、標準のライブラリが使いづらい（？）という
理由で、機能を削減したライブラリを作るという考え。
たいてい、削減した機能が制限という形になって帰ってくるだけ。

615 ：仕様書無しさん：2013/05/05(日) 04:33:37.59

「機能を制限することで簡単に使えるようにしてる」のを
「ただ簡単に使えるようにしている」のだと誤解するのが悲劇の始まり

>>614
その定義でいくと機能を追加する目的のラップはOKになるけど、
そこそこプログラミングに慣れた奴が作り始める残念ライブラリって簡略版だけでなく機能追加版とかもあるよな
そうするとスキルやライブラリ設計のまずさに問題の本質が有るようにも思えてくる

何れにしてもライブラリ書いて失敗することで学べることも有るだろうからやらない方が良い、とまでは言いたくないかなぁ…

616 ：仕様書無しさん：2013/05/05(日) 04:49:34.13

>>615
目的が「勉強」ならなんでもやればいい。
既存のライブラリの再実装でも
よく知られたアルゴリズムの再実装でも
勉強になる。

勉強と実務をごっちゃにしないこと。

617 ：仕様書無しさん：2013/05/05(日) 04:53:14.07

>>615
> その定義でいくと機能を追加する目的のラップはOKになるけど、
それもだめ。

性質を変えるラップならいい。
（性質を変えるときに仕方なく機能が変わるのは小さいならば許容範囲）

機能を減らすのは論外。機能を追加するなら
ユーティリティクラスを作ればいい。

有名なライブラリがあるのなら、それをそのまま使う方がいい。
外部では通用しないライブラリしか使えなくなりたくないだろう？

618 ：仕様書無しさん：2013/05/05(日) 04:54:04.95

性質を変えるラップならいい。とは言ったけど
どうしても変えなきゃいけない理由がある場合ね。
そのまま使えるならその方がいい。

619 ：仕様書無しさん：2013/05/05(日) 04:57:30.11

継承が許されるのは、そのライブラリの
普通の使い方として、継承してつかうと
ライブラリの使用例に書いて有る場合のみ。

620 ：仕様書無しさん：2013/05/05(日) 07:46:38.25

>>609
俺はORMっぽいことしないからそんな構造のコードは書かないが、俺ならClientの外側で
connectionを生成し、commitする。そのClientクラスはビジネスロジックであり、MVC
で言えばModel層にあたる。
それ以外で何か議論したいポイントがあるならどうぞ。

621 ：仕様書無しさん：2013/05/05(日) 07:58:26.62

俺の場合、Modelは普通は何も継承せず、コンストラクタにconnectionを渡す。
各Modelはデータベースの構造に基づくものではなく、ビジネスロジックの観点から抽出する。
ordersテーブルがあるからOrdersクラスを作るのではなく、注文を操作するクラスが必要だから
Ordersクラスを作る。
なので、各Model間でfindById等の同じメソッドは必要ない。
そもそも、サロゲートキーが無い場合もあるのだし。
だからと言って、ORMを否定するものではないよ。

622 ：おじゃばさま：2013/05/05(日) 09:23:34.25

>>621
public class Order{
private ConnectionManager connection = null;
public Order(ConnectionManager conn){
connection = conn;
}
public void search(){
QueryManager manager = new QueryManager(connection);
manager.search("select...T1");
manager.search("select...T2");
connection.commit();
}
}

public Client{
public void execute(){
ConnectionManager conn = new ConnectionManager();
Order order = new Order(conn);
order.search();
}
}
こうか？

623 ：仕様書無しさん：2013/05/05(日) 11:12:19.13

>>622
何かの前提があってConnectionManagerとQueryManagerを分けてるんだろうが、
俺なら同一のクラスにする。
何らかの理由でQueryManagerが必要なら、Ordersのコンストラクタでnewするか、
引数で貰う。
あと、commitはOrdersではやらない。
ということを除けば、およそそんな感じ。

624 ：おじゃばさま：2013/05/05(日) 13:16:52.78

>>623
public class QueryManager{
public void commit(){}
public void rollback(){}
public List<Map<String, String>> search(String query){}
public int update(String query){}
}
public class Order{
private QueryManager manager = null;
public Order(QueryManager mgr){
manager = mgr;
}
public void search(){
manager.search("select...T1");
manager.search("select...T2");
}
}
public Client{
public void execute(){
QueryManager manager = new QueryManager();
Order order = new Order(manager);
order.search();
manager.commit();
}
}
こうか？

625 ：仕様書無しさん：2013/05/05(日) 14:10:10.50

>>624
ちょっと違うがまあそんな感じ。
ところで、何か議論したいことあるの？

626 ：おじゃばさま：2013/05/05(日) 14:28:43.96

>>625
newの使いどころと、委譲と継承の使いどころだろ。

627 ：仕様書無しさん：2013/05/05(日) 14:48:57.16

>>626
今回の俺のコメントで何か質問があるならどうぞ。

628 ：仕様書無しさん：2013/05/05(日) 15:21:20.75

「これからコードを書く人」が置いてけぼりになってますが、その辺はいかがいたしましょうか？

629 ：仕様書無しさん：2013/05/05(日) 15:55:48.33

こいつらをすべて隔離スレ送りにしてください

630 ：仕様書無しさん：2013/05/05(日) 16:14:45.41

新しいネタどうぞ

631 ：仕様書無しさん：2013/05/05(日) 18:15:13.29

そもそも当然のようにJava前提で考えてる奴らがなんて言うかアレなんだよなぁ・・・
「これからIT土方になる人に」では無いんだぞ的な思いが

632 ：おじゃばさま：2013/05/05(日) 19:23:54.47

>>627
QueryManagerを継承（委譲）する
場合はどうする？

633 ：仕様書無しさん：2013/05/05(日) 19:51:43.64

お前まだいたの
いい加減巣に帰れ

634 ：仕様書無しさん：2013/05/05(日) 19:59:13.73

>>632
質問の意味がよくわからない。

635 ：おじゃばさま：2013/05/05(日) 20:30:41.76

>>634
じゃ、QueryManagerを非同期処理
にする場合はどうするか。
ちなみにsearch()もupdate()も非同期にするとする。

636 ：仕様書無しさん：2013/05/05(日) 20:40:09.73

もうめんどくせぇーからjavaネタだけ隔離すっかこれ

637 ：仕様書無しさん：2013/05/05(日) 22:09:14.05

>>635
質問の意図がわからない。
newする場所と継承と委譲の使いどころに関して疑問が無いのなら、この話はもうこれで終わり。

638 ：仕様書無しさん：2013/05/05(日) 22:11:12.66

>>636
いちいちうざいわ。実質このスレはもうおじゃばの話題しかないだろ。
嫌だったらNG登録して、新しいトピックふれよ。

639 ：おじゃばさま：2013/05/05(日) 22:37:53.54

>>637
どう見ても、継承と委譲の使いどころの質問だろう。

640 ：631：2013/05/05(日) 23:41:06.16

>>638
スレタイの趣旨から掛け離れてるネタを使ってまで維持する必要はねぇよ
俺もjavaネタ隔離には賛成

641 ：仕様書無しさん：2013/05/05(日) 23:51:19.70

>>639
だから、質問の意図がわからないんだって。
本当に俺に何かを聞きたいのなら、表現を変えてくれ。
まさかとは思うが、Clientクラスがデータベースアクセス処理を委譲しているのに
気づいてないなんてことはないよな？

642 ：仕様書無しさん：2013/05/05(日) 23:52:39.31

あ、間違えた。
最新のコードでは、処理を委譲しているのは、ClientクラスじゃなくてOrdersクラス。

643 ：仕様書無しさん：2013/05/06(月) 01:03:08.52

おじゃばには構うなよ。ここは質問スレでもない。
気になってレスしてしまう阿呆はNG登録機能の使い方から勉強しなおせよ。

>>610
その意見には大方賛成だけど、(DBに限らずもっと広い意味での)ライブラリがDIに向いてないからラップするとか、
メンバー全体の質的な問題でラップするとかはやるから、ライブラリを直接使えない仕組みが一概にダメとは言えないと思うな。
今後の拡張性も考えた上で、使う機能が限定されてるのがわかっているなら、
ライブラリに依存しない実装としておいたほうが影響範囲が狭くなるし、ようは実装者の設計次第だと思うよ。

直接使うとライブラリとの依存が切れなくなって、ライブラリ自体に変える必要が出た時に痛い目みるし、
俺々の問題と同じ悲しい結果を生む場合もあるわけだから、一概にどっちがNGとは言えない。

自分のとこでそういう糞な俺々ライブラリにイライラさせられて愚痴ってるとかなだけならいいけど、
本気でライブラリが絶対だって思ってるなら、それはちょっと視野狭くなってると思う。

644 ：仕様書無しさん：2013/05/06(月) 01:06:08.93

スレ趣旨にあった話題といえば、継承より委託ってのを出来るだけ徹底してほしい、とかかな。
同じような業務的な機能は、ユーティリティやDIコンポーネントとして実装して、
使いたいところではその処理に委託するようにしよう。

継承は、複数のクラスに共通処理を持たせるための仕組みではない。
継承ベースの実装はちゃんとテストするのに向いていないから、やるべきじゃない。

645 ：仕様書無しさん：2013/05/06(月) 01:16:10.90

>>643
俺は一貫して疎結合の大切さや、継承より委譲する構造、テスト容易性、継承の前提条件
なんかを話していて、その流れでおじゃばにもコメントしてるが、嫌ならお前がNG登録
しろよ。連鎖で俺のコメントも見えなくなるから。

ちなみに俺は>>610から始まる話題には一切興味が無いが、止めろとは思わないよ。
ただ読み飛ばすだけ。

646 ：仕様書無しさん：2013/05/06(月) 01:22:18.04

おじゃばはクラスをnewしてるけど
そこがなぜダメかは誰も指摘できてないよな
結局蜜結合でもいいんじゃん

647 ：仕様書無しさん：2013/05/06(月) 01:26:03.30

>>645
お前はスレタイを百回読みなおすべきだと思う
Javaのお勉強スレじゃねぇぞここは

648 ：仕様書無しさん：2013/05/06(月) 01:30:49.15

>>647
俺はJavaに特化した話はほぼしてないが。
したのはDIとDIコンテナの話だけ。
おじゃばがJavaプログラマでJavaのコードを書いてるだけ。

649 ：仕様書無しさん：2013/05/06(月) 01:33:34.06

どうこういっても、結局Java使ってる人多いのね

650 ：仕様書無しさん：2013/05/06(月) 02:32:03.22

もう全部Rubyで書きたい

651 ：おじゃばさま：2013/05/06(月) 04:28:20.35

継承より委譲、newよりDIと言うのを、
具体的なコードを例に解説してもらってるのだから、
スレの趣旨からは逸れてないだろう。
Javaのコードでは分からないのか？

652 ：おじゃばさま：2013/05/06(月) 04:41:28.75

>>641
委譲により変更に強いコードになっているのだろう？
ここでクラスに影響するような変更、
例えば「処理を並列化する」のような物が入った場合、
どのように修正するのかという事だ。
俺ならQueryManagerを継承して、
並列処理版のQueryManagerを作るが、
委譲ではどうするのかという事だ。

653 ：おじゃばさま：2013/05/06(月) 04:53:02.07

newについても、ビジネスロジック内の物については許容なのか、
全部非許容なのか後で聞くつもり。
DIコンテナ推奨の人は、全部非許容らしいから、
どうやって組むのか興味があるだろう？

654 ：仕様書無しさん：2013/05/06(月) 06:42:20.22

>>651
応用は利くにしても
DI ∈ Java文化圏 ∈ オブジェクト指向プログラミング一般 ∈ プログラミング一般
な話をしてるだろあんたら

他所でやれ

655 ：仕様書無しさん：2013/05/06(月) 08:15:19.71

一人芝居かと思えるくらいのスレチででかい顔されてもな
両方まとめて他所でやれよってレベル

656 ：仕様書無しさん：2013/05/06(月) 08:36:02.77

>>645
わかったから続けるなら次からコテつけてくれ。

657 ：仕様書無しさん：2013/05/06(月) 09:03:18.25

>>628書いたの俺なんだが、まだやるなら相応のスレ立てればいいのにってのが伝わらないのだな
ってことは伝わった

658 ：641：2013/05/06(月) 09:45:41.15

>>652
まだ質問の意味がよくわからない。Ordersからデータベースアクセス部分が委譲により
切り離され、変更に強くなったじゃないか。
QueryManagerを継承したいならすればいい。そこに何か疑問があるのか？

因みに、非同期版AsyncQueryManagerはおそらくLSPに違反するので、継承ではなく
別の手段をとった方がいいとは思う。どういう手段が良いのかは、言語や実行環境に
よるので、完全にスレ違いな話になる。
NoSQLやmemcached等を使ったCachedQueryManagerなら、継承しても良いと思う。

659 ：仕様書無しさん：2013/05/06(月) 09:47:48.14

最初はおじゃばを叩いてたやつらが
おじゃばが優勢になったら「よそでやれ」
どんだけ卑怯なんだか

660 ：仕様書無しさん：2013/05/06(月) 09:51:11.40

はぁ？
いつ優勢になったの？

661 ：641：2013/05/06(月) 09:56:03.41

>>653
どこでnewすべきかはケースバイケースだが、今回のQueryManagerに限れば、それは
ビジネスロジック層の外側だと言っておこう。ビジネスロジック層の内側でQueryManagerを
固定してしまっては、CachedQueryManagerに付け替えることができない。

尚、俺はDIコンテナを使えとは言ってないし、DIコンテナを使う場合にどうすべきかという
話題にも興味がない。

662 ：641：2013/05/06(月) 09:57:23.89

このスレでは641を名乗るので、見たくなければNG登録しろ。
つか、連鎖あぼーんできるブラウザ使えや。

663 ：おじゃばさま：2013/05/06(月) 17:41:51.45

>>658
継承してもいいって事は、
全部委譲って話ではないのか？

newがビジネスロジックの外という事は、
Clientにもコンストラクタのオブジェクト渡しか？
俺は反対だな。
基本的に変数のスコープを最小にすべきだろう。
QueryManagerをnewしても変更できない事は無い。
単にnew QueryManagerを
new CashedQueryManagerに変えるだけだ。

664 ：仕様書無しさん：2013/05/06(月) 18:16:44.04

> Clientにもコンストラクタのオブジェクト渡しか？
違う

> 俺は反対だな
何に反対してるんだ？

665 ：おじゃばさま：2013/05/06(月) 18:53:22.01

>>664
オブジェクト渡しを多用するのは反対だ。
それこそカプセル化が崩れるだろう。

666 ：仕様書無しさん：2013/05/06(月) 19:08:36.01

>>665
いや、だから、オブジェクト渡しを多用しないって言ってるの。

お前は自分の意見に、自分で反対してるだけだよ。

667 ：仕様書無しさん：2013/05/06(月) 19:14:15.37

>>664 >>666
持論を展開せず相手の発言を指摘するばかりでズルいね
俺もだけどw

668 ：仕様書無しさん：2013/05/06(月) 19:18:07.07

2ちゃんねるで持論を展開とか、キチガイのすること
一方的に難癖つけて叩くのが２ちゃんねるの楽しみ方

669 ：仕様書無しさん：2013/05/06(月) 19:18:18.73

え？だってnewがビジネスロジックの外でしょ？
それってDIのことでしょ？

なんでコンストラクタで渡すのさ。
間違いじゃない。

670 ：641：2013/05/06(月) 19:20:38.82

>>663
デザインパターンを勉強しないから、そんな頓珍漢なこと言うんだよ。

後半は何言ってるのかさっぱり意味不明。

671 ：仕様書無しさん：2013/05/06(月) 19:29:57.49

みんなの意見。赤がいいね。

おじゃばの意見

白じゃないってことは
黒なのか？
俺は黒には反対だな。

672 ：仕様書無しさん：2013/05/06(月) 19:31:07.81

>>671
こういう言葉遊びができる人憧れちゃう。

673 ：おじゃばさま：2013/05/06(月) 21:28:37.13

>>670
キャッシュ付きのQueryManagerに変更したければ、
QueryManagerを継承し、
CashefQueryManagerを作り、
public class Order{
：
public void search(){
CashedQueryManager manager = new CashedQueryManager(connection);
manager.search("select...T1");
manager.search("select...T2");
connection.commit();
}
}
に変更すれば良いと言っている。

674 ：おじゃばさま：2013/05/06(月) 21:37:32.07

>>671
Javaのコードぐらい読めるようになってくれよ。

675 ：641：2013/05/06(月) 22:27:33.33

>>673
わざとやってるのか?
>>624から後退してるじゃないか。元々の目的は、OrderクラスがQueryManagerを継承したり
newして密結合になるのをさけるということだったんだが、そこから理解できてないのか？
あと、委譲がどういうことかわかってないんじゃないか？
ポリモーフィズムは分かってるよな？

あと、OCP(Open Closed Principle)でググって、変更に強いコードとはどういうものか
勉強しろ。

676 ：仕様書無しさん：2013/05/06(月) 22:31:24.09

ふっふっふどうやら>>674が
コード読めるようになれだったようだな。

677 ：仕様書無しさん：2013/05/06(月) 23:10:54.78

ひょっとして、QueryManqgerを継承してCashedQueryManagerを作ったら、
new Order(new CashedManager())すればいいってことがわかってないんじゃ？

678 ：仕様書無しさん：2013/05/06(月) 23:14:54.50

JavaがダメともDIに関する議論がダメとも思わないが
各論を延々とやられるのはきついな

679 ：仕様書無しさん：2013/05/07(火) 00:40:33.74

おじゃばスキルレベルが低すぎるので、いつまでやっても話が噛み合わないと思うぞ >641

680 ：仕様書無しさん：2013/05/07(火) 01:11:35.25

641がコードを示せばいいのに

681 ：641：2013/05/07(火) 02:15:59.82

>>680
なんかコード書かないとわからないことでもある？

682 ：仕様書無しさん：2013/05/07(火) 03:19:41.78

説明しても理解してないっぽいからコード提示して考えさせろ
という意味では？

683 ：仕様書無しさん：2013/05/07(火) 04:47:17.43

>>659
どっちが優勢だろうがどっちみちスレチなんで両方よそ行ってくれ・・・

684 ：おじゃばさま：2013/05/07(火) 08:19:36.95

>>675
いや結合度を下げるのが目的ではなくて、
変更に強いコードを作るのが目的だろう。
実際にコードを書いてみて、変更してみれば分かると思って
やっているのだが。

685 ：仕様書無しさん：2013/05/07(火) 08:37:18.37

じゃあその考えはくだらないので捨ててくれ

686 ：仕様書無しさん：2013/05/07(火) 13:35:44.65

・・・誰も何も話すことないじゃんw

687 ：仕様書無しさん：2013/05/07(火) 15:52:00.58

まぁ、普通の勤め人は今仕事中ですし

688 ：仕様書無しさん：2013/05/07(火) 15:54:07.91

ところで、おじゃばってなんでsageないの？
知らないの？

689 ：仕様書無しさん：2013/05/07(火) 18:40:25.97

目立ちたがりのバカだから

690 ：仕様書無しさん：2013/05/07(火) 18:42:39.98

sageていないレスが見えている奴も相当のバカだけどな

691 ：おじゃばさま ◆.CzKQna1OU ：2013/05/07(火) 22:18:48.22

>>685
一体どういう順序で勉強してるんだ？

692 ：仕様書無しさん：2013/05/08(水) 01:27:03.11

こんなスレで「勉強」しないでくれ
わかってる上で議論ごっこするならまだしも…

はい、次。

693 ：仕様書無しさん：2013/05/08(水) 01:51:09.83

安全なところから攻撃してる名無しがやたらと偉そうなスレ

694 ：仕様書無しさん：2013/05/08(水) 02:39:43.01

自己紹介ですか

695 ：仕様書無しさん：2013/05/08(水) 15:38:37.47

いろいろひどいな

696 ：仕様書無しさん：2013/05/08(水) 17:44:32.94

やれやれ

697 ：おじゃばさま ◆.CzKQna1OU ：2013/05/08(水) 18:38:48.08

オブジェクト指向プログラミングは
俺の書いた基礎だけでも実現可能で、
十分恩恵を受ける事が出来る。
基礎を習得した後であれば、
デザインパターンは理解を深める材料になるが、
いきなりデザインパターンを学習するのは、
避けた方がいい。

デザインパターンには言語に組み込まれている物や、
用途の限定されている物、
オブジェクト指向の制約を回避してしまう物もあり、
無制限に使えば、混沌としたコードになるだろう。
俺の知る限りではJavaで有用なのは、
シングルトンぐらいだ。

さらにオブジェクト指向の書籍の中には、
未だに大量の誤訳がある。
これは翻訳者がプログラミングを知らないために発生する問題で、
記載された内容がオブジェクト指向の
原則に反するならば、訳を疑う必要がある。

698 ：おじゃばさま ◆.CzKQna1OU ：2013/05/08(水) 18:54:10.17

オブジェクト指向の利点は、変更により
コードが洗練され行く事だ。
原理は単純で、共通要素が親クラスへ分離され、
オーバライドにより既存の機能が壊れない事による。
もし修正でコードが破綻するようであれば、
それはオブジェクト指向プログラミングではないという事になる。

699 ： ◆.CzKQna1OU ：2013/05/08(水) 19:47:40.33

やれやれ

700 ：仕様書無しさん：2013/05/08(水) 21:01:09.80

まあ結局>>609程度のコードしか書けないってばれちゃってるんですけどね

701 ：おじゃばさま ◆mpgYduuqtA ：2013/05/08(水) 21:46:16.05

>>700
Java読めるようになったか？

702 ：仕様書無しさん：2013/05/08(水) 22:16:06.39

なんか痛々しいわ
何が彼をそうさせるのか

703 ：仕様書無しさん：2013/05/08(水) 23:10:58.29

何故コードばかりで人は洗練されていかないのだろうか？

704 ：641：2013/05/08(水) 23:37:29.23

さすがの俺でも、あきれて物が言えないレベル。

705 ：仕様書無しさん：2013/05/09(木) 00:19:41.78

話をよく知らないけど701を見て「こんなふうに憶測で人をなじりはじめたら人としておわり(かけ)だよね」ってしみじみ思った

706 ：仕様書無しさん：2013/05/09(木) 00:22:01.97

よく知らないことに首突っ込むようなアホにはなりたくないなあと思いました

707 ：仕様書無しさん：2013/05/09(木) 02:55:15.00

>>700がそれまで話に絡んできた誰かではなく只の単発であれば>>700と>>701だけで十分じゃね？

708 ：仕様書無しさん：2013/05/09(木) 07:42:18.32

本当おまえらって偉そうだな
少しプログラムかけるだけでここまで人を見下せるかね

709 ：おじゃばさま ◆mpgYduuqtA ：2013/05/09(木) 08:14:50.25

>>704
それだけか？
コードは？

710 ：641：2013/05/09(木) 08:36:36.52

>>709
もう、君と会話するモチベーションがほぼゼロなんだけど、俺から何かを引き出したいんだったら
少なくともきちんとした文章で質問してくれよ。
コードが一体何だって言うんだよ。

711 ：仕様書無しさん：2013/05/09(木) 12:45:12.58

お前はアホか
一度相手したなら最後まで責任持て
こういうヤツと仕事したくねえわ

712 ：641：2013/05/09(木) 12:57:28.93

相手するのやめろとか、最後まで責任もてとか、まあいろんな意見がありますが。

結論：俺の勝手

713 ：おじゃばさま ◆mpgYduuqtA ：2013/05/09(木) 18:21:46.55

>>710
609が俺のコード。
624が君の言う通りに修正したコード。
624に機能追加して、本当に修正が簡単か検証する。

だから、624にキャッシュ機能を
追加したコードを書いてくれ。
もし624自体が根本的に気に入らないなら、
609と同じ機能を持つコードを
新たに書いてくれてもいい。

714 ：仕様書無しさん：2013/05/09(木) 18:39:06.08

類い稀なる糞スレ

715 ：641：2013/05/09(木) 18:41:16.08

>>713
> だから、624にキャッシュ機能を
> 追加したコードを書いてくれ。

いやだからその質問の意味がわかんないんだって。QueryManagerを継承するだけでしょ？

public class QueryManager{
　// 変更なし
}

public class CachedQueryManager extends QueryManager {
　public List<Map<String, String>> search(String query) {
　　// キャッシュにあればそれを戻し、なければDBを検索する
　}
　public int update(String query) {
　　// キャッシュとDBを更新する
　}
}

public class Order {
　// 変更なし
}

public Client{
　public void execute(){
　　Order order = new Order(new CachedQueryManager());
　　// あるいは、new Order(QueryManagerFactory("CachedQueryManager"))とか
　　order.search();
　　manager.commit();
　}
}

716 ：641：2013/05/09(木) 18:45:21.22

あ、manager.commit()を消し忘れた。
commit必要無いだろ。

717 ：おじゃばさま ◆mpgYduuqtA ：2013/05/09(木) 19:07:42.46

>>716
Client.execute()内はトランザクションで、
複数の検索や更新が入るイメージだから、
commit()は必要。

そうなると、俺の修正とあまり変わらないな。
継承ではなく委譲、newではなくDIとか言っていたのは、
別の人か？

718 ：641：2013/05/09(木) 20:20:44.67

>>717
他の人も言ってたが俺も言ってた。
俺が書いたコードの説明はもうしないよ。
君の変更と俺の変更がそれほど違わないと思うんならそれでいいよ。
正直、君に説明するのもう疲れたし。
勉強するための書籍名とかキーワードは既に言ってるから、勉強する気があるなら勝手にやって。

719 ：仕様書無しさん：2013/05/09(木) 21:36:09.70

投げるなら最初から相手せんでくれ
迷惑極まりない

720 ：641：2013/05/09(木) 22:04:03.13

>>719
もうかなり前に全て説明済みだ。
それがわからないなら、お前もおじゃば並みということだな。
我ながら忍耐強かったよ。

721 ：仕様書無しさん：2013/05/09(木) 22:22:23.49

お前が最初から相手しなかったら周りにも余計な手間を掛けずに済んでたんだけどな

722 ：641：2013/05/09(木) 22:48:42.35

NGしとけよ。

723 ：仕様書無しさん：2013/05/09(木) 23:26:26.47

最初からおじゃばとかまじめに相手すべき相手じゃなかったわけだし、
「もう、君と会話するモチベーションがほぼゼロ」
なら後に続けるのはよりgdgdになるだけだよ

724 ：仕様書無しさん：2013/05/09(木) 23:42:21.49

>720
わかるわからないじゃない
最初から相手するなと言ってるんだよ
それがわからないとかどんだけアホなんだお前

725 ：仕様書無しさん：2013/05/10(金) 00:23:32.36

>>710
俺から何か引き出したかったら、とかすごい偉そうだな
会社でうまくやれてるか？浮いてないか？

726 ：おじゃばさま ◆mpgYduuqtA ：2013/05/10(金) 07:42:13.32

>>720
コードを見る限りでは、継承もnew
も使っているから、
継承よる委譲、newよりDIなんて
全く分からないな。

727 ：641：2013/05/10(金) 07:54:57.18

>>726
・データを取得したりドメインロジックを実装するOrderクラスは何も継承していない。
・newしてはいけないというのは、あるクラスの直接のクライアントコードの話。今回の場合は、QueryManagerの直接のクライアントであるOrderクラス。
・Orderクラスは、データアクセス処理を委譲している
・前に紹介したDIに関するページをあと10回読め
・OCPについて調べろ
・おしまい

728 ：おじゃばさま ◆mpgYduuqtA ：2013/05/10(金) 19:38:55.03

Client.execute()内でのmanager.commit()が不要だと言っていたが、
トランザクションがOrder.search()
内で閉じていて、
commit()が不要になったとしても、
委譲にするのか？

729 ：仕様書無しさん：2013/05/11(土) 03:51:14.09

別の目的のスレを私物化する荒らし行為はいい加減にしてくれ。
嫌なら見るなって叫びながら糞の掛け合いするとかアホか。そんなに乳繰り合いたいならスレたててそこでやれよ。
おじゃばはもとより、641もそんなこともわからないくらい頭悪いの？

730 ：仕様書無しさん：2013/05/11(土) 05:02:05.92

んじゃお前がスレたててやれよ

731 ：おじゃばさま ◆mpgYduuqtA ：2013/05/11(土) 07:05:32.47

つまり上位でメソッドを使用する
必要がない場合でも、
public class Order{
private QueryManager manager = null;
public Order(QueryManager mgr){
manager = mgr;
}
}
にするのか？
上位でnewするだけなら、
public class Order{
private QueryManager manager = null;
public Order(){
manager = new QueryManager();
}
}
と同じではないのか？

732 ：仕様書無しさん：2013/05/11(土) 09:00:32.98

>>731
なんの恨みで荒らしてるの？

733 ：おじゃばさま ◆mpgYduuqtA ：2013/05/11(土) 10:48:22.16

>>732
これからコードを書く人に、
「継承より委譲、newよりDIにすべき」
という話が出たから、
本当にそうか検証しているのだが。

734 ：仕様書無しさん：2013/05/11(土) 10:55:27.16

>>733
それなら筋が通ってるな
俺もDI押し付けてくるやつ好きじゃないし

735 ：仕様書無しさん：2013/05/11(土) 11:42:03.61

>>733
ほうほう、規制されてたから途中までしか見ていなかったけど、目的自体は存在するのね。
であれば「継承より委譲、newよりDI検討スレッド」で検討して、その結果をここに書き込んでいただけないですかね？

確かに初心者にいきなり三段飛ばしを強要するクズは死んだ方がいいとは思うけど。
せっかくの良スレが、その話題だけで埋め尽くされてしまってるのは惜しいので。

736 ：仕様書無しさん：2013/05/11(土) 12:15:38.13

ゴミスレがほとんどのマ板の中じゃ、珍しくまともな話題じゃん。
このスレだって前スレはひどいもんだったぞ？
文句ばっか言ってないで新しい話題でも出せや、ゴミクズが。

737 ：仕様書無しさん：2013/05/11(土) 12:45:39.68

とゴミクズが申しております。

738 ：仕様書無しさん：2013/05/11(土) 12:46:32.74

コンストラクタとかある時点でニセモノのOOじゃんw

739 ：仕様書無しさん：2013/05/11(土) 12:48:11.39

最適な解はゲースによって変わってくるし、どちらにもメリット・デメリットがあるのくらい少し調べりゃわかるじゃん
どっちか一方が正で他方は悪みたいな01で決めつけしかできないレベルの頭の奴が、こういうのを語る意味は無いよ

740 ：仕様書無しさん：2013/05/11(土) 12:49:24.47

>>739
ゲースってなんだよIMEぶっこわれてんのか

はあしの

741 ：仕様書無しさん：2013/05/11(土) 12:57:11.81

>>736
なぜ「ひどいもん」になるんだろうかね。
ここも途中からは「ひどいもん」だしね。

なんか言えと言われたので、これからコードを書く人へ。

先人に学べ。
他人も自分も信用するな。
論理を信じろ。
目的を見失うな。
あらゆる立場や視点で物事を見ろ。
完璧を目指せ。
完璧だと思うな。
気楽にやれ。

742 ：仕様書無しさん：2013/05/11(土) 12:57:12.74

まあJavaのプロジェクトは重厚なフレームワークの組み合わせが多すぎるからな
初心者がキャッチアップするには相当な苦労をかけさせることになる

743 ：仕様書無しさん：2013/05/11(土) 13:04:05.55

>>741
途中からって、前スレからほぼひどいもんだったじゃん。
なぜそうなるかって?
そういう奴らしかこのスレにはいないからだ。

744 ：仕様書無しさん：2013/05/11(土) 13:09:41.37

>>743
ごめん、前スレ見た事ないんだｗ

745 ：仕様書無しさん：2013/05/11(土) 13:11:07.70

>>743
空気読めない奴が多いって事か。
この業界全体にいるよな、そういうがん細胞みたいな奴。

746 ：仕様書無しさん：2013/05/11(土) 17:33:28.48

結局おじゃばの話題しかしてないじゃんwww

747 ：仕様書無しさん：2013/05/11(土) 18:35:48.91

そうでゲースなぁ

748 ：おじゃばさま ◆mpgYduuqtA ：2013/05/11(土) 18:46:20.43

空気は見えないので読めません。

749 ：仕様書無しさん：2013/05/11(土) 19:02:31.58

>>748
小学生かよ…

750 ：仕様書無しさん：2013/05/11(土) 20:04:02.55

641はどこいった

751 ：641：2013/05/11(土) 21:35:55.42

俺に何か用か？

752 ：仕様書無しさん：2013/05/11(土) 21:37:40.73

別スレたてろ

753 ：641：2013/05/11(土) 22:05:09.24

別に、俺の主張が正しいかどうかとか、違う意見の人と議論したかったわけじゃなくて、
単におじゃばが俺の意見を理解出来なかったから説明してただけ。
なので、どこか別スレでこの話題を続けるつもりもない。
おしまい。

754 ：仕様書無しさん：2013/05/11(土) 22:14:51.59

お前が相手する必要ねえから
手をつけた責任とって別スレたてろって話だろ

755 ：641：2013/05/12(日) 07:30:11.38

どういう話だか知らないが、いずれにせよ断る。

756 ：仕様書無しさん：2013/05/12(日) 14:13:04.76

お前に断る権利は無い

757 ：641：2013/05/12(日) 14:30:33.86

気持ち悪い

758 ：仕様書無しさん：2013/05/12(日) 14:50:37.69

自己否定か…

759 ：仕様書無しさん：2013/05/12(日) 20:07:29.12

メモ
>>6
>>23
>>36-38
>>40

760 ：仕様書無しさん：2013/05/12(日) 21:38:09.74

>>759
メモのメモ

761 ：仕様書無しさん：2013/05/13(月) 06:45:41.62

ワロタ

762 ：仕様書無しさん：2013/05/13(月) 12:57:46.03

>>40から抜粋
・凝集度
・疎結合
・重複なし
・カプセル化
・テスト容易性
・可読性
・フォーカス

763 ：仕様書無しさん：2013/05/13(月) 12:59:58.15

>>40から抜粋
オブジェクト指向設計の原則
・単一責任の原則
・オープン･クローズドの原則
・リスコフの置換原則
・依存関係逆転の原則
・インターフェース分離の原則

764 ：仕様書無しさん：2013/05/13(月) 13:06:28.62

>>40で引用または紹介されている書籍。

『ThoughtWorksアンソロジー―アジャイルとオブジェクト指向によるソフトウェアイノベーション』
http://www.amazon.co.jp/dp/487311389X

『アジャイルソフトウェア開発の奥義』
http://www.amazon.co.jp/dp/4797323361

『Clean Code アジャイルソフトウェア達人の技』
http://www.amazon.co.jp/dp/4048676881

『プレファクタリング ―リファクタリング軽減のための新設計』
http://www.amazon.co.jp/dp/4873112729

『リファクタリング―プログラムの体質改善テクニック』
http://www.amazon.co.jp/dp/4894712288

『パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法』
http://www.amazon.co.jp/dp/4822282384

765 ：仕様書無しさん：2013/05/13(月) 13:59:26.76

>>762-764
これからコードを書く人向けじゃなくて、OOP歴1,2年向けだね

766 ：仕様書無しさん：2013/05/13(月) 20:51:37.04

神スレやん

767 ：おじゃばさま ◆mpgYduuqtA ：2013/05/14(火) 08:03:54.85

>>753
731の回答は？

768 ：仕様書無しさん：2013/05/14(火) 16:11:01.62

まだやってんのかよ

769 ：おじゃばさま ◆mpgYduuqtA ：2013/05/14(火) 18:02:38.64

他にネタないようだし、問題ないだろう。
764が答えてもいいぞ。
それだけ本読んでるなら、その成果を
見せてくれよ。

770 ：仕様書無しさん：2013/05/14(火) 18:14:21.10

もっと下手にでろよカス

771 ：おじゃばさま ◆mpgYduuqtA ：2013/05/14(火) 18:15:45.75

>>770
お願いします、教えて下さい。

772 ：764：2013/05/14(火) 18:16:29.52

>>769
まぁ、俺641なんだけど、君の疑問にはもう答えないよ。あきらめて。
プログラム板のJava関連スレにでも行って、持論展開してみれば？

773 ：仕様書無しさん：2013/05/14(火) 19:58:32.05

コーディングだけじゃなくスルースキルも身につけたほうがいいってことがわかるスレだった

774 ：仕様書無しさん：2013/05/14(火) 21:05:14.30

笑える

775 ：仕様書無しさん：2013/05/15(水) 00:02:34.85

悲惨すぎて笑えない

776 ：仕様書無しさん：2013/05/15(水) 00:31:22.72

ちょっと度が過ぎてるよな…

777 ：仕様書無しさん：2013/05/15(水) 01:22:48.72

議論したいならJavaスレ行くかスレたてればいいのに。
いつまでここでやってるんだ。

778 ：仕様書無しさん：2013/05/15(水) 02:02:43.93

かまってくれる人がいるうちだろ
死ねばいいのに

779 ：おじゃばさま ◆mpgYduuqtA ：2013/05/15(水) 07:26:22.06

>>772
じゃあ俺がオブジェクト指向における
モジュール分割の基礎を教えてやるよ。

780 ：仕様書無しさん：2013/05/15(水) 08:14:14.92

死んでくれるだけで結構ですよ。

781 ：おじゃばさま ◆mpgYduuqtA ：2013/05/15(水) 18:38:01.63

ファイルアクセスを例に説明する。
レガシーCの場合は、
fopen()
fgets()
fputs()
fclose()
このような構成になっている。
これらはリターン値や引数に
FILE*「ファイルポインタ」を
持っている。
これを単純にオブジェクト指向に
すると、
class FileManager{
public FileManager(String name){}
public void open(){}
public String read(){}
public int write(String buff){}
public close(){}
}
となる。
しかし、いくつかの問題がある。

782 ：おじゃばさま ◆mpgYduuqtA ：2013/05/15(水) 18:38:25.32

ここでいくつか問題がある。
まずread()とwrite()は意味的には
似ているか、openに依存している。
リードモードでオープンして
ライト出来ないため、
リードとライトは分けた方がいい。
単一責任の原則というやつだ。

次に、openはコンストラクタでやれば
不要になる。
クローズはデストラクタで行うが、
Javaの場合はいつ呼ばれるか分からないため、
明示的に呼べるようにclose()を提供し、
デストラクタではクローズされていない場合に、
クローズするようにする。

783 ：仕様書無しさん：2013/05/15(水) 18:46:21.15

>>782
> openはコンストラクタでやれば不要になる。

ファイル名はどうすんだ

784 ：おじゃばさま ◆mpgYduuqtA ：2013/05/15(水) 19:29:54.14

class FileReader{
public FileReader(String name){}
public String read(){}
public void close(){}
}
class FileWriter{
public FileWriter(String name){
public int write(String buff){}
public void close(){}
}
これがオブジェクト指向だ。

785 ：仕様書無しさん：2013/05/15(水) 19:33:14.09

コンストラクタで渡すとか、ファクトリにファイル名を渡して作るとか

786 ：仕様書無しさん：2013/05/15(水) 19:33:50.69

一々close要るってダルい言語だよなJava

787 ：仕様書無しさん：2013/05/15(水) 19:34:07.85

むしろ
class FileManager
こんなな前付けるセンスの方が遥かに問題だ。

788 ：仕様書無しさん：2013/05/15(水) 20:10:15.24

>>784
ファイル名が違ってたらどうすんだ？
いちいちチェックすんのか？
フルパスだと最大で何文字チェックするんだ？

789 ：おじゃばさま ◆mpgYduuqtA ：2013/05/15(水) 20:22:13.54

>>788
ファイル名チェック？
そんなのはせず、オープンエラーなら、
Exceptionをスローする。

790 ：仕様書無しさん：2013/05/15(水) 21:07:03.59

>>789
ファイル名を変更して読み書き
つまり、複数のファイルの読み書きだよ
いちいちCloseが必要なのか？

791 ：おじゃばさま ◆mpgYduuqtA ：2013/05/15(水) 21:30:11.60

次に悪い例
class FilePointer{
}
class FileGenerator{
public FilePointer open(String name){}
}
class FileExecutor{
public String read(FilePointer fp){}
public int write(FilePointer fp, String buff){}
public void close(FilePointer fp){}
}
レガシーCを処理毎にまとめた。

792 ：仕様書無しさん：2013/05/15(水) 22:04:29.01

ヒドイね

793 ：おじゃばさま ◆mpgYduuqtA ：2013/05/15(水) 22:06:37.76

>>790
ファイル名変更しての読み書きは、
基本的に2ファイル使う。
変更前のファイルをFileReaderで開いて、
変更後のファイルをFileWriterで開いて、
任意の処理をした後、変更前のファイルを
消して下さい。

794 ：おじゃばさま ◆mpgYduuqtA ：2013/05/15(水) 22:48:16.74

さてこれを変更してみよう。
FileReaderにバッファリング機能を
追加してみよう。
class BuffedFileReader extends FileReader{
public BuffedFileReader(String name){}
public String read(){
バッファ機能
}
}

795 ：仕様書無しさん：2013/05/15(水) 22:54:46.12

！？

796 ：おじゃばさま ◆mpgYduuqtA ：2013/05/15(水) 23:06:35.83

では次にファイルではなくWebから
読み込むようにしてみよう。
WebReaderを作成し、FileReader
から共通要素をReaderに移動し、
それぞれでそれを継承する。
class Reader{
public Reader(String name){}
共通要素
}
class FileReader extends Reader{
public FileReader(String name){}
public String read(){}
public void close(){}
}
class WebReader extends Reader{
public WebReader(String name){}
public String read(){}
public void close(){}
}
これがReaderが抽象化されたという。
変更によりコードが洗練される瞬間だ。

もしこれらの修正を791の悪い例の
コードに対して行うと、無茶苦茶になる。

797 ：仕様書無しさん：2013/05/15(水) 23:14:44.68

Java講座がやりたいなら他所でやれ。

798 ：仕様書無しさん：2013/05/15(水) 23:22:00.75

丸写しで出典元も知ってるけど、クソコテの名誉のために黙っといてやるか

799 ：おじゃばさま ◆mpgYduuqtA ：2013/05/16(木) 00:28:42.69

>>798
へー、なんて本？

800 ：仕様書無しさん：2013/05/16(木) 01:29:04.04

説明能力が足りてない奴は何を行っても滑稽でしかない

801 ：おじゃばさま ◆mpgYduuqtA ：2013/05/16(木) 08:29:57.34

>>800
ではその高い説明能力で、DIと委譲の
優位性を説明してはどうだ？

802 ：仕様書無しさん：2013/05/16(木) 10:49:21.38

なんでJavaの人達ってReaderとWriterを分けたがるかね。
抽象化されたIOクラスなら、読み/書きメソッドが揃ってた方が便利だと思うが。
他にReaderとWriterを分けたがる言語ってある？

803 ：仕様書無しさん：2013/05/16(木) 13:08:36.93

InputStrem/WriterStreamとかJavaはそういう設計思想じゃろ

804 ：仕様書無しさん：2013/05/16(木) 13:09:08.99

OutputStreamか
あんまり覚えてねえな

805 ：仕様書無しさん：2013/05/16(木) 13:20:40.80

>>803
なんでそういう設計思想なんだろうという疑問。

806 ：仕様書無しさん：2013/05/16(木) 14:05:11.07

委譲。
class IoBase {
public:
　　virtual string read(string& name) = 0;
　　virtual int write(string& buf) = 0;
　　virtual void close() = 0;
};
class FileIo : public IoBase {};
class HttpIo : public IoBase {};
class MemoryIo : public IoBase {};
class SocketIo : public IoBase {};

class HogeExecutor {
public:
　　HogeExecutor(IoBase* io_) : io(io_) {}
　　string read(string& name) {return io->read(name);}
　　int write(string& buf) {return io->write(buf);}
　　void close() {io->close();}
private:
　　IoBase* io;
};

807 ：おじゃばさま ◆mpgYduuqtA ：2013/05/16(木) 18:29:22.30

>>806
これは、ファイルの場合は、
どのタイミングでオープンする？
リードするのかライトするのか
分からないと、コンストラクタでは
オープン出来ないが。

808 ：おじゃばさま ◆mpgYduuqtA ：2013/05/16(木) 18:51:31.19

>>806
HttpIoのreadメソッドのみパラメータが
一つ増えた（タイムアウト時間など）場合は、
HogeExecuterのreadメソッドは
どのように修正する？

809 ：仕様書無しさん：2013/05/16(木) 19:54:34.42

え、>>796はreadはオーバーライドしてないのか？

810 ：仕様書無しさん：2013/05/17(金) 00:14:14.88

ひょっとして、read,write,closeをオーバーライドしないからポリモーフィズムが使えず委譲できないというオチ?

811 ：仕様書無しさん：2013/05/17(金) 02:05:06.39

だからいい加減スレタイ読め
ここは「これからコードを書く人に教えたいノウハウ」じゃなくて
「これからコードを書く人に絶対やって欲しいこと」スレだあほう

>>802
C++もistreamとostreamとこれらを多重継承したiostreamが無かったっけか
逆立ちしても受け入れられない機能を提供しないって方針は有りだと思うよ
Javaでの設計で冗長に感じる事は多い気がするけれど、ReaderとWriterを分ける事自体は然程気にすることじゃない気がする

812 ：仕様書無しさん：2013/05/17(金) 03:56:32.91

>>811
お前も同類だ、アホ

813 ：おじゃばさま ◆mpgYduuqtA ：2013/05/17(金) 09:05:41.05

>>809
796ではWebReaderにタイムアウト
が追加になるなら、
WebReaderに引数を追加した
メソッドを追加するだろう。
オーバライドではなく、メソッド追加だな。

>>810
オーバライドしないから
ポリモーフィズムが使えない？
何かに対しての答えか？

>>811
これからコードを書く人に、
オブジェクト指向のモジュール分割の
基礎を習得して欲しい。
でいいだろう。

814 ：仕様書無しさん：2013/05/17(金) 09:08:36.60

なんでJavaに限定しとんねん、アホちゃうかこのオッサン

815 ：おじゃばさま ◆mpgYduuqtA ：2013/05/17(金) 09:16:03.29

>>806
これって何が利点？

816 ：仕様書無しさん：2013/05/17(金) 11:21:49.33

>>813
> >>809
> 796ではWebReaderにタイムアウト
> が追加になるなら、
> WebReaderに引数を追加した
> メソッドを追加するだろう。
> オーバライドではなく、メソッド追加だな。

そんなことを聞きたいのではないよ。
>>796のreadはオーバーライドしてるの？してないの？

817 ：おじゃばさま ◆mpgYduuqtA ：2013/05/17(金) 18:04:48.80

>>816
オーバライドしてる。

818 ：仕様書無しさん：2013/05/17(金) 18:21:06.68

>>817
オーバーライドしてるのなら、>>806のIoBaseと構造は同じだろ

819 ：仕様書無しさん：2013/05/17(金) 18:24:09.33

つか、はよ「共通部分を親クラスにくくりだして実装継承する」を超えた話しろよ
いつまで同じ話してんだよ

820 ：おじゃばさま ◆mpgYduuqtA ：2013/05/17(金) 18:32:37.16

>>818
違うと思う。
ReaderとWriter分けているし、
子クラスにメソッド追加する
制限もない。

委譲のコードは807、808の問題には
どうやって対応する？

821 ：仕様書無しさん：2013/05/17(金) 18:41:22.80

>>820
人の揚げ足取りはいいから

てめーはファイル名を毎回チェックするのか毎回オープンしなおすのかはっきりしやがれ

822 ：おじゃばさま ◆mpgYduuqtA ：2013/05/17(金) 18:56:39.68

>>821
あげあしではなく、素朴な質問だよ。

ファイル名のチェックと言うのは、
何を言っているのか分からない。
ファイル名変更して、複数のファイルを
読み書きする？
ファイル名変更はReader、Writerの
仕事じゃないし、
複数のファイルを扱いたいなら、
Reader、Writerを使った別のクラスを
作るだろう。

823 ：仕様書無しさん：2013/05/17(金) 19:14:28.04

>>822
おｋおｋ
ファイルごとにクラスを作るわけね。

824 ：仕様書無しさん：2013/05/17(金) 19:16:08.30

>>813
なら「オブジェクト指向のモジュール分割の基礎を習得して欲しい。」と書けばいいのであって、講義を始めるのはやっぱりスレチ
それと>>814

825 ：おじゃばさま ◆mpgYduuqtA ：2013/05/17(金) 19:27:40.19

>>824
オブジェクト指向の話をしたら、
デザインパターンの本とか薦める
人がいただろう。
基礎を知らずデザパタなんて有害だ。
オブジェクト指向の基礎を学習する
のに最適な本がない以上、
基礎の話になるのは必然だろう。

826 ：仕様書無しさん：2013/05/17(金) 19:37:54.21

メモのメモのメモ
>>760
>>762-764

827 ：仕様書無しさん：2013/05/17(金) 20:38:28.43

>>825
だから、それなら「基礎を知らずデザパタなんて有害だ。先にオブジェクト指向の基礎を学習しろ」
とでも書けばいい話であってここで講義おっぱじめる理由にはならねぇんだよ。

お前の講義はスレチなんだからここで講義してもスレ趣旨の内容がノイズとして資料価値を下げるし、
この手の会話もノイズとなるし、挙句の果てにdat落ちまでする。
有益なことをしたいならGoogleSiteでも構わんからページ作ってそこでやれ。

828 ：おじゃばさま ◆mpgYduuqtA ：2013/05/17(金) 22:32:59.36

>>827
オッケー、
じゃ価値ある情報を見せてくれよ。

829 ：仕様書無しさん：2013/05/17(金) 23:07:19.22

>>828
ここで講義しても価値が下がるし他所でやれって言ってるだけなんだが、なんでそんなレスになるんだ？

お前の講義に価値が無いとは言ってない。
自分でそんなレスする辺り、自分は価値の無い講義してると自分で思ってるのか？
価値の無い講義だと自分で思ってるならハナからやるな。そもそもスレチだ。

このスレは「これからコードを書く人に絶対やって欲しいこと」スレであって、
「これからコードを書く人に絶対やって欲しいことに必要な資料の丸上げ」スレじゃない。

分かったらさっさと講義は止めてページ作って、リンク貼って終わりにしろ。
お前の講義に価値がなければそのページは只のゴミページになるだけだし、
お前の講義に価値があるならそのページは貴重な資料になるだろう。
ここでやったら価値の有無に関わらず、等しくノイズまみれのゴミになってdatの海に消えるだけだ。

830 ：仕様書無しさん：2013/05/17(金) 23:17:39.32

ってか普通の入門書読んでコード書けば良いだけでしょ
細かいところは失敗して学べばいい

831 ：仕様書無しさん：2013/05/18(土) 00:02:40.05

前と全く同じ流れ。
具象クラスをnewするんでしょ
↓
するよ
↓
継承したら使用するコードも修正するの?
↓
するよ

832 ：仕様書無しさん：2013/05/18(土) 06:05:16.93

>>829
> お前の講義に価値が無いとは言ってない。

ちゃんと否定しろよ

833 ：仕様書無しさん：2013/05/18(土) 08:56:58.34

DogクラスがあるところにCatクラスが必要になったら
Animalクラスを作ってDogとCatを派生させます、レベルの
ことしか言ってないもんなあ

834 ：仕様書無しさん：2013/05/18(土) 09:54:25.61

>>832
自慰講義を他所でやってもらうのが主目的なら、価値がないと思ってても言わないほうがいいとかそういう類

835 ：仕様書無しさん：2013/05/18(土) 11:01:08.35

自慰講義を他所でやってもらうのが主目的なら、価値がないと思ってても言わないほうがいいとかそういう類だと思ってても言わない方がいい

836 ：仕様書無しさん：2013/05/18(土) 11:14:14.63

見たくないならNGしろよ

837 ：仕様書無しさん：2013/05/18(土) 16:55:35.06

糞コテに構うからahoo知恵遅れになるんだよ

838 ：仕様書無しさん：2013/05/18(土) 18:22:45.13

コテNGなんて基本中の基本

839 ：仕様書無しさん：2013/05/18(土) 18:37:26.57

ソフトウェアデザイン6月号読んできたんだけれど
オブジェクト指向って、ほんとに現場であんな事細かに分割してるの？

840 ：仕様書無しさん：2013/05/19(日) 17:02:16.55

してない
そもそもOOP理解してないレベルのクズがごろごろ居る

841 ：仕様書無しさん：2013/05/19(日) 17:30:09.92

一度IT行って基本的な事わかった後で自分で勉強しないと厳しい
大手行くとプログラミングなんてやらんし中小はデスマだし

842 ：仕様書無しさん：2013/05/19(日) 19:25:03.24

OOP理解してない奴が後輩の面倒とか見るから、無能量産企業が溢れてるよな。

843 ：仕様書無しさん：2013/05/20(月) 19:54:32.88

UMLすら...

844 ：仕様書無しさん：2013/05/21(火) 00:54:52.94

結局、関数言語よりさらにさかのぼって手続きゴリゴリです
神クラスがすべてなんです

845 ：仕様書無しさん：2013/05/21(火) 03:58:53.76

便利な言葉
学習コストガー

くそっ！

846 ：仕様書無しさん：2013/05/21(火) 14:05:09.80

キーボードにコーヒーこぼさないように気をつけるんだ！！

847 ：仕様書無しさん：2013/05/22(水) 03:43:53.57

これからコードを書く人に絶対にやってほしい事。

こんなスレ見るな！

これが早いな。
読むだけ無駄な時間を浪費。

848 ：仕様書無しさん：2013/05/25(土) 15:29:35.00

手続き脳のままのやつが一人でもいると色々破綻する
ちゃんとしたコードレビューできるレベルの知識あるやつが少なすぎる
っていうかそういうレベルでレビューしたら全部作りなおすしかないレベルの成果物が多すぎてレビュアーが死ぬ

849 ：仕様書無しさん：2013/05/25(土) 15:49:48.82

まったくだ。レビューではなく教育だ。
一行一行どうすればいいか教育しないといかん。
しかもそれが俺より上司だったり
先輩だったりする。

まあ入社して何年かで慣れたし、
上もやめたりでいなくなったりしたから
今は結構楽になったけどな。

850 ：仕様書無しさん：2013/05/25(土) 17:39:11.65

まとめると、レベルの低い会社に入ったら、それなりの人間しかいないってことだな。

851 ：仕様書無しさん：2013/05/25(土) 18:38:09.32

その通りなんだけど、レベル高い会社って日本にあるのかな…？
面接で技術力しっかり確認してる所少ないし、技術の良し悪しとか、技術者の良し悪しがわかる人もほとんどいないし、技術者の地位が低いし…

852 ：仕様書無しさん：2013/05/25(土) 19:04:33.53

>>851
レベル高い会社はあるかもしれないけど、地獄だよ。
だって、能力の低い奴は拷問されて殺されてるんだから。

853 ：仕様書無しさん：2013/05/25(土) 20:15:49.60

UEIのenchant.jsの話とか聞くと、あーこういう奴もプログラマになるんだって思ったよ。

854 ：仕様書無しさん：2013/05/26(日) 12:16:26.36

ノートPCにコーヒーこぼさないように気をつけるんだ！！

855 ：仕様書無しさん：2013/05/26(日) 15:36:10.78

コーヒーこぼさないように
紅茶を飲んでる俺は優秀

856 ：仕様書無しさん：2013/05/26(日) 19:04:57.43

コーヒーのフレッシュの替わりにベイリーズを入れるとメッチャおいしぃ

857 ：仕様書無しさん：2013/05/26(日) 19:07:42.13

コーヒーフレッシュはミルクではなく単なる油だからやめたほうが良いらしい

858 ：仕様書無しさん：2013/05/26(日) 19:12:01.25

ノートにお茶こぼしたこと有るが
キーボードの隙間までたぷたぷの状態から
水面がスッと沈んでいく様はいまでもトラウマ。

859 ：仕様書無しさん：2013/05/26(日) 20:07:30.66

>>856
勤務中やぞ

>>857
あれは白くなったサラダ油

そして激しくスレ違い

860 ：仕様書無しさん：2013/05/26(日) 22:04:46.12

クリープを入れないコーヒーなんて…

861 ：仕様書無しさん：2013/05/26(日) 22:27:11.64

分かってたけどおっさんしか居ねぇなｗ

862 ：仕様書無しさん：2013/05/27(月) 01:40:15.16

>>856
美味そうだが酒じゃねぇかよ…

863 ：仕様書無しさん：2013/05/28(火) 00:09:45.89

これからコードを書く人には、ソース管理についての知識をつけてほしい
GitHubいいゾ～これ

864 ：仕様書無しさん：2013/05/28(火) 00:17:14.34

プログラミングは趣味に留めておくべき。

865 ：仕様書無しさん：2013/05/28(火) 00:34:27.23

飲み物スレ

866 ：仕様書無しさん：2013/05/28(火) 02:49:50.82

役に立つコメントを書く事かな。
こういうの↓は、一見、丁寧に書いているようだけど情報量はない。

// ファイルを開く
in = new FileInputStream("foo.txt");

// ファイルを閉じる
in.close();

// 値を返す
return val;

867 ：仕様書無しさん：2013/05/28(火) 03:02:47.94

>>866
「無意味なコメント書くような奴が書いたコードだ」って情報は得られるぞ

868 ：仕様書無しさん：2013/05/28(火) 08:16:21.54

>>866
コメントを抽出して仕様書化する糞作業がある開発では
そういうコメントが必要。もしくは、そういうコメントを先に
書かせて詳細設計としてレビューするところもある。
なので役に立たないコメントではない。

本当に役に立たないコメントというのは

// aに1をたす
a++;

見たいなの。

869 ：仕様書無しさん：2013/05/28(火) 09:27:31.33

// aに0を代入
a = 1;

っていうカオスなコメントが実際あったそうだな

870 ：仕様書無しさん：2013/05/28(火) 09:51:12.07

コードに描いてある英語と同じ意味の日本語コメントはいらない。
というか、何らかの事情でトリッキーな事していない限り、ただしく設計や命名をしていればコメントはいらない。

871 ：仕様書無しさん：2013/05/28(火) 12:54:38.50

>>870
その命名をコメントの内容にすればいいわけだしな
結局のところアレだ、英語やれ

872 ：仕様書無しさん：2013/05/28(火) 13:09:26.17

日本語プログラミング言語を使えばコメントいらないんじゃね？

873 ：仕様書無しさん：2013/05/28(火) 15:58:55.35

一別して処理の流れがわかるという意味では、>>866の日本語コメントは優れているとも言える。

874 ：仕様書無しさん：2013/05/28(火) 16:08:58.06

>>873
言えない
すべて関数化しておいて詳細はその関数でやれば、関数名だけで処理を追えるから

close(); // 閉じる
とかは「aに1を足す」と大差ないし

875 ：仕様書無しさん：2013/05/28(火) 16:28:07.81

>>874
閉じる、とaに1を足すでは雲泥の差なんだが
そんなこともわからないクズがコメントを語るなよ

876 ：仕様書無しさん：2013/05/28(火) 16:38:18.94

>>875
ソースの直訳だろ
同じだわ

877 ：仕様書無しさん：2013/05/28(火) 17:02:16.95

>>874
違う意見に寛容になりましょう。

>>866のコードが20行くらいのメソッド内のコードだとして、日本語のコメントがあの三つだとしたら、

int foo()
{
// ファイルを開く
・・・
・・・
// ファイルを閉じる
・・・
・・・
// 値を返す
・・・
}

ほぼ一瞬で「ファイルをオープンして何かしてクローズして値を返すメソッドなんだなぁ」とわかる。

という人もいるって認めようよ。

878 ：仕様書無しさん：2013/05/28(火) 17:16:19.05

コード読めばわかるけど、コメントあるとやっぱありがたい。

var foo = function(dom, callback) {
// body直下にdomを挿入

// cssを設定する

// callbackが指定されてれば呼ぶ
}

879 ：仕様書無しさん：2013/05/28(火) 17:18:32.89

コメントは一年後の自分宛に書け

880 ：仕様書無しさん：2013/05/28(火) 17:19:19.76

void foo() {
// 急いで

// 口で

// 吸え
}

881 ：仕様書無しさん：2013/05/28(火) 19:16:21.04

>>877
いや、いてもいいんだけど
そんなジジくさい書き方古いよ

ここは「これからコードを書く人」にむけたスレであって、古いやり方を認めろと押し付けるスレではない

882 ：仕様書無しさん：2013/05/28(火) 20:19:54.22

{
　　//深夜に

　　//夕飯食べると

　　//太るぞ

}

883 ：仕様書無しさん：2013/05/28(火) 20:21:10.47

>>881
古い新しいはお前が決めることではない。

884 ：仕様書無しさん：2013/05/28(火) 20:44:31.90

肉肉
野菜野菜
肉肉

885 ：仕様書無しさん：2013/05/28(火) 20:55:09.61

何をどう処理するかヘッダコメントに書いてあれば充分かな。
それをどう実装しているかは改変とか不具合究明の時に見るくらいだし、
素直な実装ならコメントなんか不要でしょ。

関数化／クラス化で細分化されたプロジェクトはそういったのの方が見通しがきく。

だが、1000行程のひとりぼっちmain、てめぇは駄目だ！

886 ：仕様書無しさん：2013/05/28(火) 21:13:31.26

どちらにせよ、このスレはこれからコードを書く人には勧められんなｗ

887 ：仕様書無しさん：2013/05/28(火) 21:51:20.63

>>883
古い新しいは俺が決めることでもお前が決めることでもなくて、時代が決めること
時代に抗っても得なことは何もないよ

888 ：仕様書無しさん：2013/05/28(火) 22:02:42.98

>>883
こういうのがいるから癌なんだよな

889 ：仕様書無しさん：2013/05/28(火) 22:14:37.12

でも、癌細胞ってのは通常細胞よりも強いんだよな。

890 ：仕様書無しさん：2013/05/28(火) 22:14:55.99

>>888
その理由は？

891 ：仕様書無しさん：2013/05/28(火) 22:19:56.59

命名規則とかフォーマット規則とかどこまで本気にしていいか分かんない

892 ：仕様書無しさん：2013/05/28(火) 22:41:23.81

>>887
時代が決める？
実務経験のない学生かニートが言う幻想だな。
現実には宗教がすべて。

893 ：仕様書無しさん：2013/05/28(火) 22:44:16.78

>>888
これが新しいスタイルと決めつけているお前が一番の癌。

894 ：仕様書無しさん：2013/05/28(火) 23:06:38.69

>>893
「コードの内容を日本語に直訳する書き方は古い」っていってるんだから、決めつけてる方向逆だぞ。
そしてこの手のコメント文化は古臭いコーディング規約と共に息衝いてんので、古い考え方なのは間違いない。

問題はコレが悪いことなのか否か、だが…

欠点は、二度手間であることと、処理の概要や解説などのコメントが埋もれて見づらくなること。
利点は、このレベルの直訳の方が見やすいレベルの人間にもコードを読ませることができること。
利点が生きるレベルの奴はさっさとコード読めるように教育しろよボケって言ってもいいなら、害のほうが大きいって言えそうだ。

895 ：仕様書無しさん：2013/05/28(火) 23:14:05.54

関数の中身をコメントつけなきゃ追えないなら、それは書き方が悪いか分割の仕方が悪い。

896 ：仕様書無しさん：2013/05/28(火) 23:34:28.23

あーあ、荒れた(笑)

897 ：仕様書無しさん：2013/05/28(火) 23:39:45.73

>>894
めんどくせー奴が粘着を始めた

898 ：仕様書無しさん：2013/05/28(火) 23:55:28.48

自分の意に沿わなかったら粘着と片付ける老害

899 ：仕様書無しさん：2013/05/29(水) 00:11:21.82

書き込みしようとしてやっぱりやめたけどやっぱり必要みたいだから書くよ。

>>866 みたいなコメントは必要。初心者には必要。つまり、このスレ的には必要ってことだ。
理由は、>>869 みたいなことをやらかすから。

まだプログラミングを学習中の人間は、コードを正しくかけないので、
本当は何がしたかったのかはコメントに書かれているはず。
そしたら、コメントとコードを比較することで、バグなのかどうか判断できたりする。

コードを正しく書けるようになったなら不要。どんどん削れ。

コードを書く前にコメントを設計書っぽく書いてからコーディングに入るってことをやったりしてる。
その方が全体が小さくまとまるから見やすい。
詳細設計のバグ出しはそのときにやってる。
使用する関数名だけ並べておけば、必要な変数とか、抜けてる処理とかが見えてくる。
日本語名だけでなく、関数名を書いておくと、F1キークリックするだけで関数の詳細が見れる。
これはワープロにはない機能だ。

コード全体を書くのは時間がかかる。特に変数は処理そのものではないので余分に時間がかかる。
だから変数を書くよりもまず使う関数だけ並べるのがいい。（手続き型処理の場合）

そういうわけで、コメントで細かく処理内容を書くと言うのはありっちゃありだ。
コードが完成したときに重複だと思えば消せばいい。

ただし、色分け機能のない環境ではコメントの範囲を間違いやすいので、コメントを削るときにバグりやすい。
その場合はコメントを削ったりしないほうがいい。

900 ：仕様書無しさん：2013/05/29(水) 00:30:30.64

何かずれてる人多いな

901 ：仕様書無しさん：2013/05/29(水) 00:40:47.99

本当のの初心者は
コメントを書く→コメントの通り動くコードを書く
という練習をすればいい

が、職業でするレベルなら
コメントを書かなくても何をしているのかわかるコードを書く
やむなくわかりずらいコードになる時はコメントを書く
位にして欲しい

意図したコードが書けているかわからない位なら、家で勉強してほしい。

902 ：仕様書無しさん：2013/05/29(水) 01:02:49.81

正解なんて無い。
正解があるならこんなスレ存在しない。

でもどれが間違いというわけでもない。
みんな試行錯誤して切磋琢磨して足掻き苦しんで
それでもコードを書いているんだ。

これからコード書く人も常に足掻き苦しむしかない。
それがない世界など人の携わる世界ではない。

903 ：仕様書無しさん：2013/05/29(水) 01:04:40.95

結論

コメントはプロジェクトの前例に従え

904 ：仕様書無しさん：2013/05/29(水) 01:09:36.01

結論

やりたいようにやれ

905 ：仕様書無しさん：2013/05/29(水) 01:12:24.43

ファイルをオープンするというコメントは絶対に不要と言う方が頭固いんじゃないの

906 ：仕様書無しさん：2013/05/29(水) 01:14:09.09

>>901家に客先のソースコードお持ち帰りする輩が出てくる悪寒

907 ：仕様書無しさん：2013/05/29(水) 01:15:32.81

家に帰る余裕があるだけまし

908 ：仕様書無しさん：2013/05/29(水) 02:07:59.92

1メソッドを多機能にするからコメントで都度説明しないと読み取れないとか言い出す馬鹿が出るんだけどな
結局理解力の低い底辺に合わせてコーディングするかどうかってことだわ
無駄な作業をやる必要はないと思うけどな

つか、そういう簡単にコードを読み取れない底辺は、コメントの修正なんてせずにコピペするから
実装とコメントが食い違ったりして、負の連鎖生むだけになるから、
ロジックの部分部分への意図以外の説明コメントとか、アホの所業だよやっぱ

909 ：仕様書無しさん：2013/05/29(水) 04:06:01.31

サブ関数化はしない！コメントは日本語だから追いやすい！ってやつはアホだよな…

910 ：仕様書無しさん：2013/05/29(水) 04:08:27.63

サブ関数は勝手に作るの禁止なんだよな。
関数が作りたければ関数の仕様書を書かないといけないんだけど
仕様書を書く資格があるのはSEであってプログラマではない。
だからプログラマにはサブ関数を作る権利がない。

というのが一般的だと思うよ。

911 ：仕様書無しさん：2013/05/29(水) 04:11:12.10

ま、組織によるよな

912 ：仕様書無しさん：2013/05/29(水) 04:39:33.63

つまるところソースを翻訳したようなコメントは、
ソースを直接読めない初心者に、ソースより先に読ませる(≠書かせる・修正させる)ためのものか、
ソースを直接書けない初心者に、ソースより先に書かせる(≠残すして他人に見せる)ためのものであるべし、
って事になるんかな

二重に書くことによるチェック云々とかにしても、自動テストとか導入したほうが建設的だろうし

そういう文化・規約がある場合は……ご愁傷さまです

913 ：仕様書無しさん：2013/05/29(水) 06:38:17.88

必死すぎ

914 ：仕様書無しさん：2013/05/29(水) 07:13:21.95

まあ、ソースを読ませるためのコメントを書く人って、
つまりはソースが仕様書のダメ人間だよね。
きちんとフェーズを踏んで開発されたソースってのは、
ソースを見ればいらないものもいっぱい含むのが当たり前。

915 ：仕様書無しさん：2013/05/29(水) 07:31:26.37

小説なんて読めばわかるんだから、あらすじなんて必要ないと主張する人たち

916 ：仕様書無しさん：2013/05/29(水) 07:48:08.83

>>915
小説の本編内にあらすじの引用が必要なの？馬鹿なの？

917 ：仕様書無しさん：2013/05/29(水) 08:08:58.39

読者がコメントで欲しいのはコメンタリーであってあらすじではない。
このことからも、「ソースを翻訳したようなコメント」を書いている
奴は、無能でクズのネトウヨだろわかる。

918 ：仕様書無しさん：2013/05/29(水) 08:24:28.49

これからコードを書く人へ一言

「意識して呼吸しよう」

のめり込むと息が止まって頭が回らなかったり
眠くなる。

919 ：仕様書無しさん：2013/05/29(水) 08:43:20.74

コメントをあらすじに例えるのはさすがに勘違いがひどすぎる

920 ：仕様書無しさん：2013/05/29(水) 10:54:59.72

>>915
さすがにこれは未経験者だろ…

921 ：仕様書無しさん：2013/05/29(水) 11:32:11.36

翻訳コメなら楽に読めるって意見は、ページの9割文字で埋まっててもマンガなら読めるんですって人と通じるものが有るな。

>>915
あらすじって例えを使うなら、あらすじ欄に本文を別表現にした文章が全文書かれてるようなもんだろ、翻訳コメントは。
本文を読むための文章として全く機能しない。

922 ：仕様書無しさん：2013/05/29(水) 16:05:17.98

リーダブルコード読め。

5章　コメントすべきことを知る
5.1　コメントするべきでは「ない」こと
コメントのためのコメントをしない
ひどい名前はコメントをつけずに名前を変える
5.2　自分の考えを記録する
「監督のコメンタリー」を入れる
コードの欠陥にコメントをつける
定数にコメントをつける
5.3　読み手の立場になって考える
質問されそうなことを想像する
ハマりそうな罠を告知する
「全体像」のコメント
要約コメント
5.4　ライターズブロックを乗り越える
5.5　まとめ

6章　コメントは正確で簡潔に
6.1　コメントを簡潔にしておく
6.2　あいまいな代名詞を避ける
6.3　歯切れの悪い文章を磨く
6.4　関数の動作を正確に記述する
6.5　入出力のコーナーケースに実例を使う
6.6　コードの意図を書く
6.7　「名前付き引数」コメント
6.8　情報密度の高い言葉を使う
6.9　まとめ

923 ：仕様書無しさん：2013/05/29(水) 16:15:31.22

The Art of Readable Code: P55

<quote>
It’s especially helpful to have these summary comments in longer functions where there are a
few large “chunks” inside:

def GenerateUserReport():
　　# Acquire a lock for this user
　　...
　　# Read user's info from the database
　　...
　　# Write info to a file
　　...
　　# Release the lock for this user

These comments also act as a bulleted summary of what the function does, so the reader can
get the gist of what the function does before diving into details. (If these chunks are easily
separable, you might just make them functions of their own. As we mentioned before, good
code is better than bad code with good comments.)
</quote>

924 ：仕様書無しさん：2013/05/29(水) 16:25:13.11

まじな話、これからコードを書こうって人に、「コメントや名前を適切に」って言いすぎると
おまえらみたいな、コードが書けない頭でっかちが出来あがる。

925 ：仕様書無しさん：2013/05/29(水) 16:36:57.39

>>924
これからコードを書こうって人は、コメントという物に対して何の指針も経験も無いわけでから、
最初からあるべき論で染めやすい。

しかも、>>923程度の分量は、30分～1時間くらいあれば読めちゃう。
ただ、「こういうコードにコメントを付けるなら」の「こういうコード」の部分が分からないから、
それが分かるようになってからもう一度読むのが良い。

926 ：仕様書無しさん：2013/05/29(水) 16:37:18.31

>>923じゃなくて>>922だった。

927 ：仕様書無しさん：2013/05/29(水) 16:45:20.70

>>922
5章　コメントすべきことを知る
　　 5.1　コメントするべきでは「ない」こと
　　　　コメントのためのコメントをしない
　　　　ひどい名前はコメントをつけずに名前を変える
　　 5.2　自分の考えを記録する
　　　　「監督のコメンタリー」を入れる
　　　　コードの欠陥にコメントをつける
　　　　定数にコメントをつける
　　 5.3　読み手の立場になって考える
　　　　質問されそうなことを想像する
　　　　ハマりそうな罠を告知する
　　　　「全体像」のコメント
　　　　要約コメント
　　 5.4　ライターズブロックを乗り越える
　　 5.5　まとめ

6章　コメントは正確で簡潔に
　　 6.1　コメントを簡潔にしておく
　　 6.2　あいまいな代名詞を避ける
　　 6.3　歯切れの悪い文章を磨く
　　 6.4　関数の動作を正確に記述する
　　 6.5　入出力のコーナーケースに実例を使う
　　 6.6　コードの意図を書く
　　 6.7　「名前付き引数」コメント
　　 6.8　情報密度の高い言葉を使う
　　 6.9　まとめ

928 ：仕様書無しさん：2013/05/29(水) 16:47:25.15

> 情報密度の高い言葉

たとえば連呼リアンとか朴李とか

929 ：仕様書無しさん：2013/05/29(水) 17:05:44.87

>>928
以下のcaching layerが「情報密度の高い言葉」。

The Art of Readable Code: P64
<quote>
For example, suppose your comment were:
// This class contains a number of members that store the same information as in the
// database, but are stored here for speed. When this class is read from later, those
// members are checked first to see if they exist, and if so are returned; otherwise the
// database is read from and that data stored in those fields for next time.

Instead, you could just say:
// This class acts as a caching layer to the database.
</quote>

930 ：仕様書無しさん：2013/05/29(水) 17:23:10.96

コメント不要とか言ってる意識高いプログラマ()に言いたいんだけどさ、
お前のコード、お前が自分で思ってるほどリーダブルじゃないんだから
ちゃんとコード書ける人の猿真似すんのはやめたほうがいいと思うよ。

責務の分割とネーミングが適切にされていればコメントは不要って
そりゃそうなんだけどさ、英語わかんない馬鹿が頑張って名付けたそのメソッド、
なにがしたいのか全然わかりませんからーｗ

931 ：仕様書無しさん：2013/05/29(水) 18:05:12.58

リーダブルコードなんて新人にいらねーよ
読んでも実戦経験がなければ意味がない

932 ：仕様書無しさん：2013/05/29(水) 18:30:13.36

まあ、caching layerでピンと来ない奴が読んでも無駄だろうな

933 ：仕様書無しさん：2013/05/29(水) 19:12:38.09

// This class acts as a caching layer to the database.
class CachingLayer
要するにコメントいらねーってことか

934 ：仕様書無しさん：2013/05/29(水) 19:15:40.61

こう書くのが絶対に正しい！ソースはリーダブルコード（キリッ

935 ：仕様書無しさん：2013/05/29(水) 20:06:15.09

こう書くのは絶対に間違い、の反例だよ。
最初から言ってるじゃん。違う意見にも寛容になろうよって。

936 ：仕様書無しさん：2013/05/29(水) 20:18:14.57

そう言えば「行数を工数の計算に使うからコメントとか空行とか入れるな」と言う業務命令もらったことがある。
殴られたけど絶対従わなかった。

937 ：仕様書無しさん：2013/05/29(水) 22:13:57.70

>>936
いや、従えよ

938 ：仕様書無しさん：2013/05/29(水) 22:40:51.79

まともな行数カウントツールならコメントと空行を除いた実効行数を教えてくれるけどな

939 ：仕様書無しさん：2013/05/29(水) 22:55:11.35

行数なんてwc -lで十分。

940 ：仕様書無しさん：2013/05/29(水) 23:44:54.86

// XXX hack me

941 ：仕様書無しさん：2013/05/29(水) 23:55:35.19

>>930
誰もんなこと言ってないよ。
ソースを日本語訳したようなコメントは不要(有害)って言ってるだけ。
915の人もだけど、ソースの日本語訳以外のコメントを知らないのかな？

>>936
糞ルールだなぁ・・・てかそれ、行末や行頭にコメント入れるのもダメなん？

942 ：936：2013/05/30(木) 00:46:42.37

>>941
行末は確かおｋだったけど、途中改行禁止なのと「//」は互換性ないから禁止で
実質禁止。

943 ：仕様書無しさん：2013/05/30(木) 01:16:01.72

>>901
> 本当のの初心者は
> コメントを書く→コメントの通り動くコードを書く
> という練習をすればいい
>
> が、職業でするレベルなら
> コメントを書かなくても何をしているのかわかるコードを書く
> やむなくわかりずらいコードになる時はコメントを書く
> 位にして欲しい

常々思っているんだが、
勉強のためのコード（作業）と
仕事のためのコード（作業）は分けたほうがいい。

例えば自動化できれば直ぐに仕事が出来るのに、自動化してしまえば自分の力でできなくなる。
勉強のために自動化はしない。自動化しないことには意味があるんだ。
みたいな考え方はしたらダメ。

勉強のためにコメントを多く書くことに意味が無いとは言わない。だけどそれは勉強のためのコードだ。
そんなものを仕事に使うな。仕事のための作業で、勉強も出来れば一見一石二鳥に見えるかもしれないが、
それは仕事の効率を下げているだけ。

仕事では誰かがお膳立てをしたものを使ってラクラクやればいい。
それで勉強にならないというのなら、仕事とは分けて勉強をすればいい。

勉強と仕事を混ぜてはいけない。

944 ：仕様書無しさん：2013/05/30(木) 01:23:22.95

このスレはプログラミング始めたての学生が多いとみた

945 ：仕様書無しさん：2013/05/30(木) 01:55:00.44

>>942
読み込むときと保存するときに置換すりゃいいんじゃね？

それはともかく//コメント禁止ルールで言う互換性って何との互換性なんだろう
実際そういうコンパイラ向けに書いてるわけじゃないだろうし、
そんな環境まで持ってって動くようなレベルのコード書いてる現場でコメントの変換すら出来ないなんて思いつかんし。
行数しか読まない老害の脳味噌との互換性とかだと泣けるなぁ…

946 ：仕様書無しさん：2013/05/30(木) 02:00:08.42

C言語において、コメントは/* */のみ。
//は元々C++のコメントであり、
処理系によっては対応していない事があるらしい。
C99において正式にC言語のコメントとして認められるようになった。

947 ：仕様書無しさん：2013/05/30(木) 02:00:55.86

>>945
刑務所から出てきたばっかりなのを自慢してる老害だった

刑務所に入った理由は、小学生を誘拐してプログラム書かせて頭蓋骨骨折の暴行。
その小学生が俺。
俺に復讐するために舞い戻ってきたんだとさ。

948 ：仕様書無しさん：2013/05/30(木) 02:33:55.21

>>946
C99対応してなくてもC89の独自拡張で//一行コメントに対応してた(してる)コンパイラは普通に居るからなぁ

(現在使用中のコンパイラが独自拡張かC99準拠で行コメントを受け入れている前提で)
互換性のためにC89規格のみで独自拡張は一切禁止とした結果行コメントもダメとかなら分からんでもないけど、
それを厳密に守って手直しなしにコンパイラ差し替えれるような技術があったらコメント程度どうにでも変換できるだろと。
そしてそんな差し替えを常時想定しなきゃならんほどコンパイラの選択が不安定なのってどうなんだと。

949 ：仕様書無しさん：2013/05/30(木) 04:04:17.73

いまだにステップ数(笑)で評価してるとこがあるんだな

950 ：仕様書無しさん：2013/05/30(木) 04:09:01.15

むしろそれが普通では

951 ：仕様書無しさん：2013/05/30(木) 04:38:04.87

冗談は顔だけにしてくれ

952 ：仕様書無しさん：2013/05/30(木) 07:37:36.76

奴隷の評価方法にステップ数以外あるのか

953 ：仕様書無しさん：2013/05/30(木) 09:10:45.62

>>945
保存するときにコメント削除するのはわかるけど
（コミット時に自動フォーマットとかありがちなことだし）、
読み込むときに復元ってどうやんの？

954 ：仕様書無しさん：2013/05/30(木) 13:08:35.77

>>953
単に行コメントが禁止されてるだけなら
～～//コメント
を
～～/*コメント*/
に変換しとくだけでいいんでない？

わざわざ行コメント型に直す必要があるかどうかは微妙なとこだけどさ

955 ：仕様書無しさん：2013/05/30(木) 14:46:00.00

行コメントは「//」じゃないとだめなんだよ。
「//」が使えないなら書かないほうがマシ。
ちゃんと読め。
途中改行禁止で行コメントも禁止。
つまり、コメントは画面に表示されない。
画面に表示されないのに範囲指定のコメントを使った場合、後ろにごみが入る可能性があるが、それを目視できない。

ホストとかCOBOLとかであるだろ。
１行あたり何文字と決まっているけど、後ろに全角スペースが入ってるとエラーになるんだよ。
そういう状態になったらコンパイルエラーでめんどくさい。

その上俺を嫌ってるやつらばっかりなんで。
普通に仕事中にスタンガンで襲われたとき、俺が落とした財布とかほかの社員が持ち去って返してくれなくて
銀行に届け出たときには全額引き出されてた。
だから警察にも届けたんだが、「なに冗談にマジになってんだ」と言うのが会社の対応だった。

956 ：仕様書無しさん：2013/05/30(木) 14:56:35.18

>>955
マジかよ、早めに警察よりも病院に行けよ。
精神科だぞ。

957 ：仕様書無しさん：2013/05/30(木) 15:19:43.02

>>955
お前の身の回りについてはスレ違い
割とどうでもいい

958 ：仕様書無しさん：2013/05/30(木) 20:59:34.65

どうでもいいから動くモノ作れ。
それが最初の命題だ＞これからコードを書く人。

動かなければ意味がねぇんだよ。

959 ：936：2013/05/30(木) 22:04:08.80

ルールにクレームを入れたら
「コメントを画面内に収めたかったら短い命令を書け」と命令された。
だから
「コメントのために無駄な命令を書けと言うことですか」と言ったら
「無駄な命令は書くな。（短い命令は）やっぱり撤回」だとさ。
ルールは撤回されなかったがな。

その程度の知能でルールを決めてるんだから従う必要などない。

960 ：936：2013/05/30(木) 22:08:08.01

ほかにも、「中には短い行もあるんだからそっちにコメントを書けばいいだろ。」とかも言ってた。

N88BASICとかで、画面内に収めるために区切り記号使って画面いっぱいにコードを敷き詰めるやり方が紹介されてたけど
あれをWindows95の時代にやれと言うんだからびっくりするよ。
隣には画面サイズ２１インチのワークステーションがあるような会社なのに。
画面がでかいのは某地図の会社だから。

961 ：仕様書無しさん：2013/05/30(木) 22:32:16.68

頭おかしいんじゃないの?

962 ：仕様書無しさん：2013/05/30(木) 23:16:45.60

何故その処理をするのか、その理由を書くようにしてるよ＞コメント

963 ：936：2013/05/31(金) 00:34:44.30

その頭のおかしい奴がイントラネットの部署のトップに座ったんだな。

964 ：仕様書無しさん：2013/05/31(金) 02:04:34.13

エース何とかってSIerですか

965 ：仕様書無しさん：2013/05/31(金) 03:18:12.60

ま、この業界、このスレの奴らとか俺含めて、みーんな頭おかしいからさｗ

966 ：仕様書無しさん：2013/05/31(金) 03:41:55.24

スーパーカスコード
https://www.google.co.jp/search?q=%E3%82%B9%E3%83%BC%E3%83%91%E3%83%BC%E3%82%AB%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89

967 ：仕様書無しさん：2013/05/31(金) 17:06:16.62

>>955
だから読み込み時に行末ブロックコメントを行コメントに変換して、保存時に行末ブロックコメントに変換すりゃいいだろが。
ゴミが入ってたら読み込み時に行末ブロックコメントでないからブロックコメントとしてエディタに出せる。
見切れるなら折り返し表示出来るエディタくらい使えばいい。

後半はネタにしてもつまらんしマジならそんなトコに通う自分の脳味噌心配しろ

968 ：仕様書無しさん：2013/05/31(金) 17:26:52.96

何ムキになってんだよ

969 ：仕様書無しさん：2013/05/31(金) 17:59:11.96

やだこの697こわい

970 ：仕様書無しさん：2013/05/31(金) 18:32:29.65

>>967
俺は、そんな書き込みをする欲望を抑えられない、自分の心配をしたほうがいいと思うが。

971 ：仕様書無しさん：2013/05/31(金) 23:50:01.63

これからコードを書く人に知って欲しいこと
コメントが本文より目立たない配色はダサい

972 ：仕様書無しさん：2013/05/31(金) 23:54:55.25

視認性の問題をダサイでしか表現できない、おまえが心配。

973 ：仕様書無しさん：2013/06/01(土) 00:12:54.76

視認性の問題としか解釈できないお前が心配

974 ：仕様書無しさん：2013/06/01(土) 02:10:32.20

煽りあってるお前らが心配

975 ：仕様書無しさん：2013/06/01(土) 03:15:08.07

もう6月なのが心配

976 ：仕様書無しさん：2013/06/01(土) 15:41:44.96

たしかに心配

977 ：仕様書無しさん：2013/06/04(火) 03:14:45.61

このスレが埋まりそうなのも心配

978 ：忍法帖【Lv=10,xxxPT】(1+0：5) ：2013/06/04(火) 22:42:11.68

tes

979 ：仕様書無しさん：2013/06/04(火) 23:03:38.97

これからコードを書く人に絶対やって欲しいこと★3
ttp://kohada.2ch.net/test/read.cgi/prog/1370353426/

980 ：仕様書無しさん：2013/06/05(水) 00:59:30.85

さば落ちか

981 ：仕様書無しさん：2013/06/05(水) 08:58:08.56

？

982 ：仕様書無しさん：2013/06/05(水) 20:04:09.80

うめ？