【Java】DIコンテナって本当に便利か？

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2008/08/20(水) 23:23:26
インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどｗ
2008/09/17(水) 22:22:50
開発ペースが速くなるのは良いが、人的リスクはどうなるのかね？
少数精鋭だと事故や病気で欠員が出ると途端に回らなくなるが。
後メンテナンスにも「優秀な」人材が必要になったりしないよな？
ノウハウが属人化して「Aさんじゃないと判らない」なんてよく聞く死亡フラグだ。

（もちろん>>147は、そんな奴は優秀とは言わないとか
優秀な人材ならすぐ対応できるとか言うんだろうが）

普通の会社ではどうするかって？
そこそこの能力で替えが効く人間を大勢揃えるのさ。
もちろん、人間の替えが効くようにメジャーな言語や技術を選択して
必要なスキルレベルも最低ランクの人材に合わせる。
これならメンテナンスする人材もすぐ都合がつくしな。

100人月とかの開発で必要な「優秀な」人材ってのは、
こういった面も見据えて適切な技術を選択したり
必要であれば独自フレームワークを設計したり
開発チーム全体のスキルレベルの底上げを行ったりできる開発者だろな。

なんて超アタリマエな事を偉そうに語ってすまん。
2008/09/17(水) 22:39:27
長いから1段目しか見てないが、
うちも少数精鋭で立て続けに二人居なくなって
あばばばばってなったよｗ
2008/09/17(水) 22:50:30
優秀な人間だけ30人も集められるわけがなかろう。
2008/09/17(水) 22:51:49
あいや上は無視してorz

まいずれにしても優秀な人間だけ集めるってのはやっぱり現実には無理がある。
優秀な人間は各プロジェクトに分散させるもんだからな。
152デフォルトの名無しさん
垢版 |
2008/09/17(水) 23:08:57
30人月って、3人x10ヶ月のことじゃないのか。
2008/09/17(水) 23:10:32
30人月だと普通は5人×6ヶ月くらいじゃね？
2008/09/17(水) 23:17:40
今の現場は人ばかりいてダラダラ1000人月は消化してるな。
プロジェクト管理？
決まってるじゃないか、エクセルだよ！
2008/09/18(木) 00:19:09
知らないうちにヘンなインスタンスと会話してたりするとコワイよなぁ・・・

DIコンテナってある意味、人間関係の希薄な現代社会みたい。
2008/09/18(木) 00:41:51
妹だと思ってお尻なでてたらお袋だった、みたいな？
2008/09/18(木) 00:52:58
>>148
欠員リスクはあるね。そこまで大きな仕事になると受けられないな。

で、引継ぎのほうなんだけど、運用保守要員のトレーニングも引き受けたり、
社内標準化と込みでやったりする。それに、そもそも特殊な技術を使うわけでもないし。

あと、俺の主張は「無能は使うな」であって、「優秀な人だけでやれ」ではないよ。
2008/09/18(木) 11:03:38
それすらも難しいのが結構現実…
2008/09/18(木) 17:50:47
ホントホント

2chに書き込んでるような俺らみたいなヤカラでさえ、
より良い設計に興味があるだけマシで
普通のPGは会社引けたら知らんぷりだもんな
2008/09/18(木) 20:43:51
まあ中にはPGには余計な知恵をつけて欲しくないとかで
DIコンテナとかの話するだけで目の敵にするような奴もいるしな。

…それはそれで正しいのか？そうは思いたくないが。
2008/09/18(木) 20:56:26
作業者(制御構造を書くだけ一般PG)にまでDIなんて意識させるか？
DIなんて裏方だし、骨組み作る人間だけが意識してれば良いじゃん。
2008/09/18(木) 21:06:49
そしてさらにPGの二極化が進むのであった。
2008/09/18(木) 21:19:46
日本って人材に甘すぎるのか、分からない分からないを繰り返して
残業しまくって成果物がゼロに近い奴が首にならないんだよな。
しばしば年収を意識しちゃって鬱になるよｗ

