リファクタリングしたい病
何でユニットテストとかバージョン管理に惹かれていたかがちょっと分かった気がします。「リファクタリングしたい病」にかかっていて、この病気をどうにかするために無意識のうちに上記を用いようとしていたみたいです。
（自分もまだまだ経験不足で全然ダメダメだとは分かっていますが）今のプロジェクトの開発者のレベルは正直いまいち。ちょこちょこネタにはしていますが、1000行のサブルーチン*1があったり、全てグローバルデータ*2でやりとりしていたり、他にも例をあげれば○▲□×…（以下略）。ま、どれだけひどいかをあげるのが本題ではないので、この辺でｗ
で、あまりよろしくないコードにひきづられて、自分がメンテナンスする部分までよろしくなくなるのが何というかひじょーにプライドが許せないわけで。どうにかしてきれいな形にした上で手を入れていきたい、つまり、リファクタリングをしたいってのが根本にあったわけです。
ただ、単純にリファクタリングをしたいとは言っても、そんな文化でもないのでなかなか難しい。ぱっと考えたところ、リファクタリングに対するPMなどの懸念事項は以下の三つ。
1点目は、よく言われることですよね。まぁ、これはリファクタリングした場合としなかった場合とを定量化して比較すれば説明はできるかと。それで、納得してくれるかは別問題ですが…
2点目も、よく分かります。で、この問題を回避するために、ユニットテスト（＆テスト自動化）をいろいろ検証してたのですよね。自動化されたユニットテストがあれば、デグレードの危険を限りなく小さくすることができます。全てのテストシナリオを完全に自動化させることはコスト的に合わない部分があるのかもしれないですが、それでも大部分は自動化でき、さらにはデグレードを回避することが可能となると考えています。
3点目は、（コードをきれいにするという）リファクタリングの概念と矛盾しているように聞こえるので、少し説明がいりますね。現プロジェクトでは、ソースコードを修正する際は、コードのヘッダに修正内容を記述すると同時に変更箇所をコメントで分かるようにしておくという規約があります。この規約では、例えば↓のようになります。
*--------------------------------------* * 乗算プログラム *--------------------------------------* * 履歴 * 1. [ユーザ名] 2倍ではなく3倍へ修正 *--------------------------------------* 〜〜〜 * START Modify [ユーザ名] * wa_return = wa_input * 2. wa_return = wa_input * 3. * END Modify [ユーザ名]
ヘッダ部分に修正内容を入れるのは全然異論はないのですが、問題はコード中のコメント。これぐらい単純だったらまだましなのですが、これが二重・三重に修正が入ると見にくいことこの上ない。実際はどれが正しいロジックかを追うだけでも日が暮れます。こういうのって、まさにバージョン管理の出番ですよね？
上記の3点の懸念事項ですが、1点目は私だけでなく他メンバーも実感していることからそこまで説明は難しくなさそうです。2点目については、ユニットテストの概念論だけでなく具体的なやり方まで固めることができつつあります。あとは、まず個人で試してみて細かい点を修正しつつ、導入に際してのドキュメントを作成すればいいかな。
問題は、3点目なのですよね。適切なバージョン管理を導入すれば解決しそうとは思うのですが、その適切なバージョン管理が思い当たらない。id:Kirika氏とも話したのですが、一般的なシステムとは違って現プロジェクトでのシステムアーキテクチャ*3って結構違うんですよね。その違いをうまく吸収できるようなバージョン管理＆運用が思い浮かばない…orz
この辺はもうちょっと検討する余地がありそうです。
ただ、ソース中にコメントで履歴を残す手法がよろしくないのは、↓にあげている通り。一応、新しい順に並べています。
- どーも釈然としない
- コメントアウトがナンセンスである理由
- だからソース自身に履歴を残すなと S.S.S. blog/ウェブリブログ
- プログラムの修正履歴 - きままな日記帳
- アクセスが禁止されています：@nifty
古いものは2004年4月。多分オープンに出ていないだけで、もっと多数の人が思っていることでしょう。これは本当にどげんかせんといかん…ｗ
