  |
はてなキーワード: リファクタリングとは
forループからなる処理があり、データに対して、条件に合致する行にスコアを与え、スコア判定されたものは(id, score)というペアを出力し、それ以外のデータはリストにまとめて返す、という処理がある。
このパターンが6回ぐらい連続で続いていたが、条件合致部分が複雑で、処理が一致していることに気が付かなかった。
処理が一致していることに気がついて、abstractメソッドに実装(条件合致部分)を与えるという方式にして抽象化したらコードがスッキリした。
1. プログラムの夢 - Wataru's Dream of Code
2. ループの迷宮 - Labyrinth of Loops
3. 変数の秘密 - Secrets of the Variables
4. 条件分岐の試練 - Trials of the If-Else
5. デバッグの夜明け - Dawn of Debugging
6. サブルーチンの冒険 - Adventures in Subroutines
7. レガシーコードの呪い - Curse of the Legacy Code
8. リファクタリングの旅 - Journey of Refactoring
9. アルゴリズムの競演 - Symphony of Algorithms
10. クラウドの彼方に - Beyond the Clouds
実際のところ、リファクタリングは不可能ではない。ただ、やり方がある。
「この機能を修正して」「バグがあるから修正して」「新しい機能を追加して」と要求が挙がることがあるだろう。これがチャンスだ。
この要求に関係する部分（全体ではない）を、リファクタリングすればいいのである。
地道な作業になるが、「修正に伴うリファクタリング」を繰り返せば徐々に波及してくる。
ただし、最低限として、以下を満たす必要がある。
https://note.com/joan_of_arc/n/ned510ca913c7
これは業務が自分から見てクソだったので、良くするために提言したが全てないがしろにされ鬱になり退職しましたという話を延々している記事だ。
まず仕事においては営業的な意味で数値改善できる根拠が出せないのであればそれは改悪である。リファクタリングを幾らしても自分にとっていいコードになることはあれど、それ以上はない。何故なら書いた人物たちはそれが最善だと思って書いているからだ。
DDDだのデザインパターンだの、モジュール化だのポリフォーリズムだの素晴らしい設計技術が叫ばれて久しいが、一般人にそんなものは脳裏にないし、そんなのを勉強する暇があれば他にすることがある。プライベートで仕事に関することなんてするわけない。家で寝転がってポテチをぐーたら食べているのが現実。もし、そうでなければとっくにまともなコードになってる。
さて、仮にリファクタリングをしてもいいとされた時、業務外では家で寝転がってポテチをぐーたら食べている連中が書いたコードをどう直させるかだ。ほぼ不可能だろう。彼らには動くコードが正義で、自分の読みやすい密結合スパゲティぐちゃぐちゃコードこそ正義だ。そして彼らは金を産むコードを書いてきた先人でもある。要するに無理な話ということだ。君が社長でないのであれば諦めろということだよ。
https://comemo.nikkei.com/n/n84d2b6b03d3c
＞現職（SIer・SES）では、仕様などがトップダウンで指示されますよね（自分からは意見できませんよね）。弊社のこのポジションでは、トップダウンで指示が来るだけでなく、提案もできます。
とあるが、現実問題提案は難しい。小さい会社ならともかく、大手事業会社では膨大なステークホルダーがおり、それら全員にハンコリレーをして回るのは不可能に近い。何故なら最初に貰ったハンコが途中で失効するからだ。そもそも各部門とのコネクションを得るだけで膨大な労力と時間が掛かる。
また社内受託状態になっているとリファクタリングでさえ、発注内容に存在しない概念なので気軽に行うことはできない。仮にチャンスを得ても動き次第では実装した人間のメンツも潰してしまうので信頼を失うことさえあり、そういった文化がなければ容易ではない。
対してSESやSIerは余った時間は基本何をしてもいい。これは大抵の場合顧客や自分の契約が準委任などの形で時間清算になっているためだ。社内受託の場合は早く終われば追加の案件が振ってきて手を止める暇もないが、SIerはあらかじめ範囲が決まっているため、地面から突如湧いてくるケースは炎上案件を除き存在しないし、炎上案件でも火消しのための改善は経験上、受け入れられる。上流側の基本設計や要件定義がザルなら下流側から叩きなおし、顧客に直談判することすらやりようによっては可能だ。実装した人間はしょっちゅう入れ替わるのでメンツもクソもないし、仮に残っていても妙なプライドを持つ人間は多くない。
事業会社では自社で抱えている社員を限界まで使い倒すのが狙いなのもあり、これが難しい。外注を入れると高くつくのでギリギリの人数で仕事を回していると余白がないのだ。逆に入っている側の人間は明確な義務がないので自由に動ける（SES会社との関係悪化が起きるとよくないので使い潰すような動きはしない）
転職活動中に複数社から意見を聞いたが、外部向けにアピールしているボトムダウンやら改善の活動は人を集めるための方便・綺麗ごと、常識的に考えれば事業成長が優先でやる暇などないよ、と言われたので恐らくどこもそうなのだろう。
いやぁ〜、テキストエディタの世界、めっちゃディープでんねん！聞いてくださいよ〜。
まず、テキストエディタの心臓部、バッファ管理システムについてや。これ、単なるテキスト保持やないんですわ。例えば、Emacsのガベージコレクション機構。マーク＆スイープ方式採用してて、バッファ内のLispオブジェクトを効率的に管理してんねん。これがあるから、長時間の編集作業でもメモリリークせーへんのや。
次に、レンダリングエンジン。これが曲者でんねん。Unicode標準のUAX #9に準拠した双方向アルゴリズム実装せなアカン。さらに、合字処理のためにOpenTypeのGSUB/GPOSテーブル解析も必要や。Harfbuzzライブラリ使うんやけど、カスタムシェーピングエンジン組み込んで、特殊な文字体系にも対応せなアカンのや。
構文解析エンジンも侮れまへんで。LR(1)パーサーじゃ複雑な言語構文に対応でけへんから、GLR（Generalized LR）パーサー実装するんや。これで曖昧な文法も扱えるようになるんですわ。Treesitterライブラリ使うと、インクリメンタルな構文解析ができて、巨大ファイルでもリアルタイムにハイライティングできるんや。
差分アルゴリズムも奥が深いんですわ。Myers差分アルゴリズムだけやなくて、Histogram差分アルゴリズムも実装せなアカン。大規模リファクタリングの差分表示に効くねん。さらに、セマンティック差分アルゴリズムも組み込んで、構造的な変更も検出できるようにするんや。
非同期処理システムもめっちゃ重要や。単なるPromiseやasync/awaitやのうて、Reactive Extensionsベースのストリーム処理実装するんや。これで、複雑なイベントシーケンスも扱えるようになるんですわ。さらに、アクターモデルベースの並行処理システム組み込んで、マルチコア活用した並列処理も可能にするんや。
最新トレンドもめっちゃアツいんですわ。例えば、Language Server Protocolの拡張や。単なる静的解析やのうて、シンボリックAI使うた意味解析まで可能にしてるんや。これで、コードの意図を理解して、より高度なリファクタリング提案ができるようになるんですわ。
WebAssembly統合も進化してるんや。Single Instruction, Multiple Data (SIMD)命令セットサポートで、テキスト処理のパフォーマンスが爆上がりしてんねん。さらに、WebAssembly System Interface (WASI)採用で、ファイルシステムアクセスも可能になってるんや。
AI支援機能も侮れまへんで。単なる補完やのうて、プログラム合成（Program Synthesis）技術導入してるんや。部分的な仕様から完全なコードを生成できるようになってんねん。さらに、説明生成AI組み込んで、生成されたコードの詳細な解説までしてくれるんですわ。
リアルタイムコラボレーションも進化してるんや。Conflict-free Replicated Data Type (CRDT)のカスタム実装で、ネットワーク遅延があっても一貫性保てるようになってんねん。さらに、意図ベースの競合解決アルゴリズム導入して、複雑な編集操作の衝突も自動解決できるようになってるんや。
拡張性アーキテクチャもすごいんですわ。WebAssemblyベースのプラグインシステム採用して、言語に依存せんプラグイン開発可能になってんねん。さらに、サンドボックス化されたランタイム環境提供して、セキュアなプラグイン実行も実現してるんや。
性能評価も厳しくなってるんですわ。起動時間は、コールドスタートだけやのうて、ホットスタートも測定せなアカン。メモリ使用量も、物理メモリだけやなくて、仮想メモリの使用状況も追跡するんや。CPU使用率は、マイクロアーキテクチャレベルの最適化まで求められるようになってんねん。レンダリング性能は、GPUアクセラレーションの効率も評価せなアカンのや。応答性は、入力レイテンシだけやのうて、知覚的な応答性（Perceived Responsiveness）も測定するんですわ。
いや〜、テキストエディタの世界、マジでディープすぎて、もう頭おかしなるで〜！こんな感じで、テキストエディタの最深部まで潜ってみましたけど、いかがでしたか？テキストエディタ、侮れまへんで〜。ホンマに。
端的に言えば、「やり方が変わったらミスが増えるし覚えるまでの仕事が遅くなるから」以外にないですよ。
新しいやり方になって大幅スピードアップならともかく、仕事のスピード自体はおおむね一緒だけどやり方だけは変わるってパターンの場合は現場の負担が半端ない。
現場が死ぬ気でやれば解決するわけでもなく、人員を一時的に増やした所で初心者ばかり集めては結局ミスが増える。
「リファクタリングの方が安く仕上がりると勘違いしてるから目指してるんだろうな」と思ってる人、ただのバカです。
発注側も一次請けも現場もみんな「いっそ根本から作り直したほうがシステム屋さん的には楽なんだろう」ってことは分かってる。
でも作り直してしまった場合に生じる現場の混乱とリファクタリングのコストを天秤にかけて現場のやり方を変えないことを選んでるわけ。
そこが分かってないで「まーたアホな仕様でシステム更新しようとしたんでしょー。学習しないね―」みたいなこと言ってるのいい加減見飽きたよ。
去年から稼働している現場で、以前からあったReact Nativeの面倒を見ているんだがまあこれがひどい出来なんだ。
jQuery時代に見かけたようなコードをやたら見かけたので思わず懐かしくなってしまった。
リファクタリングしようとしたけど直す範囲が広すぎてアプリを壊しかねなかったので、早々に諦めてだましだまし保守をしていた。
そんな中今年に入ってアプリのリニューアルの話が出てきた。React Native捨ててSwift/KotlinやらFlutterに書き換えるとかそういうのではなく、デザインの刷新といくつかの機能改修。
このままだとアプリが更に魔窟化するので、マネージャーに色々相談したところいくつかの事実がわかった。
ということだった。
結局現状のまま進めるわけにはいかず、要件定義の傍らリファクタリング作業をしている。
そういう経緯もあったので、リファクタリングとテストの工数も積んだ上で見積もりだしてもらってる。
「レガシーアーキテクチャをモダンアーキテクチャに刷新」なんてよく聞く話しだけど、
実態は「長年の増改築とだましだましのリフォームが限界になってきたので新築で建て替えます」何だと思う。
最近は「Vue.jsからRemixにマイグレーション」なんて見かけるけど、悪いのはVue.jsじゃなくて禄に設計しないでコード書いてるエンジニアと、
リファクタリングには予算でないけどマイグレーションなら予算取れるという悪しき風習。
年がら年中フロントエンド刷新しているような会社は地雷なので行かないほうがいい。
いくらRemixやらNext.jsやら最新鋭のフレームワーク使ってても、クソコードで書いたらクソが出来上がるだけだ。
