見通しの悪いコードができあがってしまう、その理由 - Magnolia Tech

クソコードができあがるのは「影響の及ぼすコンポーネント量を最小にする」という個別最適の価値観が支配的になった時、です 影響の及ぶ範囲を小さくするために、巨大で複雑なコードの塊を一箇所に追加し始めたりするのです そうした方が関心の範囲が限定できるから...だけど、全体最適ではない— magnoliak🍧 (@magnolia_k_) 2022年3月12日 でも悪気はないんです 真面目に巨大で見通しの悪いコードを作り上げていくけど、影響範囲が最小になる方が常に正しい、という価値観は「わかりやすい」んですよ— magnoliak🍧 (@magnolia_k_) 2022年3月12日 「変更量が最小になる」「影響が最小になる」...目の前のタスクをこなすためには、それが一番良いことに見えるんですよね でも、「継続的に同じペースが保てるか？」「スケールするか？」というと、そんなことは無いけど、そ

[ledsun]

コードの所有権の問題もあるんですよね。「変更量が少ない方がレビューが通りやすい」とか

[yetch]

能力ある複数人が覚悟を持って全体を把握する以外に解決策が無いという絶望。

[n_231]

まぁ他にも色々あるけどほとんどは短期的利益を求めて長期的損失を暗黙的に許容する人間の普遍的愚かさに起因する。定命の種族にプログラミングは向かないのである。

[turanukimaru]

ペアプロ・モブプロが最高にクソだと思うのは、設計し直すのが場の空気的に難しいこと。目の前の問題を解決した ! 俺最高にCoooool ! って相方に「いやこれ作り直すべきでしょ」とか言いにくい。いや言うんだけど疲れる

[versatile]

今となってはコードを書く時間よりも、n人以上が approve しないとダメ、というレビューにかかる時間の方が長くなりつつあるのである。ならば、変更行数を最低にして早くデプロイしたいというのは直感的な感情

[deep_one]

ちょっと違う。理由は「そんな修正をしなければならなくなった計画の見通しの悪さ」なのよね…

[sisya]

巨大コンポーネント恐怖症vs依存関係スパゲティ病の戦いみたいなところはある。個々人のワークメモリの差によって視野が狭いコードが出来てしまうのだと思っている。

[fukken]

往往にして、工数的に大変と思われる理想像を達成するための工数は、やってみると大したことなかったりするんだよな。

[toaruR]

工期の関係もあって、機能のまとまりの数より、並行作業人数が多いと、実装被りが同時多発してウワーってなる（´－｀）

[odakaho]

機能追加とリファクタとバグ修正は一緒のプルリクでやらんこと。

[uzulla]

「追加のこのケース、とりあえずこのIFを追加して完了」の愚を認識し、みな強く生きていきてほしい。

[auient]

全体最適でなく局所的個別最適(修正箇所が少なくて済む)が優勢になったときに見通しの悪いコードができる。背景には「権限がない」「興味がない」がある

[Sixeight]

悩ましい。目的のコードを最小限で書くのではなくて、目的のコードを将来的にも最小限で書くための努力が要るのかな。もっと簡単に書ける方法があるなら先に周辺を直したり、そもそも問題自体を疑ってみたり。

[ishikawa_pro]

わかる。 コードレビュー時に指摘しても、期日が近くて直す時間がないと言われるから、じゃあ何をレビューすればよかったんだよとよく思う

[Error401]

もうこれ書き直した方が速いでしょ、レベルのコードレビューをするコストとリスクが高すぎて、糞コードがはびこる

[noname774300]

個人的な趣味のコードだったら書き換えようと思ったら即書き換えられるし、ともすればプログラミング言語まで変えて見通しを追求できる😎

[lb501]

すごく長いSQL https://jp.quora.com/他人のコードや設計を見て1番これはあり得ないだろ

[a-kuma3]

「興味がない」に尽きると思う。動いてる（っぽい）コードの断片を切り貼りして、統合環境で場当たり的にコードをいじってなんとか動くところまで行きました、みたいなやつ。設計とかテストとかなんにも考えてない

[haccian]

むつかしい

[uxoru]

最近思うに、ソフト本体のコードレビューは不要で、テストプログラムのみレビューすればいいんじゃないかと。テストが通ればOK。ソフト本体がクソコードだったら、イチから作り直せばええと思ったり。

[unyaa]

https://onbin.hateblo.jp/entry/meigen002

[sonota88]

そしてビッグリライトへ

[morimarii]

コードって規格に沿った工業製品じゃなくて職人のプロダクト的な所あるから能力ある人間に委任する（≒バカは黙って座ってる）という非民主的な方法のほうが効率良かったりするが、中々に難しい所ある。

[hiroomi]

見通しと言えるところがステキ。

[xlc]

コンポーネントは使うものであって作るものではない。ヘタクソにコンポーネントを弄らせたらそりゃあ破綻もするだろう。

[buhoho]

単純な処理追加したいだけなのに何重もコンポーネント経由するトンネル掘るのとか、どこにトンネル掘ったらいいのかとか調べるのかっっっったるーーー！

[for-my-internet-demo]

変更範囲と影響範囲のちがいがちょっとイメージと違うんだが、モジュールや抽象を非定期的に分けずに見たままのとこにif文やメソッド追加するするみたいな話？

[otihateten3510]

コンポーネントの量をめちゃくちゃ増やして見通しが悪くなってるケースの方が遭遇する機会多いんだけど？ここ5年くらいかな。　／コンポーネント量を、ではなく「変更箇所を」なら理解できる

[rryu]

コードの修正範囲と影響範囲の大きさは比例しないというのが原因だと思う。ちょっと分岐を入れて一つのルーチンに複数の処理を重ね合わせていくと、やがて影響範囲が読めない化け物ができあがる。

[ducktoon]

見通しの悪いコードを書く人はエディタを使えてない。興味がないに該当するのかもしれないけど他のファイルにストレスなく瞬時に移動できないから今開いているソースになんでも書いてしまう

[Shinwiki]

設計も何もなくて、考えながら、書けるとこから場当たり的に作ってるから…という、問題以前の問題がありまして。

[PrivateIntMain]

ちょっと変えるだけなのにそんなにお金出せないよって言われますので。説明して納得して、じゃあやめるならまだしもこれしか金出せないけどやってって結論ならもう興味失せるよね。

[kamm]

1番の理由は矢継ぎ早に繰り出される仕様変更ではないの。最初から明確な仕様があれば、ほとんどの場合設計もきれいになるよ。

[satohu20xx]

変更量だけで考えると既存を触らないほうがいいので、リファクタしない文化が出来上がってしまいそう