再利用をめぐるあれやこれや

こんにちは、ずいぶん久しぶりの更新のテーマは、再利用性です。

再利用性はソフトウェア工学永遠のテーマです。 再利用性は生産性を向上させるための必須項目とされています。 多くのプログラミング言語やプログラミング環境が再利用性を謳い、それでいてその多くは話題から去っていきました。 たぶん、その言語や環境が提供する「再利用性」なるものが、多くの人にとって必要とされている「再利用性」とは異なっていたのでしょう。 その結果「もっと上流で再利用しないと、下流でだけ再利用しても効果がないよ」とか「それはツールがまだ揃ってないからだよ」とか、色々な枝葉が出てきています。 そこで、ふと思うのです。再利用って一体何なんだろう？再利用が向上させる生産性とは一体何なんだろう？

単純に考えれば、プログラミングにおける再利用性というのは、あるプログラムの構成要素を別のプログラムを構成するために流用することです。 関数であったり、述語であったり、オブジェクトであったり、クラスであったり、パッケージであったり、プログラムの断片だったり、色々な構成要素が再利用の対象になります。 ある関数を別のプログラムに流用する。簡単じゃん、どうしてみんなそうしないの？と思いますが、もちろん簡単じゃない理由があります。

全てのプログラムには、正常に動作するための条件が設定されています。CPUだったりOSだったりメモリサイズだったりネットワークだったり、色々な「環境」を前提にしています。 プログラムの構成要素にも前提条件があります。逆に言えば、前提条件に合致しない環境に流用しても正しく動作しません。 例えば、引数として整数を受け付ける関数に文字列を渡しても正常に動作しません。 静的型付け言語であれば型エラーや暗黙的型変換をするでしょう。動的型付言語だと動くかもしれませんし、動かないかもしれません。 この意味では、再利用性を高めるためには前提条件を少なくすることが必要だと言えます。 より正確に言えば再利用性を高めるためには前提条件を明確にすることが必要で、さらにその前提条件が少なければ嬉しい、ということになります。

その上で、前提条件を変更しやすいということが大事だと思っています。

単純な例として、ソートを挙げてみます。 整数の配列を引数として取って、その内容を小さい順に並べ直した配列を返す関数を定義してみます。 ここで再利用性を高めるために何が出来るでしょうか？ 配列の要素の型を、整数だけでなく浮動小数点数や文字列など、他の型でも使えるようにすることも「前提条件の変更」です。 また、配列だけではなく、線形リストや木構造を引数として取る事が出来るようにすることも「前提条件の変更」です。 さらに引数が一度に与えられるのではなく、関数を評価している最中に引数の配列の要素が段々と埋まっていく、という環境でも使えるようにすることも「前提条件の変更」ですね。 もしかしたら、「大小関係」自体も最初から定義されているのではなく、ソート関数を評価している最中に１つ１つ例示しながら学習していく、というのも考えられます。 前提条件には、データ構造も制御構造もIOも問題定義自体も含まれます。 どれも変わるかもしれない前提条件なのです。

オレオレ哲学になっちゃいますが、世の中には通時的に必然的な正しさなど無いと思います。 何が正しいのかはその時やその場所によって移り変わっていく世界観や価値観で変わっていきます。 データ構造も制御構造もIOも問題定義も、どれも前提条件として変化していくものです。 一度書いたらあとは使うだけ、というのは幻想です。 書いたときには絶対に正しいと信じていた事が、後になって間違いに変化してしまうのが常です。

一度書いたら、次はもっと良いモノを書く。 それをやりやすいプログラミング言語、それをやりやすいプログラミング環境というのが、再利用性の高い言語や環境だと思います。

同じことが生産性にも言えます。 生産性とは何でしょうか？ 多くの職業プログラマにとって生産性とは、単位時間に生産するコードの量でしょう。 同じ期間かけたらより多くのプログラムを書いた方が生産性が高いし、同じプログラムを書くのに必要な時間が短かくてもやはり生産性が高いと言われます。

では、再利用の視点で生産性が高いプログラマとは、過去に誰かが書いたコードを継ぎ接ぎしてコードを仕立て上げる能力が高いプログラマなんでしょうか？ たぶんソフトウェア工学的にはそうなのでしょう。 でもそれってなんか違うと思うのですよ。 だって、プログラマは生ものですから。

オレには「ある問題を解決するためにプログラムを書いたら、次に問題を解決する時にはもっと良いプログラムを書ける」という信念があります。 逆に言えば、そうでなくなったらプログラマを引退すべきだと思ってます。 生産性が高いプログラマになるということは、大量のコードを書けるということではなくて、その問題を解決するためにより簡単に、より便利に、より納得がいく解決法としてのプログラムをサクッと書ける、ということだと思っています。 つまり、オレにとっての生産性とは、同じ時間でどれだけたくさんのコードを書けるかではなく、同じ時間でどれだけ賢くなれるか、ということです。

そうでも思わないと、別に賢くもないオレなんて、やってられませんよ。ツ