I/O BLOG;

input を整理して ouput する訓練ブログ

実装とリファクタリング

とにかく、リファクタリングを今すぐ始める必要がある。

リファクタリング前進である。やり続けると製品は良くなり続ける。時間が経てば経つほど、良くなる。 時間を味方につけることができる。製品は成長する。

いつ、やるのか、やめるのか

開発してるとコードを書く。 いきなり最適なコードを書けるわけではないので、どこかでリファクタリングが必要になってくる。
では「いつ」リファクタリングを「行う」のか、基準が明確でない。
また「いつ」リファクタリングを「やめる」のか、基準が明確でない。

あまりに、やり過ぎてしまうと実装が進まず、納品に間に合わないかもしれない。 しかし、リファクタリングをしないと、コードは泥沼化する。時間を追う毎に、泥は深くなり開発者達の足を遅くする。結局は納品に間に合わないかもしれない。

リファクタリングによって得られる恩恵がそのコストを上回る「損益分岐点」はどこだろうか。

マーティン・ファウラーの『リファクタリング』では、リファクタリングするタイミングは「コードが不吉に臭うとき」であるそうだ。 例えば、

  • 重複したコードがあるとき
  • 一つのメソッドが大きすぎるとき
  • 至るところに同じスイッチ分が現れるとき

などである。

また、静的解析ツールなどを使ってコードの複雑度を計測する方法もいいと思う。

リファクタリングは、プロジェクト開発の納品だけではなく、むしろ保守フェーズのほうが大きく効果がある。 その恩恵はコードの規模と保守期間と比例すると思う。

リファクタリングは軽視されがちだと思う。それはまずは目の前の仕事を終わらせる必要があるからだ。 しかし、リファクタリング自体も「本当に必要な仕事」の一つだと思う。

それは、製品を整然として、品質を向上させ、人がコードを理解することを助ける。会社の財産としての価値が上がる。

実践

開発チームでリファクタリングの習慣がないのであれば、ぜひ取り入れて欲しい。

とにかく、今すぐ始める必要がある。

本来はコードのカオスが広がる速度よりも、リファクタリングの速度が上回る必要がある。 しかし、上回ることができなくても、リファクタリングをやめてはいけない。やらないよりはましだからだ。

リファクタリング前進である。やり続けると製品は良くなり続ける。時間が経てば経つほど、良くなる。 時間を味方につけることができる。製品は成長する。同時に会社も成長する。

目の前の納期は最も大切だが、長期的にも投資してほしい。投資なしでは、その先に待っているのはジリ貧のみである。 既にジリ貧であっても今すぐ始めるべきだ。いつか必ず良くなる。