>>160
費用対効果だわな。
DIはOJTの範囲外なのでちょっと投資する必要がある。
2008/09/19(金) 00:43:31
>>161
実装者が理解できてないままだと
interface 使わないコードを平気で持ってくるわけだが。
お前さんのレビューのコストがバカになんねえよ。
実例挙げて教育した方が絶対早い。
分からないやつは切り捨てたらいいから。
2008/09/19(金) 20:35:47
>>164
理解させずとも「規約違反」で片付ければいいだろ。

ガチガチの規約ずくめのプロジェクトなら
そもそもPGが勝手にinterfaceを作ることすら「規約違反」だしな。
2008/09/19(金) 20:46:29
クラスの追加が承認制というようなこともするけどね。
レイヤ構成と機能毎の箱だけ用意しておいて、後はそこに
処理を書いてください、みたいな。

馬鹿にしているとも思うけど、悲しいかな、そうしないと
最低限の品質を保てないということもある。
2008/09/19(金) 23:10:35
>>166
それやっちゃうと3000行のメソッドや10000行のクラスが湧いて出たりしない?
そうならないように適切に分割したクラスやインターフェース書いて渡すの?
でもそういうのが判断できるとこまで設計したら、
中身も自分で書いた方がはるかに少ない工数で作れるよね……。
2008/09/19(金) 23:48:26
3000行のメソッドや10000行のクラスはさすがに無い。
レイヤ、機能までをそれなりに分割したものを渡すけど、
それでなくても今時3000行のメソッドは無いだろう(ﾟдﾟ )？

むしろ気をつける必要があるのは、重複する処理が作られること。
これはチェックして交通整理する必要有り。

