保身の設計

ソフトウェアの規模が大きくなってくる、そして代々のコードをメンテしながら継ぎ足しで開発していると、どうしても新しい機能を追加する事になった場合に「自分が担当する機能にいかに影響を与えないようにするか」という視点で設計してしまう。

そう考えるのはある意味当然なんだけど、それが行き過ぎて、機能を提供する他モジュールに対して非常に使いにくいAPIを提供したりというケースが起きる。自己保身が強すぎるのだ。

設計の理想と、現実の継ぎはぎコード。そして短い開発期間。それを考えると自分のところにバグが出なければ、と保身に走ってしまうのだけど、使いにくいAPIが原因で新たなバグを誘発することもあるだろうし、さらに後々の機能拡張でそこがネックとなることもけっこう多いように思う。

いつ、どのタイミングで、リスクを取って既存コードを整理しつつ、使いやすいAPIを提供するかというのを考えないと、製品開発では機種を追うごとにどんどん機能追加が行われていくから、タイミングを逃すとリファクタリングすらできない状態に陥ってしまう。あまりにも肥大化しすぎて、通常の開発期間内にリファクタリングできない、と。

そうなるとコードとしてはもう首が回らない。ひたすら綱渡り的にコードの追加修正をするハメになり、余計に保身をせざるを得ない悪循環。

そうならないためにも、大規模なコードのリファクタリングは少しずつ、継続して行うようにしたほうが良いはず。細く長く。時間に追われていると追加機能の実装ばかりが頭に浮かぶけれど、後々自分が苦労しないためにも、カイゼンは意識しよう。私も。

タイトルとURLをコピーしました