リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog

どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私

[ledsun]

「誰も仕様を知らない」ことがわかることが大事。どうすればいいかわからなくて困惑する。だからこそ「誰も仕様を知らない」を共通認識にすることが大事。そこから別の判断基準を探していく作業が大事。

[Sephy]

リファクタリングは一度に全部きれいにしようとすると芋蔓で大体死ぬ。その時に修正対象になった部分の可読性を良好にするとか日々の積み重ねが重要。本来の修正対象のテストだけで済むから連鎖して死ぬ事は少ない

[rryu]

生き残っているクソコードは修正を拒む強さを思っているので、コーディングルールの適用程度の指針では太刀打ちできないのだ。

[deep_one]

「現行仕様が明確になっておらず、それを明確化するところに立ち戻る必要があること」誰も現行仕様を知らないのに「現行通りに動くこと」って言われる奴。まず「現行通りに動く」を捨てるのが重要。

[progrhyme]

「糞コードは直すな」しかし、直して得られたものもあった

[mak_in]

リファクタリングはテストが大事。テストで動作が担保できる、テストがすぐに動く、が担保できないと、ソースコードも担保できなくなってつらい。実ソースよりも先に、そこを手をいれるかな。

[nakamura-kenichi]

こういうのは予算と期間がたっぷり付かん限りは、修正時に最小限でサクッとやるんやで。何回かイテレーション回ったら結構すっきりしてるやで。

[napsucks]

よくそんな目に見えてる地雷に突っ込んでいったもんだ、タフだなあ。カネと時間かけてリファクタリングに成功しても元と同じ機能を持つものができるだけと思うと手を出そうとは思わない。大半の人がそう思うだろう。

[toaruR]

仕様の整えるべき箇所が分かってよかったとも（´－｀）

[atsushieno]

仕様が明確でないかどうかもリファクタリングみたいなかたちでコードを掘り下げてみないとわからんことあるよね（テスト追加でもいいんだけど仕事だと工数出るのかっていう問題がある）

[takatama]

お金を稼いでいる技術的負債に敬意を持ちつつ、クソコードは撲滅

[gothedistance]

安易な作り直しに倒すな、と

[osiire]

リファクタリングの範疇を越えた仕様明確化や言語/ライブラリの変更まで、この若さでやってのけたのは称賛に値する。機能は変わらないかもしれないが、今後の不具合の減少と新機能の追加容易性で確実に貢献してる。

[quick_past]

最初の設計がおかしくてうんうんになってるのと、そもそも実装力が低すぎてうんうんになってるのでは、事情が違ってきそう

[fukken]

「影響範囲の広い大事な部分」ほど、下手に書き換えると壊れるという認識からリファクタリングされず、しかし影響範囲が広いが故に日常的にジェンガのように修正され、結果保守不可能なクソコードになりがち。

[Magicant]

若い内にかういふ体験ができる人は素質あるよね

[akiramaz]

目を背けている技術的負債がある

[cl-gaku]

言い訳のために一部だけ残して新築そっくりさんになることもしばしば

[masa8aurum]

・まず現行仕様を明確にしよう /「汚いソースコード」の例が書かれていて、それも参考になる

[nilab]

リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog

[kikuchi1201]

素晴らしいなぁ。堅実的で応援したくなる

[cuttoff19]

とても良い話

[nakag0711]

レベル低い現場だと足引っ張る人多いからね。著名OSSの開発なんかを見てるとよくある現場と比較して開発者の態度の違いがハッキリわかる

[hitotakuchan]

冪等性を理解してなさそう＞関数には必ず冪等性を持たせること

[aceraceae]

リファクタリングみたいなこと主たる業務の裏であまりスケジュールを考えずにすすめたほうがいいと思うんだけどな。

[atsushifx]

失敗談大事。しかし、リファクタリング以前のレガシーコードの話よね

[nishi1231chang]

エンジニアが、経験浅いうちにこうやってやたら一気に書き直したがる心理に名前つけたいな。意識高い系みたいな一気に背伸びしたがるような感じ。実務でも、ボーイスカウトルールでコツコツするのが結局大事よ

[to4iki]

周辺を触る機会に整頓するなど地道に借金返済するしかない

[diveintounlimit]

つらい

[shingo-sasaki-0529]

すごい。こんなんリアーキテクチャではと思ってしまった。リファクタリングは小さくコツコツ本業の片手間ぐらいが好き。

[gabari]

良い記事。Joelの「あなたが絶対すべきでないことPart 1」を思い出させる。

[ijustiH]

表現のゆらぎがあったり、理想像がふわっとしていたり、わりと読みづらくて文章が好きじゃない。学びはそのとおりと思うけど。

[JGEEM]

良記事。つまるところ要求はなに？仕様はどうあるべき？という人間系の話に収束するよね、ということに早々に気づけたことの価値は高い

[joker1007]

どっちかというと意思決定の留保があったことを忘れてるのが悪い積み重ねを生むと思っている。しかもそういう明確に仕様化されていない異常挙動をただ正常にするとそこに立脚して適応した人間から怒られる……。

[baronhorse]

こういうものの担当を振られた以上是非もない。やらなければチームが潰れてしまうだろ

[temtan]

ちゃんとした仕様が無いからどうあるべきが判らず色んな人が手を加えたから総合的に把握してる人物もいないシステムの保守は大変という話で「リファクタリング」とはまた違う話じゃねーかなあ。

[sugawara1991]

再実装や再設計はリファクタリングと呼ぶ改善活動の範疇の外に置く方が良いと思う。コードが表現するものに極力影響を与えず可読性や保守性の改善を目的に一歩ずつ書き換え可能なものだけそう呼ぶ方が良い