プログラマの雑談部屋 ★24
■ このスレッドは過去ログ倉庫に格納されています
前スレに書いたら>>1000だったから立てたよ。
テンプレは内容読まずにコピペしたんだが
なんか変だね >>3
書き方が異質だからな
Cの眷属が主力の今においてVBしか出来ませんを公言してるようなもんだし クソ言語だけど、それ故にc#に無いhandles句とか言う謎文法が便利よ ちょい相談させて
少し前に入った外注さんの書くソースが独特で困惑してる
ソースが汚い訳でもバクがある訳でも無いし動作としては問題はない
ないんだけどロジックの組み立て方とかがうちのプロジェクトの常識？と違うから悪目立ちしてる
他のメンバーにも聞いてみたけどその人の書いてるコードは読みづらいって思ってるみたい
マネージャーに相談したんだけど
「ちゃんと動くならそれでいい」みたいなこと言うんだけど、こっちとしては流用元に使う事もあるから困ってる
ただ、改修してもらうにしても明確なルールがある訳じゃないから何をどうお願いしたらいいのか難しいところ
こういうのってどうしたら良いと思う？
こっちが慣れるしかないのかね >>7
マネージャがいいって言ってるんだから問題ないんだろ
慣れろ >>7
コードレビューして意識共有＆リファクタだな
ちゃんと設計してたらそんな独特にならんけども >>9
マネージャーは自分でプログラムを書かない事もあってか、要件通りにプログラムが動けばいいって感じの人だからコードレビューとかにコストをかけないんだよね >>7
補足すると、一度しか使わない構造体とかクラスとかラッパーとかを大量に作る感じと言えばいいのかな
処理を分割する為にプライベートで作るのは分かるけどすごく小さい単位で作るからデバッグ時とかにすごく追いかけづらいんだよね >>11
設計書書かせないからだね
そういう奴に設計書書かせると
途端にクラスを作らなくなる
書くの面倒だからｗ
結局自分だって把握できない量の
おしっこを大量に散布して
自分しか触れないようにする手法
名付けて犬のしょんべん作戦 >>7
そもそもお前が未熟だからいけない
いい設計とは何か？
答えられないだろ？
そいつの書くソースは明らかにそこから逸脱しているから読みにくい
でも言葉でお前はそれを表現できないから指摘できない
参考までに俺のいい設計の
定義を書くと
何の機能のどの処理が
ソースのどこに書いてるか
誰にでもわかること
これがわかんねーから
そいつのソースは読みにくい >>7
外注なんだろ
実装でツベコベ言うなら頼むなって感じ
どうせ外注先の未経験派遣が低単価で一生懸命作ってくれてんだからむしろ動くだけ偉いと褒めてやれ >>11
現物見ないと、勝手なこと言えないから、わからん。 >>12
ションベン撒き散らした挙句に条件良いところがあるとさっさとトンズラ、PMはツベコベ言わず引き継げバグ修正しろの一点張りでデスマの後に故障退場までがテンプレート 外注したとこのコードなんて見なくていいだろ
外部に繋がってるとこだけ見りゃいいじゃん >>11
実際に見てみないと、
外注が独りよがりか現場のクラス不慣れかわからん
YAGNIとかKISSとかよく言われるんで、
そこら辺で妥当かどうか相談してみたら？
ただ最初に上がってきた段階で相談してない時点で、
若干手遅れ感 >>19
あーそんな感じかも
機能を小さく単純にする事は大切だけど、1機能単体では何を目的としてるのかが分からなくなるまで細分化しちゃってる感じかな？
普通は相談とかしながら仕事になれていくうちにさじ加減を覚えるものだと思うけと、そういうのが出来ない人だから相談とかもせずに好き勝手にやっちゃうんだろうな 才能のあるプログラマーの書いたコードを読めない低脳文系が才能ある人を潰す好例だな >>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にできることはなんだってやってしまう可能性がある >なんも知らん奴がソースをいじることを想定してガードを入れてるバカに見える
まったく違う
すべてを完全に理解して絶対に間違えない人間だけでチームが構成されているわけではないという前提でガードしてるんだよ
というか文字通り何も知らない新規要員が途中参加することもあるってことを想定できないって仕事で開発したことないのかな？ ■ このスレッドは過去ログ倉庫に格納されています
