ソフトウェアの再利用について
ソフトウェア再利用は開発効率と品質を向上させるための方法論の中でも最も重要なもののひとつである。だが、多くの組織はこの方法論の適用に対し積極的とは云えない。それはなぜだろうか。
ヨードンは、その理由は４つあると説明している。
・ソフトウェア工学の教科書は読者に「初めて習った原理」でシステムを作ることを教えている。再利用するようには教えていない。或いは再利用そのものを教えていない。
・自分の作ったもの以外を使わない。他人が作ったものを信じない。
・過去の失敗が再利用は実践的ではないと思わせている。
・再利用を高めた者に対する表彰を組織はしていない。生産性評価は新規開発者が対象で、再利用をした者はその半分以下の評価しか得られない。
ソフトウェアの再利用について
ソフトウェア再利用は開発効率と品質を向上させるための方法論の中でも最も重要なもののひとつである。だが、多くの組織はこの方法論の適用に対し積極的とは云えない。それはなぜだろうか。
ヨードンは、その理由は４つあると説明している。
・ソフトウェア工学の教科書は読者に「初めて習った原理」でシステムを作ることを教えている。再利用するようには教えていない。或いは再利用そのものを教えていない。
・自分の作ったもの以外を使わない。他人が作ったものを信じない。
・過去の失敗が再利用は実践的ではないと思わせている。
・再利用を高めた者に対する表彰を組織はしていない。生産性評価は新規開発者が対象で、再利用をした者はその半分以下の評価しか得られない。
仕様変更における対応
システム開発で仕様変更が発生した時に開発者たちは通常どうするのだろいか。ある開発者はこんな云い方をした。
ホットスポットを実装する
[リーダブルコード]コメント：ライターズブロックを乗り越える
これがJavaであれば、私ならテンプレートメソッドパターンで局所化しプログラム完了の遅延を図る。
テンプレートメソッドパターンではフックメソッドの実装を下位クラスに委ねる。
このパターンは処理の一部がホットスポットである場合によく用いられる。ホットスポットとは仕様変更が入りやすい、或は仕様が曖昧な箇所のことである。
例えば、CSVファイルを取り込みDBにロードしたいがCSVファイルのデータを配列に変換するにはどうすれば良いかが分からない、という状況で使う。
CSV形式ではデータがカンマを含む場合、ダブルクオテーションでくくるというルールがある。しかしこれはカンマがあるデータだけというルールではないため複雑なプログラムとなる。APIもなしにこれを実装するのは大変である。
そこで「データ値にはカンマもダブルクオテーションも入らない」という前提でとりあえず実装する。
まずホットスポットである「CSVファイルを配列に変換する処理」をフックメソッドとして局所化する。コメントには「CSVファイルの各データを配列として返す」と記する。ただしこのメソッドは中身のない空メソッドもしくは抽象メソッドである。
次に子クラスにてフックメソッドを実装する。このコメントには「CSVファイルの各データを配列として返す（ただし各データ値にはカンマは含まれないものとする）」と記し、その通りの実装を行う。こうすることでデータ値にカンマ入るという仕様にも対応し易くなる。
例を示す。
abstract class Helper {
/** CSVファイルの各データを配列として返す/*
abstract String getCsvData(File file);
}
class HelperImpl extends Helper{
/** CSVファイルの各データを配列として返す（ただし各データ値にはカンマは含まれないものとする）/*
String getCscData(File file){ ... }
}
<component name="Helper" class="HelperImpl"/>
これは「CSVにはカンマが入らない」前提のプログラムであるが「やはりCSVにはカンマが入ることになりそうだ」と云われても簡単に対応することができる。具体的には以下のクラスを定義しdiconファイルを修正する。
class HelperImpl2 extends Helper{
/** CSVファイルの各データを配列として返す/*
String getCscData(File file){ ... }
}
<component name="Helper" class="HelperImpl2"/>
可視性の高いコード
[リーダブルコード]コメント：情報密度の濃さ：正確に書く
なかなか面白いことを書いている。
もしも私がプログラマで、コードレビューでこのような指摘がでたらなかなか厳しいレビューアだなと思うだろうが確かにその通りである。行数カウンタなどの機能においてもこの観点は重要である。ただ、本来これは設計レベルの話でプログラマにそれをコメントする責任を負わせるのは酷かもしれないとは思うが。
だが、記事にもあるがそれは関数のヘッダコメントの話である。コード文中のコメントであれば長々と書くべきではない。長々と書かなければならないのであれば関数化しなければならない。コード文中のコメントを長々と書くとプログラムの可視性を著しく落とすのである。たとえ関数の中身が一行になろうとも関数化が必要だ。
また曖昧さはコード文中であろうと関数ヘッダコメントであろうと完全に除去せねばならない。下手に「エレガントな文章の方が分かりやすい」などと砕けた文章で格好つけたり、読み手に解釈を強いる曖昧さを残す文章にしては「絶対に」いけない。もしも曖昧なコメントがあれば冗長でもいいから正確に書くべきだ。そして必要なら関数化する。
このようにリファクタリングを行うと最終的にはコード文中からコメントがどんどん消えていく。コード文中のコメントが関数のヘッダコメントに変換されていくのである。結果可視性は向上していく。
「読める」コードにはそのような工夫が必要である。
経験をもっとすべし
色んな人が「オブジェクト指向やデザインパターンを中途半端な知識で使うな」という趣旨の事を仰っています
正論です。パターンや設計手法は「考え方の見本」であり、それらを考えなしに使うというのは本末転倒です
けれど私はやはり、
「やりたいならどんどんオブジェクト指向やデザインパターンをやったみたらいい」
と言いたいです。
オブジェクト指向にこだわったせいでクソコードを書いてしまうような経験の浅い人は、たとえオブジェクト指向を禁止されてもクソコードを書いてしまいます。
オブジェクト指向プログラミングの経験不足が今のプログラマに否めないのは、彼らの責任ではない。彼らの現場がオブジェクト指向開発でなかったり、彼らの先輩、上司がオブジェクト指向に疎いからである。
本来プログラマは好奇心が強い。技術習得のために講習会に出たり社内勉強会を積極的にするとかしたいのである。然しそうした技術習得をしてもその先に使える可能性がほとんどないのであればその努力は無駄となる。それではモチベーションはあがらない。
であれば営業はできるだけ新技術を使った開発を受注したり、あるいは管理者も自ずから新技術を学びそれを実際のプロジェクトに適用する。同時にプログラマを講習会にいかせたり社内勉強会を支援するなどの企業努力が必要である。
然しそれでも未経験というリスクがある。
例えばデザインパターンはよい設計のテンプレートだが経験がないとうまく使えない。経験不足で使うと逆効果となるリスクがある。これは未経験の者が誰でも通るどうしようもない壁である。
であれば仮想プロジェクトで経験すればよい。
最初の経験をリスクなくこなせるのが仮想プロジェクトである。いや、リスクはあるがそれが顕在化したところで損害はない。これは仮想プロジェクトの強みである。こうした仮想プロジェクトへの参加は講習会などで経験できる。
或は自社で実験プロジェクトを企画し経験してしまうのもよい。
そうやって次回の本番までに経験しておく。それでリスクは減るのだ。もちろんリスクがゼロになることはない。だがそれは経験数が増えても同じである。だからとりあえず一度経験したら本番プロジェクトにチャレンジすればいい。
然し、そうした仮想プロジェクトに参加するチャンスのないプログラマもいるだろう。そういうプログラマはどうすればいいのか。
「やってしまう」しかない。
賭けである。
もちろんそのためには最低限しなければならないことがある。
リスクを承知でやるとしてもそれを回避するためのリスクマネージメントをしなければならないということだ。それを調べることが経験の代わりになる。
当たり前だがお客様の損害のリスクヘッジを最優先にしなければならない。そのためには工夫も必要だ。失敗しリスクが顕在化した場合の覚悟も要る。無間残業地獄が待っているかもしれない。下手すればクビである。その上で「使ってみたい」という欲望にかられたなら使うしかないではないか。なら、使え！使ってしまえ！
リスクシミュレーションをしながら真剣に技術を研究し挑戦するというぎりぎりの状況でこそプログラマは常識では考えられない飛躍的な技術的躍進に導かれるのだ。
そしてこれは多くのプログラマが経験する道でもあるのだ。
