エンジニアの嘘が多くて経営者に不信感があるからです。理由をつけてリファクタリングとかでリリースを遅らされるけど品質は大して高くない。次の別なエンジニアがまた同じことを言ってリファクタリングとかをはじめる。そんな地獄のループに悩まされた経験があるからです https://t.co/qkYUYMtUCO
— やまもんチャリ走社長／ITエンジニア専用焼肉奢りおじ (@MotoyasuYamada) June 27, 2023
多くの場合、必要なリファクタリングはビジネスロジックが変更されるなどして、根本的に仕様の見直しを行い、影響範囲を洗い出した上で他メンバーの開発と衝突しないようにコミュニケーションを取りながらやる。（リファクタリングじゃなくて改修では？それはそう）
大変とかいうレベルじゃないものになるので、参入した新規エンジニアがちょちょいでリファクタリングできるようなものは、体の良い自分の読みやすいコードへの変換でしかない。みたいなところがある気がします
例えばショートハンドへの変換とか。型付け言語だとanyになっているところをちゃんと型定義するとか
後者に関してはきれいに付いてると可読性高いし好きだけど、とはいえ入ってきていきなりその辺全部キレイにしたいとかいうタイプの人、我がクソ強そうなので色々大変そうだなぁという気はする。我が実装に合わせよ愚民ども。みたいに見える。
やるとしても自分が着手する範囲をとりあえずやれば良いのではという気持ちがある
経営者目線だと工数を確保するだけの理由がないと、お客さんがいるタイプの開発とかだったりすると客先にそれどうやって説明すんねんとかいう話にもなってきそうなので、リファクタリングは諦めようという気持ちになる
結局一番必要なところはもうどうしようもない感じになってるし、大体
リファクタリングは基本的に小さなステップを重ねていくわけですが、構造を改善するために大きなステップを超えざるを得なくなることがあります。
— なぎせ ゆうき (@nagise) June 27, 2023
このステップがある程度大きくなると、リファクタリングの困難性が急激に上昇し、現実的にリファクタリング不可能になります。
このあたりに地平線がある
本当にこれ。
入社以来、ブルドーザーのようにリファクタリングを進めております。じゃっかんdiffの量に引かれましたが、PRはチーム全員いれたモブレビュー形式でやったら意外にサクッと終わったし個人の負担も少なくてよかった。味を占めたのでガンガン入れ替えていくぞ pic.twitter.com/bIeWokUsDx
— トミール (@tomita) June 23, 2023
こういう人間卒業してそうな人だったらいけるのかもしれない
ただ流石に内製のシステムだろうという気はする。入社が4月だと考えると2ヶ月近くやってるとかなのだろうか
どちらの言い分も正しい場合も考えられて、既にコードが完全に腐ってる時には新規参入者がフレッシュさに任せてリファクタリングを要求して実施しようとするが、スパゲティを解こうするも力尽きるが続くことに。
— po (@podhmo) June 27, 2023
傍から見ると嘘に見えるが地獄が既に顕現してるときだと両者が正しい事を言っていそう https://t.co/fdQIdkC3zS
これもある
今自分が触っているコードがまさにこれ
一つのクラスに2種類のタイプを兼用するような形で作成した結果、それぞれのタイプが独自進化を続けていき、枝葉の部分が常にそのタイプを意識して条件分岐を細かく指定していかなければならず、とにかくネストが深い
更にいうと初期化処理のときにそれぞれのタイプが進化を遂げることを考慮していない形で作られていたので、後続の人間がそこを改修せずに進化を吸収するような実装で対応した結果、なんかもうあちらこちらで状態変化がおこっていてヘルプミーという感じ。
ずっと見てたのでどこで何起きてるか流石に覚えたからなんとかならんこともないけど、初見の絶望感は酷いし、そういうときはやっぱりリファクタリングしたくなる
でもいざやったら密結合の嵐だし、新規実装とは衝突するしで100%挫折すると思ってるので共存するか逃げるかしかエンジニア個人には選択肢がないのではと思ったりした。化け物ならできるかもしれないけど、個の力だけでは無理な部分はあるので組織を説得する何らかの力も必要なのではと思う
