動的型付け言語はやはり使用できない

Web上で見られる動的型付け言語の利点は、それを書いた人が、現在、動的型付け言語の方が素晴らしいと思っていることは理解できる。しかし、どういう経緯でそう考えるようになったのかがいまいち分からないものだった。

BEST SOFTWARE WRITING の中の1章に、ブルース・エッケルという人が書いた"強い型付け vs. 強いテスト"というエッセイがある。

ここでは、元々静的型チェックを支持していた著者が、どのような経験を経て動的型チェックの方が素晴らしいと考えるに至ったかが記述されている。

私が静的型付け言語の方が優れていると考えている理由(静的型付け言語ではコンパイル時に分かるエラーが、動的型付け言語だと実行時になるまで分からない)と、著者が過去そうであった理由が全く同じであることもあり、今まで読んできた「動的型付け言語のメリット」に対して最も説得力があると感じた。

最終的に著者は、「テストされていないものは、壊れていると思え」、つまり、動的/静的に関わらずテストは行う必要があり、どちらも必ずテストを行う必要があるのであれば、動的型付け言語の方が柔軟性がある分優位である、としている。

上記について、理解はできるものの、やはり同意はできず、今のプロジェクトの実情からは、彼方の理想論にしか聞こえない。今までテスト無しで動かしてきたプログラムが山のように存在しており、例え、今、新規にプロジェクトが立ち上がった状態だとしても、同じメンバであればやはり同じような結果になるだろうと思われるからだ。

そのようなレベル(CMMIでいうとせいぜいレベル2だろうか)のプロジェクトでは、コンパイルによるチェックすら重要なテストのうちの1つであり、省略することは即破滅へ導かれることになる。

問題点である「テストが行われていないこと」については、解消できるのだろうか。少なくとも私の周りの人間の中には、そのような状況に対して危機感を持っている者は極少数であるし、実際実行できるスキルを持っている者も同程度のように見えるのだが。

最近、やっと定期的な静的チェックを開発プロセスの中に組み込むことができた。本の中の理想的な開発プロセスでは、JUnitなんかを実行させているところだが...

BEST SOFTWARE WRITING

Joel on Softwareの著者であるJoel Spolskyが編者として著名人(残念ながら私が以前から知っていた人はほとんどいないが)の書いた記事を集めた書籍。昨日購入したばかりで全ては読めていないのだが、Joel on Softwareより『ヨミモノ』色が強くなっているので、実開発に役立つ度合いはかなり低いと思われる。オリジナルのタイトルには"1"と与番されているので、もしかすると2巻以降も出るのかもしれない。