「ソフトウェアの改造力」をよんで

元ネタ「ソフトウェアの改造力」
http://itpro.nikkeibp.co.jp/article/COLUMN/20071102/286257/?ST=system

読んで感じた事は、適切に「責務」の分解ができていない、業務上の責務とプログラム上での「責務」が噛み合っていないので、改造が大変になるのではないかと感じた。

「責務」が明確になっているプログラム（スパゲッティーじゃないプログラム）ならば、

労働金庫連合会は，郵便貯金口座からの入金，送金を受け付ける「受付プログラム」を6月19日に新たなプログラムに入れ替えた。目的は，あるチェック・ロジックを改良すること。

　ところが，プログラムを変更した際に，本来は入金だけに必要なチェック・ロジック（図1の左）を，送金処理にも適用してしまった。背景には，送金と入金を，同じ電文フォーマットで処理していたことがある。不要なチェックにより，「キャッシュカード発行済み（再発行あり）」と「キャッシュカード未発行」の送金パターンが誤ってエラーと判定されてしまった。

上記のようなミスは起きないはず。責務に

送金と入金処理をします。送金には、「キャッシュカード発行済み（再発行あり）」と「キャッシュカード未発行」のバリエーションもあります。（まあ、責務と言えるのは、最初の一行だけ気もするが、、、）

って書いてあれば、普通はテスト漏れは起きないと思う。で、更に言ってしまうと「改造力」っていうのは、「開発力」の別の側面でしかないと思う。

唯、動けばいいって言うレベルで、「開発」したのか、保守等の事も考え適切に「責務」の割り振りをした上で「開発」したかのか。この差は、非常に大きいと思う。

また、「責務」という言葉は、「ネーミング」にもつながると思う。「責務」が明確になっていない場合、「ネーミング」は困難を極めるためである（何やっているかわからないものに名前は凄い付けにくい）。ただ、現場では、ネーミングっていうのは軽視されがちな所があり、また、業務を熟知していないと適切な名前は付けれないという面もある。

で、落ちはあるかというと、落ちはありません・・・・
適切な「責務」の割り振りは難しいし、「ネーミング」も難しい。なので、「改造」もきっと難しいままなのでしょう・・・・