2019年5月13日

「共通モジュールを使用して設計した先に待っている悲劇」を見事に表現した動画に「真顔で笑ってる」「今のコードがそれ」という地獄が集まる

私はコードがわかりませんが勢いで笑いました
234
笑う
岩佐和紀 / マスク・ド・ライジングサン @kazukiiwasa

素晴らしすぎてグーの音のでないw 個人的にはあんまりアホみたいにDRY化するのは嫌なタイプ。 twitter.com/MinoDriven/sta…

2019-05-13 14:59:01
yumi@猫、休む🐈 @nyanz82

おもろいっ! 実際は笑いごとではすまんけど。 (音出るよ、注意) twitter.com/MinoDriven/sta…

2019-05-12 22:37:38
よし @YossyIsland2

朝から腹筋崩壊した ほんこれ… 何も考えずに共通化する人多すぎ twitter.com/MinoDriven/sta…

2019-05-13 06:27:13
masahiko-Bot @amasahiko2

手足もげそうになるところで腹がよじれた。 しかしなぜか僕の顔は真顔だった。 twitter.com/MinoDriven/sta…

2019-05-12 21:15:24
あるあるすぎる
Winky @umebosiiiiiiiii

今の案件まさにこれwwwwww まじで勘弁してくれ twitter.com/MinoDriven/sta…

2019-05-13 00:27:41
がむ @gam0022

心当たりがありすぎる… 継承するよりコピペした方がマシなケース、けっこうあるよね…😞 twitter.com/MinoDriven/sta…

2019-05-12 23:24:13
KST @KASServerTF2

iPhoneプログラマー「なんか既視感が(BaseViewController)」 Androidプログラマー「すまんなわいもや(BaseActivity)」 twitter.com/MinoDriven/sta…

2019-05-12 21:54:59
KST @KASServerTF2

Baseクラス作ってそこに共有コード書くとだいたいつらいかんじになるよね twitter.com/MinoDriven/sta…

2019-05-12 21:57:36
ありとみ @shuntaro3

引きちぎるところにリアリティを感じる。 twitter.com/MinoDriven/sta…

2019-05-12 22:02:20
芸が細かい
marvelph @marvelph

オープンニングメニューの練炭と退職でダメだったw twitter.com/MinoDriven/sta…

2019-05-13 13:49:35
残りを読む(7)

コメント

