レトロコードの不吉な匂い - あるプログラマの日記

最近の仕事は、過去に java で開発したシステムのバージョンアップを行っていますが
java のバージョンは過去のままで行っています。（レトロ）

10年くらい前に開発していたシステムですが、今見直すとリファクタリングした方が良いと思うコードがところどころあります。コードの「不吉な匂い」が...

数年前の自分は、もはや他人。
過去に自分が書いたコードも、現時点で見直すと「何か変」ということもあったりします。

コードが属人化してしまっているのを見ると他のプログラマーからの介入を防ぐためか、リファクタリングを避けて障壁を築いているのかと思ってしまうことがある...
（勘繰りが過ぎると！）

属人化は、長期的にみてプロジェクトチームや企業の損失なります。
他の人で対応できないため特定の個人だけで対応することになり
内部の問題が顕在化しないため、導入後に問題が発生したりするなど様々な弊害がでます。

改めて「リファクタリング」というのは
外部的な振る舞いを保ちつつ、内部構造を改善すること。
外部の動作や機能は変化しないままで、

内部コードの設計や構造を変更して改善すること。

「内部構造を改善すること」とは、

すぐ理解できるような構造にすること。

コードを見てその目的がわかるようにすること。

人が理解しづらいコードは、コードを見てもその目的がわからないため
コードが読みにくく変更や追加を行うのに時間がかかり、
かつバグを作りこんでしまうリスクも高くなります。

プログラムは完成した後も頻繁に仕様が変更されたり

機能が追加されたりするものです。
将来の仕様変更に備えてコードの修正箇所を正確に速く見つけてることができ

るようにしておくと作業効率が良くなり、バグが入り込む余地も少なくなります。

なので、常に、変更・追加がしやすいように理解しやすく見通しがよいコードに
保っておく必要があります。
オブジェクト指向プログラミングの利点を活かせるようにしておくことが重要です。
ポイントは
　・可読性
　・再利用性
　・柔軟性

リファクタリングの目的
　・設計の向上
　・設計の劣化防止
　・理解しやすいコードを保つ
　・バグの特定
　・プログラミングの迅速化

リファクタリングを始める前に、対象コードに対するテストコードを

書くことが必須です。

人の手が入るとどうしてもバグが入り込む余地がでてくるので
小さなステップでリファクタリングを繰り返して、その都度、自動テスト(JUnitなど）を行うようにするのが安全です。

　・過去に作成したときに良いと思えた設計が現時点で

　　見直すとミスマッチであると認識できた時点でリファクタリングを行う。

　・重複コードを発見した時
　　コードの重複部部をなくす。メソッド化する。
　　それによって結果的にコード量を減らすことができます。

　・コードを理解するときにリファクタリングを行う。