ステップ6：リファクタリング完了後にやるべきこと
お疲れ様でした！ 単体テストを実装し、テストが問題なく通るようになればリファクタリングとしては十分と言えるでしょう。Git環境であれば、コードをコミットし、プルリクを出してよい段階だと思います。ここまでしっかりリファクタリングしていれば、鬼の先輩による激詰めコードレビューも恐れるに足らずです！ もし、今回のリファクタリングに関して、他にやるべきことがあるとすれば、以下のようなことが挙げられます。ぜひこれらも検討してみてください。
ドキュメントの整備
チームメンバーのために、作成した新関数のドキュメントを作成します。
テストの完全性のチェック
ユニットテストがすべての重要なケースをカバーしているか確認してください。また、テストが失敗した際のメッセージが役立つものになっているか確認してください。
エラーハンドリング
関数のエラーハンドリングが適切に行われているか確認してください。ユーザー入力やファイル操作などの外部からのデータ処理において、適切なバリデーションが行われているか確認してください。
ステップ0：そもそも論
最近のアニメやドラマでは、話がある程度進んだところで前日談として「エピソード0」がリリースされることが多いので、ちょっとあやかってみました。そもそもリファクタリングをやるべきか否か？ という話です。
冒頭のリファクタリング（Refactoring）の定義の話を思い出してください。なぜ“Re”factoringなのか。この用語の存在自体が「最初からきれいなコードを書くのは難しい」という開発現場の実情を表していると思います。納期の制約もあるし、ビジネスチームから降って来る仕様はコロコロ変わるし。最初からきれいなコードを書こうとしても上手くいくもんじゃありません。上手くいかなくても全くダメじゃない、むしろそれが普通。人間だもの…… だからこそリファクタリングが大切で、定期的にやるべきだと私は思います（リアルワールドの「掃除」と同じですね）。いつリファクタリングをするかの判断には第2回で紹介したコード品質の測定が役立つでしょう。
しかしながら、リファクタリングの過程でバグを入れてしまって、コード品質を上げるつもりがかえって下げてしまうこともあります。「動いているコードはいじるな」という格言もあります。修正することによる危険性と、それによって得られる価値(コード品質の向上)とを秤にかけて、「リファクタリングをあえてしない」という選択をするプロジェクトもあります。それらは理解できるのですが、そのようなプロジェクトであっても何もしないでコード品質がどんどん下がっていくのはまずい…なんとかしたい……そういったニーズに答えようとする技術開発も進んでいます（先のアナロジーで言えば、散らかった部屋でもAppleのAirTagを使えば、少なくとも大事なものはなくならない、といったところでしょうか）。
実は筆者らもそのような製品の開発を行っていますし、例えばGitHubも、「Copilot Chat」として人間に変わってコードを分析して問題の特定とともに、修正提案、問題の説明、代替アプローチを提供してくれる機能をリリースしています。我々も色々と試していますが、AIを利用したソフトウェア開発は、コードをゼロから自動生成するよりも人間が書いたコードをなんらかの形で管理・改善してもらうような使い方の方が、少なくとも現時点では役に立つのではないかと考えています。
まとめ
以上、リファクタリングの概要と、簡単ではありますが実例コードを使ってのリファクタリングの一例をみていただきました。リファクタリングには他にも様々なパターンが存在します。それらのパターンについては、『リファクタリング 第2版』というタイトルがそのままズバリのMartin Fowlerの名著にまとめられています。この本の定義によれば、前章で行ったリファクタリングは、「関数の抽出」パターンになります。本書では他に20種類以上のリファクタリング・パターンについて解説されています。ぜひ参考にしてみてください。
本記事では「どうやってコード品質を上げるのか？」と題して、コード品質を上げる手法の一つであるリファクタリングを紹介し、実際のやり方を説明しました。今回の第3回で、一旦本連載は終了なのですが、他にもコード品質にまつわるトピックスは数多くあります。コーディング規約、コードレビュー、パフォーマンス最適化、セキュリティ、継続的インテグレーションと継続的デリバリー （CI/CD）、などなど。もし皆様からのご要望があれば、ぜひこれらのトピックスに関しても書いていきたいと思います。
では、また会う日まで。Happy Hacking!