sk @sk_exe 2019年5月13日
「同じ処理」ではなく「似たような処理」を共通化しようとしたのが失敗の始まり。
63
佐渡災炎 @sadscient 2019年5月13日
共通化の手法がまず間違ってる。共通基底クラスを作って継承しろよ。特定クラスに別処理が必要になったら仮想オーバーライドしてポリモーフィングで対処しろ。 「共通モジュール」とか昭和脳かよ。
11
arikui @arikuiruby 2019年5月13日
使用者側に合わせて書き換えないといけないほど密結合のコード塊を「モジュール」とは呼ばねえ。「ただ置き場所を変えただけのコード」だ。
36
のりしあん @noricyan2 2019年5月13日
この問題をこうすればいいはずなんて言い捨てるのは、本質が分かっていない。
15
kusano @t_kusano 2019年5月13日
共通モジュールに専用分岐を入れた時点で共通化の範囲は変わっているので、そこで共通モジュールを再構築(リファクタリング)するべきなんだよなあ。専用分岐を入れる=すなわち陳腐化した(設計と合ってない)コードなんだよね。こまめに再構築。テストコスト?アーアーキコエナイー
17
Daregada @daichi14657 2019年5月13日
テストの手の字も出てこなかったので、リファクタリングと言いつつ、実際は「行き当たりばったりで書き換え、運を天に任す」じゃねーかな
6
Yeme @yer_meme 2019年5月13日
共通化すべきなのは「同じ意図の処理」であって「同じコード」じゃないっスよ。分岐必須になった時点で意図が違うんスから分けるべきっス。
46
trycatch777 @trycatch777 2019年5月13日
モジュール6個分の専用処理が入っているクラスがあって(元・共通クラス)、それが6個分別々の場所に存在する、という恐ろしい状態の未来を見た。
4
あるす@ただいま休職中 @ars015 2019年5月13日
素晴らしいまでに現実的すぎてワラエナイ
4
しろうと @sirouto 2019年5月13日
何も考えず「共通モジュール」化して、結果的に密結合化した失敗例。しかし、今ある行数を減らすため、「処理を共通化」するのは手続き的発想。将来の変更コストを下げるため、「責務によって分割」するのが、オブジェクト指向的発想。OOで組むなら「単一責務の原則」があり、クラスの変更理由が複数ある時点で、原則に沿ってない。そこで原則に沿うと、クラスの数は増える。が、「リファクタリング」を提唱したファウラーも、「基本データ型への執着」を克服して、「貨幣クラス」などのスモールオブジェクトを作ることを推奨している。
8
愚民Artane.🦀@オメガツイッタラー(最底辺限界ツイッタラー)/コロナは風邪じゃない@経験者 @Artanejp 2019年5月13日
途中まで見たけど、インタフェースの共通化とか、共用処理の分離レベルでやめときゃよかったのに。としか…(´・ω・`)
2
もふ大臣 @kodzura 2019年5月13日
「みんなちがって、みんなだめ」フレーズが浮かぶが『便利過ぎるモノに手を出すな』習慣により却下(とりま代用と辣韮の皮と実装遅延と問題側再分割のうち一番やりたいのに限ってやらせてもらえない
5
ポッカ @pokka80 2019年5月13日
共通モジュールに個別の判定処理入れるかよと言いたいが1回入れたわ
0
sake @sake_ne_ku 2019年5月13日
エンジニア炙り出し記事だ…
3
鹿 @a_hind 2019年5月13日
こういうのその場しのぎでやると必ずくっそ忙しい時に仇成す奴だからなあ。 後先考えない奴程その場しのぎでなんとかしようとするからこういうの好きだよね。
0
Off Black @OffBlack1 2019年5月14日
なんJ民のモジュールとか嫌すぎるwwログに実況とか吐かれてたら微妙にまちがえてはないけどなんかやだわwww
2
セマフォ @NoMoreLivesOne 2019年5月14日
似た処理は、同じ処理ではないよね。同じ処理だから「共通化」できるわけで。規格化と言う言葉を頭に浮かべよう。 ただまぁ、とりま時間ねぇしこれでやっつけっか!って言う判断は消せないので、どこかでお掃除する覚悟を必ず持とうね。
4
サディア・ラボン(ドラクエ10ではヒエロサロメ) @taddy_frog 2019年5月14日
F型ザクは汎用型なのでどこでも使えるよ。地上部隊「雨が降ってザクが壊れました!」地上の技術者「コロニーじゃ予想出来なかったな。改良してJ型作ろう」 宇宙部隊「地球の奴らが凄いザク作ったらしい。俺達も欲しいな」宇宙部隊仕官「宇宙での活動に必要な部品を外しちゃったらしいぞ。てか色々無茶な改造してるっぽい」 地上部隊「ザクではガンダムに勝てない。グフ作ったろ」
0
サディア・ラボン(ドラクエ10ではヒエロサロメ) @taddy_frog 2019年5月14日
taddy_frog 宇宙部隊「グフは地上に特化し過ぎて宇宙で使えるように改造できんな」 MS開発部「ドム作りました。部品の付け替えで地上用と宇宙用の換装が容易です」ジオン兵「俺達はこれを待ってたんだ!!!」
0
SAKURA87@多摩丁督 @Sakura87_net 2019年5月14日
共通処理だとおもって旅に出させて、帰ってきた結果を処理していたら、実は本家のプログラムはその動作がバグで直した際に本家以外の数百のプログラムの書き換えが必要になったりというパターンもあったりする。する…。
0
朝倉梗概 @asakura_outline 2019年5月14日
バージョン管理できなくて先祖がえりもあるよ
1
Naitoh @Naitoh10 2019年5月14日
staticにしても問題ない参照透過性の高いメソッドを集めた怠惰クラス以外を共通化するとだいたいこうなる
0
higanaichiniti @higanaichiniti 2019年5月14日
ポイントは「納期が近い」。怖すぎる…
3
あさぎ丸怪郎 @asagix 2019年5月14日
共通モジュールを各処理用にコピーするところから始めよう。
1
たろう @arx8l 2019年5月14日
どこもあるあるなんだねぇ… これをちゃんと笑える(あるいは怒れる)人がいるのが救いか
0
カメの子07_🐬🌱💞🦩❇️👑🌸 @westeye1182 2019年5月14日
バラバラにできないのなら共通コード内の使わないと分かってる部分もそのまま引きずれば良いのでは?(素人の感想)
1
gori.sh/aoki/140コロニー/comitia @gori_sh 2019年5月14日
余計なつながりを入れたせいで破綻する例を見せられているのに、さらに複雑化させようという提案が複数流れてて大草
0
青の666号 @mikata666 2019年5月14日
本当は責務ごとに分けた方がいいのは分かっていても、組み込みでROM容量が少ないような環境とかで…ついね…
0
ささみくん @3_3_me 2019年5月14日
ドントリピートユアセルフの精神やぞ
0
goya4 @goya4 2019年5月14日
『ブレイクポイントを設置しておけば』 ←ハイ、機械語脳な発想ですね(自覚あり)
0
lion @lion55571 2019年5月14日
ま、言語によるよね。ベッタベタのcだったりね。
1
frisky @friskymonpetit 2019年5月14日
その点、ユニケージ開発手法は「ループするな展開しろ」「関数化(コマンド化)するな直接記述しろ」、と上流ビジネスロジックの仕様変更をよく理解した開発手法になってるのよね。
1
frisky @friskymonpetit 2019年5月14日
この共通化も、仕様変更や体制変更がなければ「うまくいった共通化」だったのよね。うまく設計すれば仕様変更に耐えられるというのは幻想だと思うの。 現状のアプリ開発なら「コードの再利用性」よりも「初期開発コストを小さく、見通しよく」のほうが重要そうに思える。
1
いるーか @iruka12go 2019年5月14日
noricyan2 「納期が異様に短い」「正しい設計思想を持っているエンジニアがいない」、更に「システム運用にかけられる費用が少ない」という、時間・人・金の問題ですしねえ…。
5
arikui @arikuiruby 2019年5月14日
モジュールでもなんでもないものをモジュールと言い張るからこうなる。まだ「クラスAとクラスBの共通部分を雑に抜き出しただけのヤツです」って正直に書いとけばよかったのに。
1
bun🍃 @bun3559 2019年5月14日
共通モジュールの例といえば、元号⇔西暦変換ですね(白目)
0
うり @urium 2019年5月14日
RPGツクール製なのがおもしろい
0
Gothicgaze @Gothicgaze 2019年5月14日
分割した後、元共通処理だった部分を見直さなければならなくなって更に地獄を見る(見た)
5
ぼんぼ (千鳥饅頭) @tm_bonvo 2019年5月14日
共通モジュールってなんだよVB6かよ
0
kartis56 @kartis56 2019年5月14日
sadscient ポリモーフとかCOBOLじゃ使えないし
0
すいか @pear00234 2019年5月14日
恐らくソフトウェア開発において、「将来的な仕様変更時リスクを抑える」「コードを共通化して量を抑制する」ことは相反する命題なんではないだろうかと思うようになってきた。ぶっちゃけ、初期設計できっちり正しく作れば作るほど、仕様変更時のリスクやコストや複雑度が跳ね上がるイメージというか。結果論だけであれこれ言えれば楽なんだけどねぇ。
1
nsa @asnitk 2019年5月14日
継承使える言語なら基底クラスに、そうじゃない言語なら影響調査、そもそも粒度デカすぎ問題
0
kusano @t_kusano 2019年5月15日
pear00234 いや、共通化せずにコピペされたコードに仕様変更があると、あちこち同じように直さねばならなくなり、漏れるリスクがあるから相反してはいない。基本的にはDRY。共通化は正義。コピペは死すべし。
0
シロネコ @straypas 2019年5月15日
DRYを徹底しようって言い出すほど、この共通化の罠にはまりやすい DRYは正しいんだけど 共通化したコードをどのクラスが持つかの見極めが必要で この見極めをミスると変更に弱い共通化コードが誕生する (ブリッジパターンか委譲管理なら安全性が高くなりやすく、基底クラスや継承でやると安全性が低くなりやすい。状況によるけど)
1
テストアカウント @iir3YfMwe1IPasO 2019年5月16日
耳がいたい。こういうの昔量産してたわ。 似たような処理と同じ処理って違うからな。
0
HasHeadache @HasHeadache 2019年5月17日
未来を予見するなんてどだい無理なんですよ(開き直り)
1
mmsaito @mmsaito1987 2019年5月18日
DRYとテンプレートはは魅惑的ですからね.よくやってしまう.最初は「みなさんはこの2つのcallback/仮想メンバの実装をしてくれればいいんです」と簡単に始まっても,「うちはcallbackAの後に特別な後処理がいるんです」ということが必ず出てくる.では,optionalPostA を追加しましょう,などとやっていくと便利だったライブラリがひどく使用が難解になものに化けてしまう.
0
きゃっつ(Kats)⊿ @grayengineer 2019年10月21日
これは「共通化しようとしたこと」が悪いわけではなくて、設計の段階で仕様が確定していないのが原因なわけで、それは共通化に限らず開発の現場ではよくあるありふれた問題だよね。ちゃんと仕様が確定していれば、何を共通化すべきで何を個別にすべきかも確定するわけだから
0