2009年11月22日日曜日

Software Designの2つの方法

"Programming in Haskell"のPrefaceで引用されていた一節を再引用。Tony Hoareという人のTuring Award受賞時のコメント。
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
拙訳:
ソフトウェア設計には二つのやり方がある。一つは、極めてシンプルに設計して、バグがないことを明らかするやり方。もう一つは、非常に複雑に設計して、明らかにわかるようなバグをなくすやり方。前者の方がはるかに難しい。
日本語でうまく表せない(訳の問題?)ですが、"obviously no deficiencies" と "no obvious deficiencies" という、単語の並び順で意味を逆転させるところが絶妙。

で、これが "Programming in Haskell" に載っているので「Haskellのような関数型言語でのソフトウェア開発と、C/C++のような命令型言語での開発との比較なんだろう。Tony HoareというのはHaskell関連の人に違いない」と思っていたら全然違いました。

Tony Hoareは、
  • プログラミング言語デザインの研究者
  • Quicksortアルゴリズムを発明した人(知らなかった・・・)
  • ALGOL60を設計 & 実装
    • その際、Nullポインタを導入した事を「数十億ドルに値する失敗」と後悔している)
  • 今は Microsoft Researchのシニアリサーチャー
でした。

つまり冒頭の一節は、ソフトウェア設計一般の話なんですね。とはいえ、少なくとも "Programming in Haskell"の著者は、Haskellを使うことで"obviously no deficiencies"な設計にしやすい、と考えていると言えるでしょう。その理由はprefaceには書いていませんが、「静的な強い型付け言語」というHaskellの特徴と無縁ではないはずです。

静的な強い型付け言語 (HaskellとMLと・・・あと何?) を使った人は分かりますが、(特に初心者は)コンパイルを通すまでに異常に時間がかかります。簡単なプログラムのコンパイルでも、何度も「型がおかしい」とコンパイラに怒られます。型エラーに対応するために、コードを見直し、その過程で型エラーではないロジカルなバグを見つけることもあるでしょう。

「注意深くコードを書く」のは「言うは易し。行うは難し。」の典型例です。プログラミングとはプログラマの思考の明文化なので、「注意深く」というのはつまり「自分に批判的に」ということであり、人間が苦手とする態度です。そこで、プログラマの思考(コード)を批判してくれる人・ものが重要になってきます。

コードの品質を高めると言われている手法
  • -Wall or -Werror
  • 静的な強い型付け言語
  • Test Driven Development
  • ペアプログラミング
  • コードレビュー
は、「コードを批判する」という点において同じ働きをすると言えます。逆に言うと、高品質なコードを書くには、コードを批判する(批判される)環境が必要と言えるでしょう。

(つまらない結論に行き着いてしまった。「"obviously no deficiencies" と "no obvious deficiencies" がおもしろいな」っという小さな感動が発端なので、そこでやめとけばよかった。無理して書いても良いことない、という教訓です。)

0 件のコメント:

コメントを投稿