« 定例会から:月間MVP(2010/02月度) | トップページ | 勉強会:書籍ワーキンググループ »

定例会から:リファクタリング案件

定例会の機会を利用して、開発開始・終了報告を行ってます。
「こんなこと、しまーす」、「やりましたー」では意味が無い。
要は「共有する事に意義の有りそうなナレッジを公開する」ことが目的です。

また、多くの場合に、この機会・話題を触媒として、関連した経験やナレッジが参加者の中から出て来たりします。
絶対的な正解を求めるわけではなく(多分、そんなモノは大抵の場合に無いでしょうから)、その機会にナレッジを吐き出しあい、ディスカッションを行うことで経験に厚みを持たせることができます。
「実体験」を「間接経験」で補完・拡張するわけですね。

なので、「報告の為の報告」をしても意味が有りません。
お互いに無駄な時間・コストを食うだけですし、何よりも退屈です!

ある受託案件で、リファクタリングを目的としたプロジェクトが有りました。
わざわざ「リファクタリング」を依頼して来る(コストを掛けようとしている)わけですから、中身は言わずと知れますね。

メトリクス分析のツールでソースコードを計測したそうですが、とてつもない値がズラッと並んだそうです。
目視で解析しても凄い状態。
リファクタリングに伴う必須要素の1つとしてUnitテストを仕込み掛けていましたが、ごく一部に対処したのみで諦めざるを得ません(勿論、顧客に連絡し認識共有した上で、方針の変更をしたのですが)。

「処理を書き換える」のは無理と判断し、メソッドの移動、クラスの命名規則の統一、重複クラスの排除、DBアクセスの切り出し、引数の統一、などなど。
「これは拙いだろう」と考えられる要素で、処理コードに変更を加えずに済む範囲を極力キレイに掃除します。
分散して対処するとリスクが大きい部分は、ペアプロではなく、トリオプロをしたり。

それでも、気が付かずに処理が変わってしまう危険性もあるので、リリースの段階を幾つにも分割。
安全を期しました。

かくして、当初の目的であった「リファクタリング」を達成する事は出来なかったのですが、本質的な目的である「メンテナンス性を向上させる」という点では大分改善できたはず。
エンジニアとしては不完全燃焼ながらも、発注元のOKも戴けて、無事に終って良かったねーという終了報告でした。

ご支援、宜しくお願いします!ブログランキング!

にほんブログ村 ベンチャーブログへこちらも宜しく!

|

« 定例会から:月間MVP(2010/02月度) | トップページ | 勉強会:書籍ワーキンググループ »

定例会、勉強会など」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 定例会から:リファクタリング案件:

« 定例会から:月間MVP(2010/02月度) | トップページ | 勉強会:書籍ワーキンググループ »