コーディングの負担を減らす

コーディングの負担は大きく分けて二つに分類できます。

まず一つが仕様書通りのプログラムを書くことです。
この負担を減らすには、良い仕様書が求められます。
また複数人でコーディングする場合、必要なグローバル変数をあらかじめ指示しておかないと、入出力において予想しない動きを出す事があります。
理想を言えば全ての必要な動作をチェックし、紙の上でデバッグまで行った仕様書が良いでしょう。
またマニュアルにこだわるように、仕様書の指示を与える文章も解釈の余地が無いように詰めの作業を行っておくと、早くてバグの少ない良い製品ができるでしょう。
ただし解釈の余地がないようにすることはハンドルで言えば「あそび」を無くすことですから、仕様書の指示が間違っていた場合破滅的な結果をもたらす事があります。
ちなみに紙の上のデバッグは都市伝説のように思われていますが、小さな製品の場合はむしろそれを行える程要件や仕様を理解できる人間が必要でしょう。
例えばバグが非常に少ないプログラムとして有名なTeXの開発者ドナルド・クヌース教授は、TeXの開発の時に紙の上でデバッグを行い、プログラムは学生に半分ほどを委任しています。
その学生の中にはプログラムを殆ど知らない人物も混じっていたそうです。
しかしTeXはほぼ計画通りに完成しました。
ウォーターフローモデルは上流が非常に優れていればいるほど、下流の負担が少なくて済むという良い事例です。

もう一つのコーディングの負担はプログラムを書くこと。
これは実際に人間が一文字一文字コードを打っていくという作業そのものを指しています。
この負担の軽減に関する答えの一つとして、オブジェクト指向があります。
あるプログラムを別のプログラムで再利用するという概念は構造化プログラミングの前からもありましたが、それの実現を目指したのがオブジェクト指向です。
ある処理を別の部分でも使うなら、同じプログラムを別の場所から呼び出してやれば良いのです。
さらにもう一つの答えとして自動プログラミングがあります。
これはAIによりある要求を与えたときにその要求を実現するコードを自動で出力させる物です。
この研究はかなり昔から考えられていましたが、要求の定義や学習方法などの効率の良い方法が定まらずに未だ流浪している状態です。
しかし少し前にプログラムが、運動の物体のデータを用いて与えられていないF=maを導き出すことに成功しています。
少なくともよく使われているようなプログラムなら、案外早く実現するかも知れませんね。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*