工数というか効率に関しては、少数精鋭の方が良いのは勿論だけど、
1人で単位時間当たり1の成果を出すのではなく、10人かき集めて
単位時間当たり2の成果(効率は1/5)を求められることもある(´・ω・`)
2008/09/20(土) 11:51:27
優秀な人とそうでない人の差は生産性だけじゃない。
実際生産性自体は大きなな差はないこともある。
特に業務処理みたいなのの実装では。
しかし品質や保守性にはかなり差が出る。

業務処理とかじゃなくてもっと基盤よりの実装だったりして難度が高い部分だと
生産性にも品質にも保守性にもそれを使う側への影響にも大きな差がでる。
そもそも優秀じゃないと出来ないものもある。
2008/09/20(土) 12:27:40
>>168
1メソッド3000行はさすがに見たことないけど。

1000行のメソッドAの一部処理を別の1000行のメソッドBにしてあり、
メソッドBの一部処理をまた別の1000行のメソッドCにしてある、とかなら普通に見る。

ちなみに10000行どころか70000行程度のクラスまでなら普通に見る。
VB.NETのForm継承クラスに業務処理まで突っ込んだやつ。
2008/09/20(土) 14:07:32
まじかよ
2008/09/20(土) 15:21:57
ま〜なんだ。
DIの有用さが理解出来ない奴は、これまでテストをきちんとやって来なかった奴だな
2008/09/20(土) 18:30:26
組織を改善したければOJTという思考停止剤を経営者から奪わないといけない。
2008/09/20(土) 22:18:01
テスト以外に何かに使えねえかなあ。>DI
2008/09/20(土) 23:12:38
疎結合最高だよな、いやまじで。な人と
疎結合って何？食えるの？な人の振り分けに使える。

インターフェースと実装は分けるだろ、普通。な人と
実装継承最高!オブジェクト指向って継承しまくることだろ？な人の振り分けに使える。

ステートレスが基本だが場合によってはステートフルなロジックも必要か、な人と
メンバ変数ってクラス内グローバルで最強だよな。スレッドセーフ？わけわかんねえ横文字口走るなよ、な人の振り分けに使える。

100行超えるとキモいからクラスなりメソッドなりにして意味のある名前付けようぜ、な人と
3000行超えるメソッドや10000行超えるクラス作っても動けばそれでいいだろ、な人の振り分けに使える。

なんでコードをコピペすんだよ。3回同じこと書いたら首吊って死ね！な人と
コピペのどこが悪いんだよ、動けばそれでいいだろ、このタコが！な人の振り分けに使える。

なんでテストコード書かないの？馬鹿なの？な人と
テスト書く時間でコード書けばいいでしょ？早く帰りたいでしょ？な人の振り分けに使える。

用途はたくさんあるぞ。
176デフォルトの名無しさん
垢版 |
2008/09/21(日) 09:43:26
インタフェースを実装したクラスを継承してる奴らは多いけどな。
177デフォルトの名無しさん
垢版 |
2008/09/23(火) 01:45:47
＞ｽﾃｰﾄﾚｽが基本だが場合によってはｽﾃｰﾄﾌﾙなﾛｼﾞｯｸも必要か
自分も、業務ロジッククラスであっても値としてのプロパティを持たす事は少ないんだけど
(基本的にインターフェースだけプロパティに持たす)
これって普通なの？
状態を持たないクラスばかりであまりオブジェクト指向っぽくないかなと思ってた
2008/09/23(火) 02:17:20
一般的に対話型アプリは重厚なセッションを持つものだよ。
Webアプリがそうなるのはオブジェクトライフサイクルの都合かな。
スケーラビリティの都合と言い換えてもいいと思う。
2008/09/23(火) 06:00:48
>>175
DI の問題点というのはまさにそこで、
その振り分けを生き延びた精鋭にしか保守できないシステムを作りまくるわけですよね。

業務システムの開発という場面では、保守担当者を選ぶコードなど糞です。
2008/09/23(火) 12:02:46
>>179
一般的に >>175の内容で振り落とされた奴のコードはメンテし難いと思うんだが…

それからステートレス，ステートフル云々はwebアプリ実装する上では必須の知識でしょう。
まあ、それ以外でも必要だと思うけど。

OOP勉強すりゃ、DIなんて難しいこと何も無いと思うけどね。
スレッドプログラミング初心者にマルチスレッドサーバのメンテをさせることで金貰おうとしてないか？OOPも同じことだと思うんだが。
それで苦労するんなら、金貰って勉強できる分有り難いと思え。
それで勉強しないのなら諦めて辞めろと言いたい。
2008/09/23(火) 12:17:25
>>179は
「業務システムに適用するスキルレベルを引き下げないと保守要員が確保しづらい」という話をしてるのに
なんで>>180では
「保守したきゃスキルあげてこい」って話になるのかな？なるのかな？
2008/09/23(火) 12:26:54
OOP以前に、>>175で振り落とされるような人間はまともな構造化分析も出来ないだろうし。

業務による垂直方向の機能分割と、レイヤによる水辺方向の機能分割。
DIってのはそれを補助する仕組みにすぎないんだから。

あって困るものでないというものであって、精鋭でないと使えないなんていうのは
大きくな勘違いだと思うよ。

それが理解できないなら、煽りでなく、職業を変えた方が良いと思う。
2008/09/23(火) 12:43:56
DIのインフラを作ってしまえば後は誰が保守してもかまわんでしょ
初期設計にまともなプログラマが居れば良いだけ。
2008/09/23(火) 12:55:21
>>182
俺の言いたいこと全部言ってくれて助かったんだが、

＞それが理解できないなら、煽りでなく、職業を変えた方が良いと思う。
これ実践すると、日本のプログラマ人口は1/100以下になるよな。多分。
2008/09/23(火) 12:59:34
まあ理解力うんぬんより「OOP勉強するくらいなら業務知識仕入れるわ」な奴のが一般的だしな。
2008/09/23(火) 13:50:10
PGが業務知識云々を言い出すと負け犬みたいなイメージがあるな。
2008/09/23(火) 14:08:12
>>186
いや、それはむしろそっちの方が正しいだろ。

一般的な業務アプリの世界では、99/100の作業者PGには
テクニカルな事よりも業務知識を覚えさせて。

アーキテクチャとかは1/100な人間が決めて、作業者PGは
その枠組みの中で制御構造だけ書いていた方が効率が良い
…っというか、現実的ではあるから。

テクニカルな仕事がしたいのであれば、インフラ系、
製品開発、Web系、組込み系へいくべきだろう。
2008/09/23(火) 15:39:34
>>184
>これ実践すると、日本のプログラマ人口は1/100以下になるよな。多分。
でも残った人の仕事は逆に楽になっちゃう、みたいな。
2008/09/23(火) 15:45:40
ないない。
2008/09/23(火) 16:01:27
まあ、下の方の人間が多少減ったところで
結果として出る成果に違いは無いとも思うし、
居ても居なくても同じどころか、
むしろ居ない方が良い人間が居るのにも
同意はするが。

でも、矢面に立って無駄死にしてくれる人間が居ないと、
こっちにまで変なおはちが回ってくるので、
まあ、居ても良いよというか、そんなかんじかな。
2008/09/23(火) 21:45:03
漏れは普通(?)に「悪貨は良貨を駆逐する」と思うが。

業務知識も知らないよりは知っていた方がいいだろうけど、
それは最低限のエンジニアとしての力量があってから初めて役に立つのであって、
上（アーキテクトする人）の言う事も理解できんアフォが「業務知識」とか言うと胡散臭ぇ。
2008/09/23(火) 21:55:39
アーキテクトが「上」だとか、さらっと言っちゃう？
2008/09/23(火) 22:01:51
アーキテクトはむしろ「横」。
2008/09/23(火) 22:22:03
正直、PG程度に求められる業務知識なんて、
そんなたいしたもんじゃないけどな。
誰でもしばらくやっていれば身につく程度の内容で。

本当に業務知識があると思うのなら、
PGなんかやめて、それ専門で飯を食ったほうが
良いと思うし。

35歳で定年になったり、PG→SE(笑)→無能なPMと
ジョブチェンジして、現場に迷惑をかけたい奴は
技術より業務知識でもなんでも良いと思うが。

よく、転職情報とかにも業務知識がある人間が
不足しているみたいな事が書いてあるけど、
俺の感覚としては、本当に足りてないのは、
技術的なバックボーンを持って、意志決定できる
人間だと思うがな。
2008/09/23(火) 22:33:43
なんかスレ違いな話題が増えてきたけど、「業務知識」を言い出すＰＧは
信用しない方がいい、ってのは共通認識みたいだな。
2008/09/24(水) 11:24:48
そんな極論
修正してやる！
2008/09/24(水) 11:28:12
PGで優秀じゃなかったやつは大概ロクなSE/PMにならないけど
時々いるよね、顧客との折衝がうまくてSE向きの人とか、
人間関係調整するのがうまくてPM向きの人とか。
例え人差し指だけでキーボードを打ってても
2008/09/24(水) 11:29:02
ごめんスレとなんの関係もなかった
2008/09/24(水) 20:43:18
プログラムができないから、業務知識とか言い出す奴は困りものよね。

顧客の言うことをオウム返しするだけの無意味な存在になったり、
技術的背景が無いせいでにアホな設計をして、無駄な工数をかけて
デスマを引き起こしたりと、ろくなもんじゅない。

顧客と技術がわかる人間が差し向かいでやったときの生産性の高さを
一度経験してしまうと、そういうのって本当に馬鹿らしくてやって
いられない。

さらにスレ違いすまそ。
2008/09/24(水) 22:05:12
なんだこりゃ愚痴スレか。

偉そうにスレ違いな会話を続けるくらいだったらDIをもっと広める方法でも語ってくれよ。
業務知識とか言い出すPG（よほど恨みでもあるのか？）の説得方法とかさ。
2008/09/24(水) 22:15:02
DIコンテナ自体はもう十分コモディティ化していると思う。

コンテナ自体を布教したりDependency Injectionパターンを
どうこう語るよりも、DIを使ったプロダクトを盛り上げた方が
嬉しいんじゃないかな。
2008/09/25(木) 01:19:27
というより初期開発にアーキテクト役を置こうとしない組織をなんとかすべき。
いったんDIを無理矢理導入すれば、後は使い込むにつれ説明不要で依存し出す。
2008/09/25(木) 01:25:12
確かにキラーアプリがあると嬉しいところなんだが。

情熱と時間がないと無理よね。俺には無理。
2008/09/25(木) 01:34:19
>いったんDIを無理矢理導入すれば、後は使い込むにつれ説明不要で依存し出す。
無理。
オブジェクト指向言語使っても構造化以前の
スパゲティコード書くやついるでしょ。あれと同じ。

DI使ってるはずなのに、オブジェクトを名前で探し出してたり、
あるいはなんでもかんでも new してたりするから。

あなたが然るべき立場の人間で、現場でそれを強制するだけの発言力があれば話は別。
2008/09/25(木) 01:42:50
OO言語＝オブジェクト内グローバル変数の持てる言語
という導入から入っても俺は迷うことなくDIまで辿り着いたなぁ。
保守思考が高いか否かで、個人差が出るのかなと思ってる。
2008/09/27(土) 01:32:33
実際のところ、仕事で何か使ってる？

Springは「困ったら英語のドキュメントを読む人」でなければ使えない
Seasarは「困ったらソースコードを読む人」でなければ使えない

という印象。
少なくとも、チームリーダーがしっかりしてるレベルの部隊でないと
現状ではどちらも厳しいと思うのだが。
2008/09/27(土) 01:44:44
設定の外部化が善という宗教
記述量の削減が善という宗教
2008/09/27(土) 04:07:26
>>206
それくらいできない奴は、いなくなった方が楽になる
2008/09/27(土) 07:26:39
>>208
それは組織力のないチーム(=一匹狼の寄り合い所帯)の言い訳
2008/09/27(土) 08:15:02
それくらいもできなくて、できるようになろうとしない奴らは
それですむ仕事をすればいいのに、なんで開発者になるんだろうか？
2008/09/27(土) 09:33:43
まあダメダメSIer だと、良いプロジェクト == 儲かるプロジェクト == Hello World Javaモンキー１００匹突っ込めるプロジェクト
だったりするんで、実は心の奥底から生産性なんか求めてなかったりする。
組織力ってのも Javaモンキー１００匹集められるか否か、ただそれだけだったりもする。
2008/09/27(土) 10:18:41
なるほど、それに浸かりきったバカが自分のバカさすら忘れて
>>209みたいなことを言うんだね
2008/09/27(土) 15:50:54
なぜすぐ煽り合いになるのか？
2008/09/27(土) 16:14:50
だってここ2chだし
2008/09/27(土) 19:28:29
むしろ本当の少数精鋭チームならJava使わないだろもう
2008/09/27(土) 20:37:02
むしろ本当の少数精鋭チームならDI使わないだろもう
2008/09/27(土) 20:38:44
逆々
2008/09/27(土) 20:50:31
Javaを使っていないのであれば、DIを使っていなくてもおかしくは無いが
2008/09/27(土) 20:55:15
spring以外に選択肢が無いのが問題
s2はhackerのオモチャ
2008/09/27(土) 21:01:51
guiceは？
2008/09/27(土) 21:03:38
藁
2008/09/28(日) 18:56:38
http://d.hatena.ne.jp/higayasuo/20080928/1222594738
2008/09/28(日) 19:34:28
Seasar2は慣れればサクサクなのだろうがそこまでの道程は結構険しい

問題なのは、真剣に学習コストをかけて展開するほど
今後長持ちするとは思われていないところじゃないかな
2008/09/28(日) 19:36:44
一部のローカルグループのサークル活動に
人件費を裂くような馬鹿はいないだろ。
うちはWebBeansがJavaEEに載っかったら、
without EJBな連中とは決別する予定。
2008/09/28(日) 19:49:13
そのサークルの人、みんな飽きるのが早いからね…
仕事ではリスクが高くて採用できない
(請負で作っちゃって納品ﾊｲｻﾖﾅﾗなPJなら採用できるのはﾅｲｼｮ)
2008/09/28(日) 20:29:42
Javaはそういうのはまだマシな部類だと思うけどなー。
COBOLなんか大昔の極一部の俺流フレームワークが神扱いされてるから･･･。

それに比べればSeasar系はまだマシだろう。
2008/09/28(日) 20:40:46
タイミングと内容から言って本人による宣伝なのかなあ


キモ
2008/09/29(月) 02:30:39
>>224
without EJBっていつの時代だよ
2008/09/29(月) 20:12:09
>>226
自分より下を見てまだマシだ安心する訳ですね。
2008/09/29(月) 20:46:28
>>228
ロッド・ジョンソンは今でもwithout EJBだよ
2008/09/30(火) 00:56:51
声が大きいのはひが氏だろ・・
2008/09/30(火) 01:33:11
>>230
もうロッドのいうことを無条件に賛同してるやつはいないだろ。
2008/09/30(火) 01:55:47
とりあえずよりよいプログラムを目指してここで情報収集してる
少数派がいがみあってもしょうがない
234デフォルトの名無しさん
垢版 |
2008/10/02(木) 07:33:34
こんだけ盛り上がるってことはまだまだ微妙なんだろうな
seasarも全然さくさくじゃねーしなｗ
2008/10/19(日) 21:03:33
Springどこいったよｗ
236名無し募集中。。。
垢版 |
2008/10/20(月) 01:28:40
SAStrutsかなり最強だと思うけどなー
DIとは関係ない部分でだけど
2008/10/20(月) 03:18:26
DIと関係ある話してくれよ
238名無し募集中。。。
垢版 |
2008/10/20(月) 03:30:53
DIを意識させないようにしてあるって所でいいなってさ
2008/10/20(月) 06:56:59
SAStrutsはSeaserに依存しまくりでしょ？
SAStrutsをパクってコンテナに依存しないStruts拡張を作るのが吉。
2008/10/20(月) 07:14:32
Sersarに依存してたらなんか悪いことあるのか？
Strutsに依存してることはOKなのか？
2008/10/20(月) 07:47:49
本人が前にこういう事を言っていたけど。
ttp://d.hatena.ne.jp/higayasuo/20080613/1213326209
まあ、S2でいい人は別にSAStrutsで良いんじゃね。
2008/10/20(月) 07:53:13
いまやSpring死亡してS2浮上中だけどな
今はその時とは事情が全く違う
2008/10/20(月) 11:44:06
いやあのサポートポリシーはコミュニティが黙ってないだろうと思ったら
あっさり変更したじゃないか。springはまだまだ死亡しないだろ。
244デフォルトの名無しさん
垢版 |
2008/10/20(月) 13:24:25
よくわからんけど、プロダクトがコンテナに依存して
嬉しいことってあるの？
プロダクトを作る側ではなくて、使う側の話だけど。

非依存や切り替え可能にできるなら、その方が良くね？
特にSpringのゴタゴタとか見ていると。

T2はコンテナ非依存とか言ってるけどさ。よくわからんけど、プロダクトがコンテナに依存して
嬉しいことってあるの？
プロダクトを作る側ではなくて、使う側の話だけど。

非依存や切り替え可能にできるなら、その方が良くね？
特にSpringのゴタゴタとか見ていると。

T2はコンテナ非依存とか言ってるけどさ。
2008/10/20(月) 16:41:54
大事なことだから・・・・？
2008/10/20(月) 20:04:47
それこそ使う側だと選択肢が少ない方が脳を使わなくて済むと言う
メリットがあると言えなくもないが。

むしろ、作る側が非依存で切り替え可能だと、影響調査やバージョンの互換性
やらテスト項目がてんこ盛りで泣けてくるとだろうし。
2008/10/20(月) 20:59:50
>>244
なんで2回繰り返してんだ？

依存するとコンテナの機能をフルに使える。
それで使う側に有益な機能が実現されればメリットになる。
DB依存のSQLも同じだろ。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況