はじめに
近年の AI の発展により、ソースコードの生成を AI に任せる時代が到来しています。ただし、最終的には人間の目による確認が必要です（耳にタコができるほど聞いたかもしれませんが）。
また、AI にすべてのドメイン知識を理解させるのは難しく、完璧なソースコードを生成するのは現実的ではありません。
そのため、今も昔もリファクタリングは不可欠です。本記事では、リファクタリングについての個人的な考えをまとめてみました。
リファクタリングとは？
リファクタリングとは、プログラムの動作を変えずに、ソースコードの内部構造を改善する作業を指します。
主に以下のような目的で行われます：
- 可読性の向上
- 保守性の向上
- 開発効率・品質の向上
リファクタリングのタイミングは？
結論から言うと、ソースに触れるときがリファクタリングのタイミングです。
以下に、参考文献から得た知見を抜粋して紹介します。
📘 『レガシーコードからの脱却』
いつリファクタリングを行うかについての７つの戦略
- 重要なコードがうまく保守されていない時
- コードを理解している人がいなくなった時
- 新しい情報によって、より良い設計が見つかったとき
- バグを修正する時
- 新機能を追加するとき
- レガシーコードのドキュメントを書くとき
- 作り直すより安い時
📘 『達人プログラマー』
１年前よりも、あるいは昨日よりも、さらには１０分前よりも良い考えが浮かんだ時、つまり何かを学んだ時がリファクタリングの時です。
コードがうまく馴染んでいないと感じたり、まとめるべき２つの事柄を見つけたりといった何か「おかしなもの」に遭遇した場合、手を入れることを躊躇してはいけません。今がその時なのです。コードをリファクタリングする際のきっかけとして、以下のようなものが考えられます。
- 二重化
- 直行していない設計
- 時代遅れの知識
- 使用方法
- パフォーマンス
- テストの合格
📘 『リファクタリング第2版 - 既存のコードを安全に改善する』
【三度目の法則】
Don Roberts が教えてくれてたガイドラインがあります。最初は、単純に作業を行います。二度目に以前と似たようなことをしていると気づいた場合には、重複を意識しつつも、とにかく作業を続けて構いません。そして三度目に同じようなことをしていると気づいたならば、そこでリファクタリングをするのです。
野球に例えるなら、３ストライクでリファクタリング開始です。
他にも読んだ参考書の中で、いい内容はあったと思いますが、今回は上記だけを取り上げさせていただきました。
色々読んでみても、やはり思うこととしてはソースに触れる時こそがリファクタリングの時だと思っています。
リファクタリングの阻害要因
⏰ 時間と労力の制約
価値提供を急ぐあまり、リファクタリングは後回しにされがちです。
開発メンバーとしても、お客様に早く価値を提供したいという気持ちは当たり前のことですが、リファクタリングを後回し＝永遠にやらないことも多いです。
🔁 「既存がそうだから」と手を加えない
チーム開発では、一貫性を担保することは大切です。
でも、違和感のあるもの、こうした方が絶対いいものを落とし込めるのに他はそうだからと言う理由でリファクタリングしないのは非常に勿体無いと思います。
ただ、そうなると一貫性が欠落するため、そうなる際にチームを巻き込んで既存と既存との変更内容の違いを共有するなどの、チーム内での合意形成や共有が重要です。
🧪 テストがない
そもそもテストの基盤構築ができてないもよくあることだとお思いますし、追加する機能のテストファイルがないもあると思います。
そうなるとテスト基盤構築を前段に置くなどの作業工数がプラスで発生します。
その中でプログラムの動作を変えずに、ソースコードの内部構造を改善するはなかなか勇気がいることだと思います。
🎯 影響範囲の不確実性
一見問題ない変更が、別の箇所で不具合（デグレ）を起こす可能性があります。
安易な気持ちで修正した箇所にて、問題ないとなったとしても、実は他の箇所に影響が出ていて、デグレにつながる可能性は大いにあります。
リファクタリング実践法
どのようにしているのかの個人的な動きについて、簡単に共有します。
💪 勇気を出す
動作を変えずに、内部構造を変更するため、既存ソースに触れるはなかなか怖いことですが、だとしても既存ソースをぶっ壊す気持ちを持ち続けることは大切だと思います。
テストがない場合に関しては、テスト作成も工数に入れる。入れられない時は第三者も巻き込んで動作確認を徹底的に行うです。
勇気を出したからには心理的安心も確保できるようにしなければなりません。
安心の裏付けが「勇気」には必要です。
💸 技術的負債は常に生まれるものと認識する
リファクタリングを実施したソースコードも負債だと思っています。
要は、最善を尽くしても、いずれそれは負債になります。
自分やベテランエンジニアが作成したから完璧だと思い込まずに、どんな人間でも負債を作るものと思い込むことが重要ではないかなと思っています。
どのようなのコードも、未来から見れば“過去の負債”になりうるという認識が大切です。
👀 ソースを徹底的に読む
修正箇所だけのソースだけにとどまらず、その周辺の構造、設計、処理の流れを理解することが重要です。
そうすると、「あれ？何この実装？」って箇所は絶対見つかります。
ただ、特殊な実装やパワーコードにも何かしらの理由があってそのように作られています。
そういった時、「何これ？www やばwww」と思ってスルーするのではなく、目の前にあるソースと徹底的に向き合うようにします。（「何これ？www やばwww」って思う人も、「何これ？www やばwww」のソースを作っています）
しっかり理解や把握をしていくと、このロジックはここにあった方が可読性上がるなや、保守性が高まるな、この前学んだテクニック使えそうなどができると思っています。
おわりに
ある程度の開発経験を積んだからこそ感じる、リファクタリングの大切さをまとめてみました。
これから開発を始める方や、数年経験を積んだエンジニアの方にも、少しでも参考になれば嬉しいです。