- 1 名前：デフォルトの名無しさん [2016/05/19(木) 22:07:47.87 ID:9fCVrsOw.net]
- 手順とかノウハウとか語りたい
- 2 名前：デフォルトの名無しさん mailto:sage [2016/05/19(木) 22:30:15.79 ID:7RT/6RIS.net]
- まず服を脱ぎます
- 3 名前：デフォルトの名無しさん mailto:sage [2016/05/19(木) 23:11:13.52 ID:DISKdlQR.net]
- パンツを脱いだプログラマ
- 4 名前：デフォルトの名無しさん mailto:sage [2016/05/19(木) 23:13:39.91 ID:QjLNgnwx.net]
- >>1
ノウハウや成果物は20年前と比べて随分と公開されていると思うが。
スモールオブジェクトプログラミングとかGRASPとかエクササイズ等等。
- 5 名前：デフォルトの名無しさん mailto:sage [2016/05/19(木) 23:14:14.30 ID:P4wIeaTA.net]
- デザインパターンを研究しろ。
■■■■ 糸冬 了 ■■■■
- 6 名前：デフォルトの名無しさん mailto:sage [2016/05/19(木) 23:19:53.32 ID:QjLNgnwx.net]
- 今の時代、冗談抜きで語る事はないよ。国内の有識者がまとめた資料(SlideShare等)を
読むだけ。
- 7 名前：デフォルトの名無しさん [2016/05/20(金) 01:27:57.35 ID:0eowHHkD.net]
- 実務での設計・構築経験がある奴はいないのか？
誰かがこう言ってるじゃなくて、経験談を語り合いたい。
- 8 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 06:37:23.45 ID:A9KUpz/E.net]
- 経験談を語る＝有識者がこう言ったという事を蒸し返すだけだけど。
- 9 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 06:46:44.02 ID:A9KUpz/E.net]
- 後、今はこの手の話題はTwitterの方が向いている。
2chは発言の質が玉石混合であんまり参考にならない。昔は
いろいろスレが立っていたが。
ちなみにドメインモデル周りの成果物は機密保持の関係上、
あまり表に出てこないかな。
- 10 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 08:18:55.59 ID:fT3/H/UL.net]
- ドメインモデルの進化系がマイクロサービスだと思っている
- 11 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 09:38:37.61 ID:ezy2NA/m.net]
- >>10
進化系というかDDDでいうところの境界づけられたうんちゃらをマイクロサービスとして分離する基準にするとちょうどいいってだけだよね。
最近の小規模プロジェクトでもマイクロサービスを気軽に導入しちゃう雰囲気は謎。マイクロサービスをOOPとかと同列のソフトウェアデザインと考えている人が多いからなのか。
- 12 名前：デフォルトの名無しさん [2016/05/20(金) 11:45:46.78 ID:0eowHHkD.net]
- 本に書いてある指針に沿ってやってみても役に立つ部分と足りない部分がある。
実体験と本を読んだだけとは大きな違い。
例えば、オブジェクトの抽出はどうやってる？
仕様書から名詞を洗い出すとか言われることが多いけど、
すべての名詞がオブジェクトに対応する訳じゃない。
オブジェクトとする基準とかレベルとかどんな感じでやってる？
- 13 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 12:59:06.12 ID:tPlPBHxz.net]
- 分かりやすい名前をつければ、後は大した問題ではない
- 14 名前：デフォルトの名無しさん [2016/05/20(金) 13:01:40.82 ID:0eowHHkD.net]
- そんなんでシステムが構築できると思ってるのか？
- 15 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 13:42:47.84 ID:jCV1qcCq.net]
- 確かに
全ての変数に分かりにくい名前をつける事を強要された挙句
その名前をデータベースと言う名の紙の辞書に登録しなきゃならないっていう環境で起こる問題に比べたら
大した問題じゃないよな
- 16 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 13:42:47.94 ID:xL1EKSbm.net]
- サルでも解るように教えてくれ
- 17 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 13:44:27.63 ID:jCV1qcCq.net]
- >>16
考えるな、感じろ
直感と経験からオブジェクトにするものとクロージャにするものとを区別していけば
大きく間違えることはそんなに無い
- 18 名前：デフォルトの名無しさん [2016/05/20(金) 13:47:05.45 ID:0eowHHkD.net]
- 直感と経験って説明できないときに都合よく使う言葉だよなあ。
そんなんじゃ判断はばらばらになって品質が安定しない。
だからプロセスとか指針が重要なんだが。
- 19 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 13:54:08.42 ID:jCV1qcCq.net]
- 例えば飛行機の制御プログラムを組むとして、
そのプロセスやら指針やらはサルでも分かるようにきちんと説明できるの？
- 20 名前：デフォルトの名無しさん [2016/05/20(金) 13:55:31.32 ID:0eowHHkD.net]
- サルでも分かるようにってのは俺の書き込みじゃないから知らんけど
ある程度の知識がある奴が理解できる指針は提示する必要があるだろ。
- 21 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 13:57:21.26 ID:jCV1qcCq.net]
- もう一点。
複数のプロダクトの設計段階での判断がプロダクト毎に異なる事と、
それらプロダクトの品質とは関係あるの？
- 22 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 13:59:42.00 ID:jCV1qcCq.net]
- >>20
うん、必要があるか、無いか、で言ったら必要あるよね。
それが実行可能かどうかについて訊いたんだけどね。
- 23 名前：デフォルトの名無しさん [2016/05/20(金) 14:03:06.56 ID:0eowHHkD.net]
- お前が指針を提示できないことは分かったからいいよ。
まともな本を読んでりゃ指針が書かれていることくらい分かるから。
- 24 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 14:07:35.14 ID:6MfCjgLg.net]
- >>13
正解。設計と同じぐらい大事。
現場ではエンジニアが自由に名前決めすぎ。
- 25 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 14:08:53.28 ID:jCV1qcCq.net]
- 君が「本に書かれてるから絶対に正しいんだ」って姿勢を見せるのは結構な事だけど
質問に対する答えとして不適切な事を言っておきながら答えたことにするのは人間としてどうかと思うよ。
ちなみに
直感と経験、を具体的に言うと
動作の主体になって、状態を持つものはオブジェクト
動作の客体にしかならないものはクロージャ
みたいな感じに分けてるよ。
直感的でしょ？
- 26 名前：デフォルトの名無しさん [2016/05/20(金) 14:14:49.64 ID:0eowHHkD.net]
- >>25
本に書かれている指針を理解したうえで、実際のプロジェクトに適用したときの
経験について語ってくれってこと。どうして分からないかなあ…。
オブジェクトとクロージャの区別に拘るのは違和感があるんだけど開発言語は何？
言語によってはその区別が重要なんだろうか。
- 27 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 14:19:58.58 ID:jCV1qcCq.net]
- >>26
まずその本とやらの題名なりamazonのurlなりを具体的に示して欲しいかな？
本によって言ってることまちまちだしね。
趣味でx86_64アセンブリとLispを少々
- 28 名前：デフォルトの名無しさん [2016/05/20(金) 14:24:17.23 ID:0eowHHkD.net]
- 本によってまちまちだからこそ、実際に使ってみてどうだった？って感想が
聞きたいんだけど。
趣味レベルってことで納得。
Lispだとクロージャの役割が大きいのかなあ。
業務システムの設計・構築経験がある人の体験談を聞きたい。
- 29 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 14:28:12.35 ID:jCV1qcCq.net]
- > Lispだとクロージャの役割が大きいのかなあ。
というかクロージャを拡張したら割と簡単にオブジェクトが作れるから
そこまでする必要があるかどうかで自然とオブジェクトにするかどうかが決まる感じ
ところでこれ設計の話？それとも実装の話？
- 30 名前：デフォルトの名無しさん [2016/05/20(金) 14:31:52.11 ID:0eowHHkD.net]
- 設計の話だけど、構築するために設計するんだから構築段階で設計の品質が実体化するとも言える。
実装を無視した設計はあり得ないから、実装も設計に関係する。
- 31 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 14:32:58.18 ID:wXLR68d1.net]
- >>1
おれもそもそもOOPのメリットが分からん
OOPでうまくつくっていける奴は関数型でも
手続き型言語でもそれなれにやっていけそうだが
- 32 名前：デフォルトの名無しさん [2016/05/20(金) 14:41:33.00 ID:0eowHHkD.net]
- >>31
どの設計手法を使うにしても基礎は共通してるからある手法できれいな設計ができれば
他の手法を使うときも正しい使い方ができると思う。
手続き型よりもオブジェクト指向のほうが構成要素の区切りが明確になりやすいのがメリットだと思う。
関数型の設計手法はどんなものか分からないや。
- 33 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 14:42:40.60 ID:jCV1qcCq.net]
- OOPって要するに分割統治をアグレッシブにやってるだけと違うの？
- 34 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 15:06:25.53 ID:xWTkKLUb.net]
- OOPスパゲッテー依存で後で泣く
インターフェース
クラス
ウーーーーー
もう少しいい言語設計を
- 35 名前：デフォルトの名無しさん [2016/05/20(金) 15:42:04.87 ID:0eowHHkD.net]
- >>34
それは設計が悪い。
- 36 名前：デフォルトの名無しさん [2016/05/20(金) 15:42:33.48 ID:0eowHHkD.net]
- 言語設計じゃなくてシステム設計が悪い。
- 37 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 17:57:03.05 ID:xL1EKSbm.net]
- OOPダメみたいな流れはどうして？
JavaやC#どっぷりのオレは、生きていけないの？
- 38 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 18:03:59.50 ID:JTjd3aWK.net]
- OOPはモジュール作成者にメリットはあっても
利用者にはメリットはないんだよ
- 39 名前：デフォルトの名無しさん [2016/05/20(金) 20:52:17.59 ID:0eowHHkD.net]
- >>37
オブジェクト指向をきちんと活用するのは難しいからじゃね。
素人には理解できない。
まちがった使い方をする。
間違ってるのは素人の俺じゃなくてオブジェクト指向だ。
って流れだと思う。
- 40 名前：デフォルトの名無しさん [2016/05/20(金) 20:55:01.79 ID:0eowHHkD.net]
- >>38
システムの改修が容易だというのは利用者にとってもメリットだな。
システムの改修を容易にできるだけの洗練された設計が実現できていることは少ないから
オブジェクト指向のメリットを実感できない設計が多いのかもしれないけど。
オブジェクト指向が悪いんじゃなくて、設計者が要求されるレベルに達していないことが多いだけ。
- 41 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 21:00:29.42 ID:fT3/H/UL.net]
- 利用者にメリットがないとか言ってるやつに限って
OCPすら満たしてないシステム作ってそう
- 42 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 21:13:45.60 ID:JHcTy9r/.net]
- 関数型の匿名関数に積極的に名前を付けていくとOOPになる感じ
- 43 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 21:49:33.16 ID:lJQ06Hkz.net]
- OOPは悪くはないけどメリット少ない
親クラスを継承する必要性も少ないし
DBのSELECT結果をオブジェクトに入れる必要もない
- 44 名前：デフォルトの名無しさん [2016/05/20(金) 21:52:47.80 ID:0eowHHkD.net]
- >>43
継承を推奨してる設計指針なんて見たことないけど。
オブジェクト指向設計について語りたいならまともな本を読んでからにしようぜ。
- 45 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 21:54:23.51 ID:fT3/H/UL.net]
- >>43
継承と移譲について理解しようね
- 46 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 22:19:45.27 ID:5OAEQxQd.net]
- 継承はアンチパターン
- 47 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 22:39:20.85 ID:lJQ06Hkz.net]
- >>44
推奨とか知らんけど実際の現場では継承されまくってるだろ
>>45
理解してるから言ってる。基本継承は不要。移譲だけでいいぐらい
- 48 名前：デフォルトの名無しさん [2016/05/20(金) 22:43:46.88 ID:0eowHHkD.net]
- >>47
継承を利用すべきじゃない場面でも継承が利用されているのは問題であるってほとんどの本に書いてあるぞ。
まともな本すら読まずに間違った設計をしているからメリットを実感できないだけで設計者のレベルが低いだけ。
- 49 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 22:48:17.41 ID:lJQ06Hkz.net]
- >>48
じゃああんたが言ってることと俺が言ってることは同じじゃんか
何で俺は噛み付かれたんだ
- 50 名前：デフォルトの名無しさん [2016/05/20(金) 22:50:13.54 ID:0eowHHkD.net]
- >>47
継承を利用すべきじゃない場面でも継承が利用されているのは問題であるってほとんどの本に書いてあるぞ。
まともな本すら読まずに間違った設計をしているからメリットを実感できないだけで設計者のレベルが低いだけ。
- 51 名前：デフォルトの名無しさん [2016/05/20(金) 22:51:14.89 ID:0eowHHkD.net]
- >>49
×OOPはメリット少ない
○バカな設計者が設計するシステムはダメ
全然違う。
- 52 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 22:53:29.65 ID:ALiU1X8u.net]
- こういう展開は今まで何度も何度も見たが
「OOPのメリットはこれとこれとこれだ！」
という歯切れのいい意見を一度として聞いたことが無い
- 53 名前：デフォルトの名無しさん [2016/05/20(金) 22:54:45.09 ID:0eowHHkD.net]
- >>52
>>32
ほとんどの本にこういったことが書かれているし、実感としても合ってる。
- 54 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 22:59:42.47 ID:5OAEQxQd.net]
- SOLIDしやすいのがメリット
- 55 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 23:17:55.91 ID:Zd4GCHrY.net]
- 継承はアンチパターンと思うのはまだ恵まれている方だ。俺は継承をしてくれなくて困ることの方が多い。コピペの嵐ぱない。
- 56 名前：デフォルトの名無しさん [2016/05/20(金) 23:23:18.18 ID:Ykc02+7p.net]
- それはオブジェクト指向とか以前の話だわ
- 57 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 23:25:43.35 ID:5OAEQxQd.net]
- コピペと継承関係ねえぞ
- 58 名前：デフォルトの名無しさん [2016/05/20(金) 23:27:16.59 ID:0eowHHkD.net]
- >>57
親クラスに一回記述すれば済むのに
別々のクラスの両方に同じコードが書かれているってことだろ。
- 59 名前：デフォルトの名無しさん mailto:sage [2016/05/20(金) 23:48:05.55 ID:5OAEQxQd.net]
- いやだからそれ継承どうこうじゃねえよ
- 60 名前：デフォルトの名無しさん [2016/05/20(金) 23:52:47.17 ID:0eowHHkD.net]
- >>59
お前が言いたいことはみんな分かってるだろうから会話の流れも読もうぜ。
- 61 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 00:07:02.79 ID:q2Zh6d9K.net]
- >>49
> 何で俺は噛み付かれたんだ
そこにお前がいるから（名言）
- 62 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 00:07:37.44 ID:RrD1FkH/.net]
- >>59
お前の存在自体がアンチパターンだなｗｗｗ
- 63 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 00:09:06.75 ID:hclWowah.net]
- >>58
親クラスは便利物置場じゃないからな
- 64 名前：デフォルトの名無しさん [2016/05/21(土) 00:14:14.80 ID:Dey5A/Jl.net]
- オブジェクト指向設計の経験がある奴はおらんのか？
- 65 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 00:17:03.45 ID:hclWowah.net]
- 実装レベルの設計なんか必要ないでしょ。
設計が必要なのは業務ロジックまで。
実装レベルの設計が必要なのは
相当プログラマーのレベルが低い場合のみ。
- 66 名前：デフォルトの名無しさん [2016/05/21(土) 00:24:35.47 ID:Dey5A/Jl.net]
- 実装レベルの設計って曖昧だけど
クラスと公開されたメソッドは決める必要がある。
で、それを決めるためにはクラス間の関連を考える必要がある。
ってなるとそれなりに詳細に設計することになるが。
- 67 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 00:27:38.10 ID:pCEMwj0Q.net]
- 個人で開発してるならいらんかも知らんけど
チームで実装する場合はクラス図とシーケンス図ぐらいは必要じゃね
まぁ個人でやる場合も10年後にメンテする人のために残しといた方がいいけどな
10年もたてば実装した本人も忘れてるだろ
- 68 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 00:27:53.71 ID:q2Zh6d9K.net]
- >>65
> 設計が必要なのは業務ロジックまで。
業務ロジックの設計って
具体的にどんなことや？
- 69 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 00:34:44.35 ID:sajHzwwt.net]
- そこらへんはシステムの特性やエンジニアの質など様々な要因で変わるから永遠に議論が終わらない話題だね。
- 70 名前：デフォルトの名無しさん [2016/05/21(土) 00:36:09.71 ID:Dey5A/Jl.net]
- >>68
>>65がどういう意味で書いたのかは知らんが、要件定義的な作業は必要だろ。
UMLで言えばスイムレーンに分けたアクティビティ図を書くとか。
- 71 名前：デフォルトの名無しさん [2016/05/21(土) 01:06:07.75 ID:Dey5A/Jl.net]
- >>69
しかし、実際のプロジェクトでは何らかの基準で決める訳でルールは必要。
ルールもなしに場当たり的に決めているならお話にならない。
- 72 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 09:34:19.36 ID:4qmWB+Wj.net]
- >>71
お前は何がしたいんだ？
研究したいなら大学に行くといいよ
現実では直感と経験でだいたい全部決めてる。
実装する時には例えばGoogleのスタイルガイドに合わせるとか、
既存のコードから空気読むとか、
何らかのルールがあるのは確かだけど
設計の段階でそんなこと言ってたらプロジェクトは進まない。
- 73 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 09:51:01.31 ID:zSvCOHYP.net]
- >>67
資料より対話の方が大事
図や文章はあくまで補助のメモ書きだね
- 74 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 10:22:35.74 ID:hclWowah.net]
- >>67
シーケンス図は業務で必要だね
クラス図は今まで一度も必要になったことがない
クラス図が必要なほど複雑なクラス構成にすること自体間違ってると思う
>>72
直感と経験で決めるやつがリーダーで
チーム内の統一までやってくれればいいんだけどね
1メンバーがマイルールで直感と経験で独断で決めるのはどうかと思う
チーム内にルールは必要だし、大学とか研究とかは関係ない
- 75 名前：デフォルトの名無しさん [2016/05/21(土) 10:28:49.34 ID:Dey5A/Jl.net]
- >>72
だから、実際のプロジェクトでは決めるんだから何らかの基準で判断してるんだろ。
- 76 名前：デフォルトの名無しさん [2016/05/21(土) 10:30:45.98 ID:Dey5A/Jl.net]
- >>73
資料がないと改修で泣くよ。
- 77 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 10:31:01.96 ID:4qmWB+Wj.net]
- >>74
誰が一人で設計すると言ったね
要件と要求を元に設計は成される物だから、当然複数人で話し合って物事は決まっていく。
その中で、経験上これはこうした方が良い気がする、とか
直感的にこれはまずいんじゃねーかと思う、とか
そういう話なんだが。
もしかして君は複数人で設計した事が一度も無いの？
- 78 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 10:32:32.20 ID:4qmWB+Wj.net]
- >>75
実際のプロジェクト毎にその基準が変わるから
ある一つのプロジェクトについて「これはこうだったあれはああだった」って言っても
意味が無いんだよ。
- 79 名前：デフォルトの名無しさん [2016/05/21(土) 10:32:37.55 ID:Dey5A/Jl.net]
- >>74
クラス図が必要なほど複雑なクラス構成にすること自体間違ってると思うってのは
簡単なシステムしか作ってないからそんなこと言うんだろな。
- 80 名前：デフォルトの名無しさん [2016/05/21(土) 10:34:45.75 ID:Dey5A/Jl.net]
- >>78
説明できるだけの経験がない、しっかりした基準がないてきとーな判断をしてる。
どっちかだろ？
- 81 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 10:37:30.66 ID:4qmWB+Wj.net]
- >>80
そこまで他人をこき下ろす以上は、君はそういった経験が豊富なんだよね？
ちょっと語ってくれないか。
君が経験したプロジェクトに基づいて、どういう手法を採用し、どういう問題が起きたか。
- 82 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 10:38:13.47 ID:q2Zh6d9K.net]
- どういう手法？
人海戦術とノミニケーションだろｗｗｗｗ
- 83 名前：デフォルトの名無しさん [2016/05/21(土) 10:42:52.87 ID:Dey5A/Jl.net]
- >>81
会話の内容からしてお前よりははるかにあるだろう。
俺の経験はちょっとずつ出してる。
他の人の経験を聞きたいから、自分の考えを一方的に語りたくない。
- 84 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 10:45:22.63 ID:4qmWB+Wj.net]
- >>83
そうともさ
俺は20代なんだから君のほうが経験が豊富かも知れないけど、それが何だと言うんだ
で、俺は君の経験を聞きたいんだけど？
どんどん語ってくれよ。
- 85 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 10:47:07.78 ID:q2Zh6d9K.net]
- >>84
お前も少ない経験でいいから語れよｗ
お前がどこの誰か特定できるように
細かくな。
- 86 名前：デフォルトの名無しさん [2016/05/21(土) 10:48:18.26 ID:Dey5A/Jl.net]
- >>84
プロジェクトを進めるためには決めなければいけないんだから
そのときにどいうい基準で決めるのがいいんだろうか？って考える癖を付けると実力が上がる。
実際、決めなきゃ進まないんだから決めているのにある選択をした理由をちゃんと考えて記録しないのは
だめなプロジェクトで良くみる。
- 87 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 11:08:42.80 ID:zSvCOHYP.net]
- >>76
資料無いと泣くようなシステムから脱却したいね
- 88 名前：デフォルトの名無しさん [2016/05/21(土) 11:09:50.85 ID:Dey5A/Jl.net]
- >>87
どうやって？
- 89 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 11:12:20.08 ID:4qmWB+Wj.net]
- >>85
おーけい。
ある会社のインターンでの話なんだが
Google Chromeって名前のWebブラウザあるだろ？
あいつがメモリをバカ食いするのは当時でも有名でね。
どのモジュールがどのくらいメモリを食っていて、どれだけ無駄が出ているかってのを調べるために
コンパイラを改造する仕事を割り当てて貰ったんだ。
コンパイラを改造して、コンパイル時に適切なコードを差し込むことによって
Chrome自体のコードを改変せずにメモリの詳細な統計データを得ることが出来るようになる事が目的だった。
実際にはChromeじゃなくてオープンソースのChromiumの方だけどな。
果たして、それは上手く行かなかった。
というのも、オブジェクト間に参照のループがあったり
同じクラスから別の意味を持つクラスが派生してたりして
Chromium全体が密結合になっており、
「どのクラスのインスタンスがどれだけメモリを食っているか」という情報はあまり役に立たなかったんだ。
結論：オブジェクト指向設計を下手に導入すると、メンテナンス性が下がる
- 90 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 11:12:22.49 ID:zSvCOHYP.net]
- >>88
美しいコードを書けってこと
結局のところそれだけなんだよね
- 91 名前：デフォルトの名無しさん [2016/05/21(土) 11:14:11.26 ID:Dey5A/Jl.net]
- >>89
Javaで書かれてる？
- 92 名前：デフォルトの名無しさん [2016/05/21(土) 11:15:01.57 ID:Dey5A/Jl.net]
- >>90
コメントは書く？
- 93 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 11:16:06.62 ID:hclWowah.net]
- ここにいるやつらは2chでまで設計議論するような勤勉なやつらだから
書くコードはみんな美しいだろうな
それをチーム内に統一するのがなかなか難しいんだよ
ルール作っても守らないやつは守らないし
そもそも勤勉なやつのほうが少ないから勤勉なやつにいつも負荷かかる
- 94 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 11:16:39.20 ID:4qmWB+Wj.net]
- >>91
c++03で書かれてた
- 95 名前：デフォルトの名無しさん [2016/05/21(土) 11:18:54.32 ID:Dey5A/Jl.net]
- >>94
C++は知らないけどメモリの状態を出力する機能くらいあるだろ？
それ使えば一発だったな。
- 96 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 11:20:45.55 ID:4qmWB+Wj.net]
- >>93
うちの場合、c++なら
Makefileにcpplint.pyによるチェックが書かれてて
Googleのスタイルガイドから逸脱したコードはそもそもコンパイルできないようにしてる。
- 97 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 11:22:33.52 ID:zSvCOHYP.net]
- >>92
コードで意図を表明出来ない場合にのみ書く
- 98 名前：デフォルトの名無しさん mailto:sage [2016/05/21(土) 11:22:
]
- [ここ壊れてます]
- 99 名前：43.32 ID:4qmWB+Wj.net mailto: >>95
そんな機能無かったよ？
精々がdlmallocをtcmallocに置き換えて、いつどれだけメモリが確保されたか調べれる程度。 [] - [ここ壊れてます]
- 100 名前：デフォルトの名無しさん [2016/05/21(土) 11:25:54.47 ID:Dey5A/Jl.net]
- >>98
その機能がC++にないとは思えないけどなあ。
Javaにはある。
|
 |
