エンハンス開発におけるアンチパターン:設計改善してデグレを引き起こす

運用歴が長いプロダクトはコードがカオスになりやすい。 プロジェクトに参加してコードを見ると「うわ〜なんだこれ…」とゲンナリして、自分が知っているより良い設計・良いコードに修正したくなる。 確かにコードの見通しが良くてイケてる設計の方が良い。それはそう。ただし、コードを改善するよりも重要なことがある。 それはすでに動作している機能をデグレさせないことである。

運用歴が長いということは、その分ユーザーに利用されている期間が長いことと同義である。 自分の考える"良い"設計・コードに変えた結果機能がデグレした場合、不利益を被るのはユーザーである。

ユーザーはお金を払って1プロダクトを使っている。自分の都合で自分のお給与源になる人の不利益を与えてしまって良いのだろうか。良いわけがない。エンハンス開発で一番重要なのはデグレさせないことなんじゃないか。自分の技量を押し付けてユーザーが迷惑するならそれはプロじゃないのではないか。

ゲンナリする気持ちはわかるし自分もそう思う。しかし、目の前にあるのはお金を生んでいるコードであることには間違いない。設計改善やリファクタリングは仕様を把握してテストを準備してからでも遅くない。全体像がわからないのに改善に着手するのは避けた方が良い。

…というような話を過去Issueを確認しながら思った。自分もやってしまいがちなので気をつけたい。


  1. toC向けであってもお金をどこからは得ているはず。利用者が直接払っているかどうかが違うだけであって。