プログラマの雑談部屋 ★24
■ このスレッドは過去ログ倉庫に格納されています
>>21
チームプレイなんだからワンマンプレイは歓迎されないだろ 金もらってやるんだから、歓迎すべきでないのは素人レベルの奴 >>20
最初に既存を参考に〜とか言えばいいのに
もう一番直してほしい書き方はルール化しちゃって今後はこういう書き方で でよくない？ >>27
このケースみたいに周りに合わせられないタイプは、我が強いか、周囲に関心が無いんだと思う
改修を依頼した所で、
我が強いなら「今までこうやって来た！」って反発するし、
周囲に関心がないならそもそも周りがどういうコードを書いてるのか知らない
結果、指示した所だけ直して終わり
明日からも汚いコードを書き続けることになる
要するに空気が読めないアスペ
病気だから諦めるしかないよ >>7
自分と同じ書き方でないと読めないとか日曜プログラマに転職した方がいいんじゃないか
バグフィックスする時とかその人の書き方に合わせてやるぞ
あと流用ってコピペだろそういう設計が問題
それを譲っても元になる大事なとこなら外注に任せないだろ
まあパラダイムの世代が違うとかだと問題だが >>29
横からだけど、
流用を前提とした設計が良くないって言ってるように聞こえるけど何が問題なの？
というか時々ここで流用を否定してる奴がいるけどそれお前か？
流用を前提とした設計なり開発なんて基本中の基本だと思うんだけどその辺り詳しく教えてくれない？ うーん、でもどんなコードかなんとなくわかるなぁ
ステータス１つにクラス１つ割り当てちゃうような作り方 >>30
その人コピペ流用が駄目って言ってるだけに見えるけど
立ち位置ハッキリしてくんない？
流用駄目って言ってる人は俺には見当たらない 既存コードがクソ過ぎるパターンもあるからな
古いやり方が手入れたとこだけ直してあるから真似したらアカンやつとか 周りに合わせるとか全体主義かよ！
みなさんこれがジャップランド文化です 設計の本質がわかりやすいコードであれば
人に合わせる技術が無ければ設計能力が低いと見られても仕方がない 素材関係の大卒は理数系で良いの?
関数が理解できずにプログラムから離れた人が居たけど理数系ならAIエンジンくらい作れと思った 毎回周囲に合わせると心に誓ってるのに
気が付いたらマイルールだらけになってる
がまんできない >>38
深層意識でそんな気はさらさら無いんだろきっと 閏年のプログラムは取りあえず4で割れば良いよね？
次の特例は2100年。
知らねーよwww >>40
(*ﾟ∀ﾟ)ｂ 3月1日から1日引いて29日だったら閏年さ! >>41
OracleのLastDayだったかで2100年と
2400年に対応したカレンダー組んだことあるけど、
その会社なくなってしまった。 >>11
単純に脳みそのパラダイムが違うだけだろ
そいつは一人だけOOPの世界に生きてるけど、他の連中はそうではない
OOPできる奴とできない奴は絶対にチームを分けなきゃいかんのだが、PMが素人じゃしょうがねえか >>11
良し悪しはともかく単純にどんなコードか興味がある
実際のものに似せたコードをgistなり適当な場所に張り付けてくれ 周りに合わせてスタイルを変えるってそうとう難しいよ
普通に将棋を指せる人間が全くのドシロウトの打ち筋を模倣してくださいつっても無理でしょ？
プログラムもそれと同じ
ある程度のスキル差があると下手なコードは書きたくても書けなくなる
5重にネストした分岐
10パターンを超えるスイッチ
100行を超えるメソッド
全く関連性のないビジネスがミックスインされた正体不明のクラス
正規化とは無縁のデータベース
模倣しろって言われてもどうすりゃいいんだって頭抱えるしかないよこんなの >>30
流用≒コピペ改変という意味で言ってるならパラメタライズして1回書けば終わりじゃん？
N回コピペしたら最低でもその処理の保守コストがN倍になる
依存ツリーまで辿ったらNのオーダーじゃ済まない 空気読んだら同じ給料もらえるならいいけどな
もらえねえんだろうな 問題はそのうち１か所だけ修正入れたいってなったときだ >>49
1箇所だけ呼び出し先を別のクラスなりメソッドに置き換えるだけ
問題になるわけがない そのメソッドは新規モジュールだから
コピペならなおしたとこだけテストすればいいが
共通化してあると新規部分として丸々テストしないといけない >>51
修正箇所とそれに依存するコードのテスト
新規作成箇所とそれに依存するコードのテスト
影響範囲は同じ
モジュール化してあればテストそのものが容易になるので低コスト
コピペじゃテストの範囲や仕方を考えるだけで絶望的 影響範囲が同じでも
新規作成と一部修正じゃ
必要なテストケースの数がちがう
モジュール化でテストしやすくなるなら
部分ごとに同じモジュールを配置したっていい たとえ一箇所でしか使わないモジュールでも、
モジュールとしての意味構造を持たせようと努力する
ただ、なんでもかんでもデザパタでどうでもいいインターフェースを挟むのは、異論があるかもしれないね、コストもゼロではないし わからねえかなぁ
根本的に必要なテストボリュームは変わらない
どこをどうやってテストするのかがはっきりわかって簡単なのがモジュール
どこをどうテストするかはっきりせずテストそのものも難しいのがコピペ
これ常識
コピペするってことはその処理が別の処理に埋め込まれてしまうってこと
そうなると本来修正したかったことだけを分離してテストすることができないからテストの手間がめちゃくちゃ増える そう、>>7 >>11 のいうラッパーの多いコードというのが、実際どんなものか見てみたいものだねえ コピペもモジュール化もどっちもわかるんだよね
モジュールったって今回に使えるようになってる保証もないし
必要もない既存部分をいじってぶっ壊して文句言われるのは場所によっては最悪だ
一発で信用を失って終了の可能性もある
とするとこの環境でモジュール化の選択肢はない
コピペはまあ言わずもがなの問題が起きるが
範囲がコピペ部分に限定できるし
既存部分を壊すことはない
ってメリットもある
どっちもトレードオフの問題で
どちらを選択する可能性がある
って結論以外ねーだろこれ
議論にならない >>60
クソレガシー相手の商売は大変だね
テストも整備されてないコードベースとかどんだけ金積まれてもお断りだわ >範囲がコピペ部分に限定できるし
>既存部分を壊すことはない
ダウト >>58
やたらすげー勢いでラッパ作るソース見たことねぇ？
クラスも小粒でプロパティ１つ増やすのにクラス１個作っててそれが何の為かどこにも書いてなくてキレる
明らかに脳みそに異常がある奴のクラスの作り方
クラス図書かせたら回路図みてーになった
DBからデータ取ってくるだけなのに不思議 >>61
環境をバカにするのはやめろ
どうせお前一人がきたって何もできねぇだろ >>62
キチガイレスやめろ
お前の話は聞きたくない JUnitやってると
コピペの圧力と関数化の欲求の間で悶え死ぬ >>63
それValueObjectだろ
ちゃんとしたシステムだと基本中の基本だぞ？ >>67
把握できないぐらいクラス図
回路図みたいにしちゃって一体誰にとって何がいいの？ ValueObjectめんどい
アンラップしないといろんな演算子とかメソッドが使えなくなるし
それなりに便利にしようとおもったら
使うかどうかもわかんないメソッドいっぱいつくらないといけない
個人用に作るには重すぎる >>68
ValueObjectを理解してないな
値だぞ値
お前は1とか"Hello, world!"って値をクラス図で配線するのか？しねーだろ ValueObjectで頭をかかえる私大文系w
意味のある固まりで構造化された美しさが分からない
日本人の曖昧文化では抽象性の高いプログラミングに適正がないんだろうな
ジャップランドではこんな馬鹿が上に立っているんだw >>71
は？
でもソース読むときクラスはクラスなんだからクラス図に書けや
んでこのクラスはゴミクラスだから重要なクラスはこれとこれとこれですって説明しろよカス
あんまり細かいクラスを作っちゃうから粒度がわからない
これやっても詳細設計書が整備されてれば問題は起きない
問題はなんの資料も書かないくせにこれやるとどこで何やってるのかさっぱりわからない 日銭をかせぐのにあくせくしているので
高邁な美しさにまで心を配る余裕がないのです
ライブラリ設計者になれたらそういうの作りまくってやるのに
現実は雇われ土方
扱うのはＢｅａｎばっかりで
凝集度の高いオブジェクトの自作とは縁がありません >>73
もっかいいうぞ？
お前はintやstringをクラス図にいちいち全部書いて配線するのか？
するならもう匙を投げるしか無いので話は終わりだ
しないならValueObjectも同じことだと知れ >>73
この手のOOPをまったく理解してない残念な人ってやけに設計書を崇拝するよね
おそらくプログラムに構造らしい構造が全く無いから設計書で情報を水増し冗長化しないと理解できないんだろうな
ということを考えるとやっぱり設計書不要論は正解なんだろうな
OOPが設計の本質ってことを理解できない人がついてこれないだけでさ C#の構造体はクラス図に書かなくていいぞ
クラスじゃないからな >>75
世界中で使われて安定性が実証されてどこでも使える言語の基本クラスと
どこの馬の骨がつくったかわからん思い付きクラスを一緒にしていいわけあるか
バグったらまず疑わなきゃいけないし
改修するとき影響範囲を見なきゃいけないし >>78
だよね
俺も同意見
みんなが知ってる共通クラスと
個別に作ったのとじゃ
全然扱いが違うよ >>75
お前が作ったクラスは粒度も役目もなんもかんもわからないんだよ
絶対説明してもらわないとあかんよ >>83
ValueObjectは粒度も役目も明確
お前がわかってないだけ 役目は個々のクラス名から明らか
粒度はエンティティの構成要素
わかりやすすぎわろた >>30
そういう流用は参照による流用かメンテしない前提だろ
コピーしたらメンテってどうするの? >>84
ここでその構造を使う正当性が俺にはわからない
何を狙ってその仕組みを入れたの？
その仕組みを入れてあるところとないところの違いは何なの？ 例えば本来ならその仕組みを入れるべきところに入れてない箇所があったとしたら
俺にそれが判断できる明確な線引きはあるの？ >>89
責務を明確にしてカプセル化で防御する
オブジェクト指向の基本だ
stringじゃ何でも表現出来すぎて責務が曖昧すぎる
stringには注文番号でも従業員名でもなんでも入ってしまう
これじゃそいつの正体がまったくわからないし何をやりたいのかも曖昧だ
そいつに適用可能なオペレーションも多すぎて利用者は簡単に間違える
注文番号オブジェクト.substring(1, 5)果たしてこれは注文番号にとって正しいオペレーションなのか？ わからない…
一方で
class OrderNo {
private string asText;
... (略)
}
class EmployeeName {
private string asText;
... (略)
}
といったValueObjectを使えばそれが注文番号や従業員名であることが明確になる
適用可能なオペレーションはクラスのメソッドとして厳格に定義されるので利用者が間違えることもない
注文番号オブジェクト.substring(1, 5)が注文番号にとって正しくないオペレーションなら実行することはおろかビルドすらできない
もし仮に正しいオペレーションならIDEが補完をしてくれるドキュメントコメントで説明を表示してくれる
実にエレガントだ
美しい世界へようこそ OrderNoはフォーマットとか桁数とかあるからまだわからんでもない
EmployeeNameてｗ >>93
従業員名の最大長はint maxなのか？
従業員名に任意のシンボルを含んでも問題ない？
ファーストネームとラストネームの区別はない？
ロケールによって文字列表現を変更したりしない？
思考停止しないでもう少し考えようぜ
たかが従業員名でも君が考えている以上にドメイン知識は隠れてるものだよ >>92
そんなの仕様書に書いておいてくれればいいよ 誰を対象にしてソースに対策を入れてるのかわからない
なんも知らん奴がソースをいじることを想定してガードを入れてるバカに見える >>95
仕様書に書いてあるだけじゃ間違えるんだよ
どんなに仕様書を充実させたっていざコーディングするときにはただのstringだ
人間はstringにできることはなんだってやってしまう可能性がある >なんも知らん奴がソースをいじることを想定してガードを入れてるバカに見える
まったく違う
すべてを完全に理解して絶対に間違えない人間だけでチームが構成されているわけではないという前提でガードしてるんだよ
というか文字通り何も知らない新規要員が途中参加することもあるってことを想定できないって仕事で開発したことないのかな？ >>100
あーいやもういいや
なんかイスカンダルあるといいな
って奴らみたいだし だってもうなんのためにプログラム組んでるかわからないじゃない 抽象的思考能力に劣る日本人には仕方ないんだろw
自分が理解できないものを無意味と考える所に文系っぽい馬鹿さがあるんだよw
ValueObjectはジャップと違って白人様が考えたんだからな
抽象性で日本人は欧米中韓に極めて劣る
日本発の発明も文明も無いのがその証拠w >というか文字通り何も知らない新規要員が途中参加することもあるってことを想定
おまえら、お客さんのお金で遊んでるん？ >>106
＞ おまえら、お客さんのお金で遊んでるん？
あたりまえのことを聞くとは、おまえプログラマじゃないな？
もしかして馬鹿ユーザか？
客からもらった金は、もう俺らの金であって客の金じゃねーよ！
そして金もらって仕事するかどうかは契約による。
SES契約だったら、もう何もしないでずっと遊んでいるに決まってるじゃん？
請負い契約だったら必死でやるけど、
いまどき請負契約で受けるわけねーだろボケ！ その値をＤＢに突っ込むときとかファイルに書き出すときに
どうしてんか気になる valueobjectパターンってクラス激増するからあんま好きじゃない insert into emp (empID, empName)
values (nextval('empID_seq'),$emp_Name); >>110
クラス内での話でメソッドの戻り値とかは仕様に従って言語の型に戻してるんじゃないか
そうでなければ修正を要求できるだろ >>108
>客からもらった金は、もう俺らの金であって客の金じゃねーよ！
なんだ？ この泥棒。 はれのひの従業員かな？ >というか文字通り何も知らない新規要員が途中参加することもあるってことを想定
これガイジに入れていいレベルで
何やってるのか意味不明だろ しっかし、ガードが使えないと途端にコードって糞になるな。
ロジック組み上がる度にちゃんとリファクタしていかないと、目も当てられない状況になるっていうか、
なってるクソコード大杉だろ。 >>109
残業60以上してれば働かなくても大丈夫 >>117
残業60も必要な現場はこっちから切ろうぜ。 どこ行っても導入教育まともにやらないよな
設計書の場所だけ告知して放置だもん ■ このスレッドは過去ログ倉庫に格納されています
