業務で使えるオープンソース（104）「リファクタリング」

他社向けのシステムでは相当に困難なリファクタリングですが（予算的にも）、せめて自社サービスであれば行っていきたいところです。ということでリファクタリングを勧める理由と関連オープンソース・ソフトウェアを紹介します。

メリット

技術的負債を清算する

レガシーなコードを放置していると、そこで使われているテクニックが古いものだったりセキュリティリスクを含むものだった場合に常に爆弾を抱えた状態になってしまいます。これはあまりに危険です。

また、運用を続ける中で場当たり的に追加したコードを見直したり、設定化することで見通しの良いコードになります。肥大化したコントローラのコードをモデルに移動して全体として最適化する事もできるでしょう。

テストのカバレッジ率があがる

リファクタリングを行う際にはテストは必須です。入出力の保証がなければコードを変更するのは怖くなるはずです。それでもスクリプト言語の場合、型の定義がないと怖くなるのですが…。

リファクタリングを機にAPIドキュメントを用意するのも良い手ではないでしょうか。

コードの品質があがる

そういったリファクタリングを行う事でムダなコードが減れば冗長的な部分が削られたり、使われていないメソッドを消す事ができるでしょう。その結果、コード全体の品質があがります。リファクタリングを行う上で必須なテストも書かれるのも品質向上につながるでしょう。

テストを書き始めると、テストしやすいコードを考えるようになります。その結果、複雑だったメソッドを分割してテストしやすい形にするようになるでしょう。

チーム全体のナレッジが向上する

当たり前ですがリファクタリングを行う上でソースコードリーディングは必須です。また、自分以外のメンバーが書いたコードにも積極的に手を入れる事になります。その結果、チーム全体でコードに対する理解が進み、ナレッジ共有が進みます。

個人的にはリファクタリングによる効果はここが大きいのではないかと思っています。コードが属人化するのを防ぎ、チームとして保証できる体制にできるようになるでしょう。

DBの最適化、正規化

最も難しいところですができれば行っておきたいでしょう。運用の中で雰囲気的に追加されたカラムはDBのパフォーマンスを悪化させます。カラムを追加するのではなく別テーブルに切り出しておくべきだった…なんてケースもざらです。

そこでテストを徹底的に書き、動作の保証ができる段階になったらデータベースも再度正規化してみてはいかがでしょう。