糞コードは直すな。 - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? とりあえず落ち着け。 みなさん、毎日なにかしらのコードを読み、開発する日々を送っていると思います。そんな中で、 糞コードは死ぬべきである！！絶対に直すべき！！ という感情に取りつかれてしまうことがあると思います。自分の技術力に自信のある人ほど、無理やりにでも直そうと試みると思います。それがどんな修羅の道か。そして、糞コード修正がどんな道を歩むのか。この記事では糞コード修正の罠とありがちなストーリーについて書きたいと思います。 ビジネスとしてのプログラムは本質的に糞である 例えば、「携帯電話の利用料金」のプログラムがあります。 「携帯電話

[ryunosinfx]

正確には「金の成る木である既存コードが糞でも安易に直すな。」じゃないですかね。もしくは「安易な糞コードの直しは角を矯めて牛を殺す」ですかね。

[zu2]

レガシーコードの保存は局所解なので、どっかで大破綻するのだけど、それまでの期間は想定以上に長い。コードだけじゃないよな、この話。組織だったり、人間関係だったり。

[greenbow]

ビジネスロジックの複雑さによる複雑なコードは糞コードではないのでは。まずは「糞コード」を定義してほしい

[otihateten3510]

クソコードは直せ、仕様・ビジネススキームから直せ、できないなら去れ　が僕の方針です。なので去ります。|彡ｻｯ　／大事なのはビジネス層から設計者が関わることだ。それが難しいんだけど。

[develtaro]

糞コードの反対は綺麗なコードじゃないな。綺麗な糞コードもよく見るわ。ああ、昔俺の書いたコードがそうだよ！直して跡形もなくせ！

[hogeaegxa]

「ビジネスを簡単にとらえすぎている」ってのは新人じゃなくても、業務側の客と一切接しないようなコーダーにはありがちだと思う。全てを網羅する完全なるUTとかいうのも理想主義でしかないしなあ。

[kumapo0313]

私は糞コードではなく、レガシーコードと呼ぶことにしています。

[Silica]

先日流れてきた>https://twitter.com/kansai_gaijin/status/1286735675052630017

[MasaoBlue]

言い換えると「ビジネスをシンプルに保とう」なんだろうか。でも複雑だからこそ多用なユーザーが利益を享受できている場合もあるだろうし、結局業界ごとのベストエフォートにしかならないのかな

[rasterson]

書いてあることは間違っているとは思わないが、最初シンプルだったルールが複雑になってきたら、ルールベースエンジンを導入して、今後のルール追加に備えるといったアプローチもあると思うよ。

[masaru_al]

『一時の感情に任せるな。必要なのはやる気ではない。啖呵を切る男気でもない。根気と、それをやりきる戦略です。あと、チームメンバーを敵に回してメリットはないです』

[coherent_sheaf]

"糞コードを直したいのであれば、そういったプロダクトに関する歴史的事実とも向き合わなければなりません"

[carolina04]

“「金を稼ぐ実績のある糞コード」 v.s. 「金を稼ぐか分からない実績のない綺麗なコード」だと短期の経済合理性は前者の方が高くなります。”

[Kazumi007]

クソコードでビジネスが成り立たなくなってからでも遅くない。今問題がないのなら、直すな。

[AmaiSaeta]

此れが通じるのは（筆者自身も書いてる通り）短期での話で、長期では害しか無いだろう。変更コストが上がり続け競合他社に周回差を付けられサ終。自社内の技術力は上がらず見込み有る者はサッサと転職。

[harupu]

いい話

[burabura117]

本できれいなコードやそのためのプラクティスを学んで最初に現場でやらかすのがこれだよね。えぇ、もちろん覚え、ありますとも。

[ohesotori]

なんかごめん

[tmatsuu]

インフラでもあるあるだ。わかる。でもわかると言ってしまう自分はもう若くないのかもしれない。

[mather314]

“基本的には、「ボーイスカウト・ルール」が良いと思います。”それはそうなんだけど、割れ窓理論で元が汚いと綺麗にする気力もなくなる悪循環もよく起こる印象がある。

[versatile]

クソコードを見て直さざるは恥だが役に立つ

[pero_0104]

ありがとう救われる　大量のクソコードに傷つけられてたわ

[yoshi-na]

クソコードを直すのはメリットよりデメリットの方がでかいってことかな？（読んでない）

[furudateko]

“今まで幾多の事故(と多大なる犠牲)を経て修正を重ねられている” “ビジネスを安定的に回すという面では実績がある” 糞コードであっても、そうなった理由と歴史がある。敬意を持つ。救われる記事、、

[umisora2]

“コード規約を押し付けたい側としても、「じゃあ、どういう風に新しい書き方で書くの？」というところに答えを持つことができず、受け入れざるを得ないパターンもあります。” それな。変革できない時に思い出そう

[bleu-bleut]

糞コードを直したいのであれば、そういったプロダクトに関する歴史的事実とも向き合わなければなりません。

[knok]

直せないまま業界ごと瓦解したガラケー…

[ikajigoku]

社会だ

[yaboot]

安全にリファクタリングできないのが糞コードなわけで、、、リスクを取れる立場の人とそうではない人で意見が分かれるよね

[fukken]

ビジネスロジックが恐ろしく複雑でも、知っている人がいるうちはいい。退職や移動で「知っているのはコードだけ」ということになりがち。

[twinkfrag]

かなり釣りタイトルなのはまあいいとしても、これ関連でよくある「動いてるコードが正義」とかいう言説は「動いてるクソコードは必要悪」の間違いだろう。

[metatrading]

元気かなぁ、sample()メソッド、Exampleクラス達。

[peketamin]

「君の気持ちはわかってるし、やりたいことは正しいと思うし、賛同する。だけど、それをやるのは恐らく今じゃない」って言われたことを思い出した。

[lyiase]

「クソコードは組織に依存するが、ビジネスには依存しない」が私の理解なので、ビジネスがクソコードを生むのは違和感がある。ただ触らぬ神に祟りなしは同意。リファクタしたくなったら仕様把握しておくだけにする。

[nakag0711]

直すのにコストとリスクがかかるのは当然のことで、直さない理由にならない。直すなというだけでは問題の先送りに過ぎぬ。こんなこと書いてる暇があったら早く少しずつでも直しなさい

[asayamakk]

主語が大きいし、やや抽象的だからそうだね、っていうのとそうじゃないときもあるよねとしか言えないかなあ

[ku__ra__ge]

下手するとバグAの問題がバグBでうまく打ち消されることで表面上は正しく動くという状態もあるので。

[yojik]

クソコードに単体テスト追加しリファクタリングして完璧！と思ってたら、クソコードのバグに依存して動作する他モジュールに気づかなくてアウトのパターンがあったな。(バグに気づかず無意識に正してしまった）

[aobon700]

リファクタリングの意味が分かっていない感じがする。あるいは、チームでそのような人がいたのかもしれない。糞コードを直すなは非常に誤解を生む表現だと思うので下げボタン押したいです。

[onetwodon]

勉強熱心な若手が、自分が勉強している本(良いソースコードの書き方系)と方針が違うという事で、ほぼ全ソースを書き直して、大量のバグを埋め込んでいったという地獄を知っている。