Prolog なんてなかった。

Lifactoring のススメ

　普段の私の仕事では、全くゼロからソースコードを書くということがほとんどありません。大抵はバグの修正であったり、既存のコードベースにちょっとした新機能を追加したりという作業が主となります。その際には、自分以外の様々なプログラマが書き、保守してきたコードを読むこととなります。

　長年運用されてきたソースコードは、まぁ、大抵の場合はひどいものです。廃れてしまった当時のベストプラクティス、まさかこんなに長期間残ると思わなかった暫定ソリューション、仕様変更に次ぐ変更で複雑にネストしてしまった制御構造など、コードの臭いがいたる所に立ち込めています。

　優秀で勇敢な若手エンジニアたちはリファクタリングという名の「全面的な作り直し」に走りがちですが、長年運用されたコードを作り直すのはとても勇気と根気がいる作業です。ユニットテストに包んで改良していければ良いですが、大抵の場合この手のコードはテストがほとんどないか、全くないか、全くない上に複雑すぎてもはやテストの書けない代物とかしています。

　きちんとしたリファクタリングの難易度が高い時に提案したいことこそ、「マージ担当者が一目で安全と分かるほど Light な Refactoring」=「Lifactoring」です。

　制御構造の全面的な変更は、テストなしではとても怖くてマージできません。しかし、例えば下記のようなコミット一つづつならマージする時の不安感が幾分か減らせるはずです。

• ただインデントが揃えられただけのコミット
• ただコメントが付与されただけのコミット
• 複雑な条件式がひとつだけ、ただメソッドに切り出されただけのコミット（そして条件式部分がユニットテストに組み込まれる）
• ひとつのネストした if ブロックが、ひとつ上の else if に移動することでネストがひとつだけ解消されたコミット

　この手の非常に小さな改良は、ひとつづつならほとんど意味のない改良ですが、例えば毎日ひとつづつでもリリースすれば１年後にはとても綺麗なコードに生まれ変わります。幾分かマシになれば、いわゆる「全面的なリファクタリング」にもチャレンジしやすくなるのではないでしょうか？

　リファクタリングやボーイスカウトルールはとても良いものですが、「秘伝のタレ」のようなソースコードの場合は一筋縄では行きません。それでも、ほんのすこしずつ lifactoring を繰り返していけば、タレの秘伝をとかほぐしていけるのではないでしょうか。ぜひすこしずつの改良を試してみてください。