RubyKaigi 2016 2日目の基調講演は,
Justinさんは古いコードのメンテナンス,
メンテナンス性の重要さ 〜後期の成功に求められるもの〜
Justinさんは今日の問いとして,
「古いRubyを簡単にメンテナンスできるようにできるか?」
Rubyが成功を納めたことに間違いはありません。しかし,
そこで,
リファクタリングとは 「新機能の実装やバグ修正に先立ち, それらを簡単に行うために前もって変更を加えること」
問いに答えるべく,
- リファクタリング::新機能の実装やバグ修正に先立ち,
それらを簡単に行うために前もって変更を加えること - レガシーコード::自信を持って変更できるほど十分に理解していないコード
リファクタリングは技術的にも, ビジネス的にも難しい
リファクタリングが一般的に難しい理由として,
- どれくらいかかるか時間を見積もるのが難しい
どれくらい作業が必要になるかも,どれくらいリスクがあることなのかもわからないため。 - ビジネス的な視点からは価値が見えない
リファクタリングをした結果得るのは同じ振る舞いであり,どんな価値が生まれたのかわからないため。 - 往々にして,
リファクタリングはとても複雑な箇所に施すことになるため, そこの箇所の開発を止めなければならなくなる
複数の変更をそこにマージするのが難しくなるため。
複雑なコードであればあるほど,
また,
そこで,
ここでの前提として,
ですから,
作戦1. 不安を煽る
「リファクタリングをしないと,
- 例1. 「リファクタリングをしないと,
いつかすべてを書き直さなければならなくなりますよ!」 - 例2.
「リファクタリングをしないと, メンテナンスコストは今より相当高くつくことになりますよ!」
しかし,
作戦2. コストを取りこむ
自己規律とプロ意識によってコストを取り込むこともできます。新機能を追加するときには通常,
しかし,
作戦3. 人質をとる
上記2つに代わる作戦として,
しかし,
このように,
そこでJustinさんは次のように主張し,
「自分たちはプログラマーだし,
ビジネス方面で攻めてもしかたがなく,