担当者に代わって機能追加を行うのが本来の目的だったはずなのに、
該当箇所の周辺の実装をフムフムなるほどと確認しているうちに
自分だったらこう書くな、と思う箇所があると、
直接関係ない箇所まで自分色に染め始めてしまうのが
プログラマーとしての私の性質の一つである。

こういう時にいつも悩むのは、どこまでやるべきか、ということである。

レベル
気になる程度
気になるポイント
アクション
そのときの気持ち
1
何となく気持ち悪い ・インデント
・括弧
・改行
・コメント
・中途半端な import 文 *1
作業している箇所の周辺を少しずつ自分色に染めていく。 こんなことしてていいんだろうか。
2
できれば修正したい ・重複したコード
・過剰なコメント
・一般的でない命名
・大きすぎるクラスやメソッド
・読んで即座に意味がわからないコード
・不要になったのに残されているコード *2
耐えられない箇所は見つけ次第自分色に染める。そこまででもないものは時間と相談して考える。 これをやっておけば後の作業はずいぶん楽になる(はず)。
3
ぜんぶ書き直したい ・明らかにコピペしたコード
・数多く見つかる潜在的バグ
・tmp,test,hoge,下品な言葉, 自分の名前などの適当な命名 *3
・開発者自身が読み直しても理解できないと思われるコード
可能な場合には担当者とペア・プログラミングをして自分色に染める過程を見せる。 ごめんね。でもこの愛の鞭は必要なの。

レベル3のコードを見たらまず手を加えたいと感じるが、
レベル1に至っては限りなく趣味に近い。

忙しいというのに昨日の仕事の時間の8割近くをレベル1〜レベル2前半を
自分色に染め直す作業に使ってしまった私でありました。



*1 パッケージごと import(include/require/use/using) するのを避けて個々にクラスを import しているにも関わらず、使われていないクラスが import されていたりする場合。

*2 場合によっては必要となるが、今は必要なくなっているという類のコードであれば残しておいても問題ない。開発の過程でとりあえず動かしてみるために試行錯誤した時のコードで不要なものが残っていると NG。

*3 私は大学時代にバイト先で niwatori.pm という Perl モジュールを書いて激しく怒られたことがある(niwatori は私のハンドル名の一つ)。


リファクタリング―プログラムの体質改善テクニック
マーチン ファウラー Martin Fowler
児玉 公信 平澤 章 友野 晶夫 梅沢 真史
ピアソンエデュケーション (2000/05)
売り上げランキング: 8,941
おすすめ度の平均: 4.73
5 ソフトウェアの改善に関する良書です。
5 プログラマーにとって必須アイテム
5 いい本です