goo blog サービス終了のお知らせ 

職業JAVAらーの憂鬱

職業JAVAらーの、世のため人のため以前に、自分のための覚え書き。

VS古いコード

2007-09-25 00:15:51 | Weblog
ユーザ主導のパッケージ開発に途中からアサインすることがある。
もう何度もバージョンアップリリースして、そこそこのボリュームがあるパッケージ。

途中から製造メンバーとしてアサインされたときに難しいこと。

バージョンアップ時に自分が修正を行うとき。
長い間使われ続けている既存のコードをどこまで修正していいのか?
このメソッドのI/Fを変更していいのか?
色々考えると、どうしても既存のI/Fは極力そのままに、当たり障りの無い修正をしてしまう。
特に、曰く「共通部分」ならなおさら。
当たり障りの無いっていうことは、この場合要はツジツマあわせ。ツジツマあわせをするってことは、
I/Fはあまり変わらないけどフラグが大量発生ってことになりかねない。
というか、ほぼなる。

今後も長くそのコードと付き合っていく正社員なら・・・とも思う。
けど、それは言い訳だろうなぁ。

I/F部分を変えたら影響が大きいからとは言っても、
結局中身が読みにくければ後々修正が大変になる。
特に仕様書がないような環境だと。

実際にコードの変更を行う前に、
修正対象となる箇所を実際に何度も動かして、
コードを何度も読んで、
修正方法を色んなパターン考えて、
その時点でよりベターがI/Fを変えることなのであれば、潔く行動に移すべし。
既存のわからない箇所は聞けばいい。

既存の作りを変えることに怖がるな。
あれこれ理由を作って逃げるな。
作り変えた分、しっかりテストをすればいいんだ。

逃げたところで作り直す恐怖はいずれ出てくる。
その時のコードはもっと難解になっていて、もっと怖くなってる。