～ 小さく始めて大きな効果 ～
冗長で複雑化したソースコードに取り組むのは、非常にリスクが大きく、そして時間のかかる作業です。
きれいに整理されたコードの5倍、10倍というのは決して大げさな数字ではないでしょう。
結果は単純な修正でも、最短距離でそこにたどり着けるのは稀です。
まず何処（と何処と何処...）を修正すればいいのかわかりません。
ようやくあたりがついても、「こうすればいいだろう」という修正プランはすんなりはまってくれません。
修正できたと思っても、期待した動作が得られないことは往々にしてあり、試行錯誤が繰り返されます。
そうした作業の中、プログラマのエネルギーは消耗していきます。
コードを頭で再構成して理解する必要があるので脳内のメモリを大量に消費します。
影響範囲が読み切れないので修正には神経を使います。
期待した動作がなかなか得られないと気力、集中力が削がれ、心が折れそうになります。
修正後も意図せずほかの機能の動作まで変えてしまっていないか、不安が残ります。
コードの修正にはジレンマがあります。
「ほかの機能に影響を与えないように」安全な修正にこだわると、コードは冗長化・複雑化していきます。
コードが冗長化・複雑化すると、調査の対象となる範囲、修正に必要な箇所が増えていきます。
不具合修正や機能追加の工数は増え、デグレードのリスクが高まります。
初めはきれいなコードでも、修正を重ねるうちにメンテナンス性は落ちていく宿命にあります。
時間や技術の進歩、コミット単位のコードレビューがそれを解決してくれることはありません。
適切なリファクタリングを施すことで、増大した修正コストやデグレードのリスクを減らすことができます。
必ずしも機能追加を止めて全体を一気に作り変える必要はありません。
最も必要性の高い箇所から、少しずつ、効果を体感しながら安全に適用することが可能です。
弊社には多くのレガシーコードに対処した経験から培ったリファクタリング、ユニットテストのノウハウがあります。
保守工数でお悩みの場合はぜひご相談ください。
よくあるご質問
Q. プログラミングの良し悪しでどのような違いが生まれますか？
A. 例えば、大量のデータを加工してインポートするのに、AとBの2つの方法があります。
どちらも仕様書に記載された機能要件は満たします。
しかし、AはBの3分の1の工数、2分の1のステップ数で実装でき、24倍高速に動作します。
さらに動作検証をすると、Aが用意したすべてのケースをクリアしたのに対し、
Bは使用頻度の少ないデータ型で例外が発生し、調査と修正にさらに工数がかかりました。
このような違いを生み出す箇所がプロジェクトには無数にあり、その積み重ねが、
工数と品質にテストでは取り戻すことのできない決定的な差をもたらします。