top / index / prev / next / target / source

2005-06-23 diary: プログラミング言語の自由度と とんでもないバグとの関係

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

プログラミング言語の自由度と とんでもないバグとの関係

プログラミング言語には自由度が多い方が、実現可能な対象領域が増えてうれしいです。でも プログラミング言語に自由度があればあるほど、とんでもないバグやソースコードと出会う可能性も増えます。

プログラミング言語の自由度と とんでもないバグとの関係

プログラミング言語には自由度が多い方が、実現可能な対象領域が増えて 私個人がプログラミングするうえでは うれしいです。でも プログラミング言語に自由度があればあるほど、他人が作成したとんでもないバグやソースコードと出会う可能性も増えます。Java言語って 言語仕様として一定の自由度が与えられているうえに APIが充実しているので、いろいろな対象領域の実装が可能であると同時に、とんでもないバグを作り込む表現力をも持っています。

なんてことを ここのところ感じていたら、artonさんの日記に心を打つディスカッションが載っていました。

全部 staticメソッドって、笑い話のように見えるけれど 実際に とんでもないバグとか見せつけられると、本気で検討したくなってしまいそうです。あるいはフィールド変数さへ利用しなければ全部staticメソッドにしなくたって良いのかしら？ (フィールド変数が利用禁止だったら 全部staticメソッドと あんまし意味変わらないですねぇ…)。ああ、そういえばつい最近、このパッケージのクラスは全て staticメソッドのみとする、ような開発規約を作った記憶がよみがえってきました。パッケージ毎に作成が許可されるクラスを規定し、あるパッケージ以下は全て staticメソッドのみとする、みたいにすれば、 フィールド変数に起因するバグの発生箇所が限定できますね…。

おそらく こういう話題は、規模の小さいプロジェクトにおいては あまり深刻な問題ではないのでしょうけれどもね…。規模が大きくなればなるほど、指数的に悪化しがちです (T_T)

2005.06.27追記 artonさんのツッコミ

ここからいがぴょん指摘の通りです。ご指摘 ありがとうございます。恥ずかしいことに、リフレクション可能かどうかという考察はすっぽ抜けていて、単にクラスの実装側の立場で書いておりましたです。ああ、反省しました。

それじゃあ、今後手がける○○標準化ドキュメントのタグイにおいて、特定のパッケージ内のクラスに制約をかけまくる (私はそんなお仕事ばっかり) ような仕様を決定しないといけない場面に出会った際に、staticメソッドを書かせるのか、あるいは フィールド変数を完全禁止させるのか、となると やっぱり即答できませぬ。どうしてもケースバイケースというかTPOとにらめっこのような気がします。世の ものすごく厳しい性能要件があるような実開発である場合には、インスタンス化によるメモリのガベージ発生を少しでも抑制したいので、staticメソッドを採用してしまいそうです。これはあまり知られていないのですが、ものすごく厳しい性能要件の場合、CPU消費量よりもメモリガベージ発生量の方が性能に直結するような場面があるのです。その数バイトのメモリのゴミが動作上致命的な影響を与える場合があるのです。そこまでメモリのゴミがシビアではない場合には、インスタンス可能な選択肢を積極的に選択しそうです。ああ、でもぎちぎちの低水準ユーティリティメソッドの際には、staticメソッドの方が世の方々の常識に訴えやすいような気もして、またここで信念が揺らぎます。難しいですね。やはりTPOに合わせた選択肢というものを常に考えて、バランスを取るとう選択肢を選ばざるをえないようになってしまいそうです。

ユニットテスト (単体試験) を行うということと、JUnitによってユニットテストを実施するということは、残念ながら別のことです

ユニットテスト(単体試験) を行うということの中に JUnitによってユニットテストを実施するということは含まれますが、残念なことに JUnitによってユニットテストが実施されているからといって、ユニットテスト(単体試験)が適切に実施されたとは言えません。

最近 JUnitがビミョウに普及してきて JUnitを利用してユニットテストを実施する人が増えてきましたが、そうすると今度は JUnitを実施するとなんだか全てのユニットテスト(単体試験)を実施できたのではないか、という幻想を抱いてしまう人が増えてきてしまっているように考えます。特に テストファーストという概念などが不完全に理解されあるいは普及して、JUnitコードの作成にはがんばるのだけれども 試験観点が 全く偏った不完全なもののままユニットテストを完了したと誤解してしまう人がいるのです。

あくまでも ユニットテスト(単体試験)における 幾つかの試験観点のうちのひとつについて、JUnitによって実装および実現が可能であるだけなのです。そもそもの試験観点が適切でない場合に、いくら大量のJUnitによるテストコードを作成しても、ソフトウェアの品質は向上しません。ソフトウェアは試験観点が適切な状態でユニットテストされないかぎり、バグが残ってしまいます。

また、試験観点のうちの幾つかについては、JUnitによるユニットテストの方が実施コストが低いものもあることはあります。しかし JUnitによるユニットテストが手作業のユニットテストよりもずっとコスト高である試験観点も多くあるのです。ようはバランスとか TPOなのですけれども、、、バランスを取るのって、難しいですね。おもえば、オブジェクト指向のさじ加減にしろ デザインパターンの適用にしろ、そしてユニットテストのJUnit化にしろ、その適用範囲はバランス感のある人にしか判断できないのです。、、、さて どうやったらバランス感って身に付くのでしょうね…

さらにもっと根本的なものとして、 ソースコードの品質向上は ユニットテスト(単体試験)によってだけでは保証できないということです。そもそも ソースコードの品質は他者によるソースコードレビューをもってしか向上できません。他人がソースコードを見て 初めて気がつくことがあるのです。プログラマが言語仕様を誤解している、あるいは言語仕様の理解が不十分である場合に、びっくりするようなソースコード記述・実装がなされている場合があるからです。

ソフトウェア開発工程定義によっては ソースコードレビューはユニットテスト(単体試験)工程に含められることもあるのでしょうけれどもね。ソースコードレビューを経てのみ、ソースコードの品質は初めて最低限のところが担保されるのです。ソースコードレビューが終わってから、初めてユニットテスト(単体試験)の実施に取りかかることができます。テストファーストでJUnitのコードが幾つか提供されていたとしても、所詮それは ごく一部の試験観点によるユニットテストが提供されているにすぎないのです。多くの場合 ユニットテスト(単体試験)工程において、あらかじめ作成されていた

JUnitのテストコードには頼らずに、新たにユニットテストを実施 (そしてその作業の一部として JUnitのコード記述) を行っていくことになるでしょう。あるいは開発工程定義などの際に、テストファーストを実施してそれをユニットテストとしても利用できそうな試験観点をあらかじめ規定・設定しておくと、テスト工程の全体効率が向上するようにも思えます。そのあたりは工夫のしがいもありそうです。(重要なのは試験観点とテストファーストの適用範囲マッピングなのでしょう)

…ユニットテスト(単体試験)って難しいですね。小さいプロジェクトを実施しているだけだったら あまり気にしないで良いのですけれども、規模が中くらいを超えだしたら、ユニットテスト(単体試験)の難易度はどんどん上がっていってしまいます。そういう場面では 適切に ユニットテスト(単体試験)に関する基礎的な知識を身につけた人材が必要になってきます。特に試験観点の設定はそれが実現するソフトウェアの仕様とともに、実装技術とか言語仕様とも深い関わりがあるので、マルチな知識・技能を持った人が必要になってきます。大変なことです…。

バランス感覚

ちょうど Cafe Babeさんの日記に、バランス感覚とか対人能力とかの話題が載っていました。

この日記を読んで、いろいろ考えさせられました。いろんなアイデアがちりばめられていて 刺激的です。さあて、じゃあ私にコンピュータ・ソフトウェアに対する哲学が ちゃんと備わっているのかしらん…、などと、まだまだ考えが行き渡っていないところをいろいろ考えさせられます。もっと考えを深めて行かなくては…。でも時間が無い (苦笑)

そして、そういえば 私はアマチュア音楽家(ヴァイオリニスト)ですね…。一応自分では芸術家のつもりでいます (上手じゃ無いけれど)

恥ずかしいバグに遭わないために努力すること

とりあえず恥ずかしいバグについて、身内から発生させないようにするための継続的な努力が大事です。ちょっとソースコードレビューを行う、あるいは ちょっと気の利いた単体試験を一回でも実施したら簡単に発見できるようなバグを発生させないよう、継続的に努力していくのです。メンバーが多い、あるいはメンバーの追加が発生しがちな現場では大切な考えです。

恥ずかしいバグの例

とりあえず恥ずかしくない程度の品質になるよう ソースコードレビューやユニットテスト(単体試験)を実施する／実施させることが大切です。バランスの良い試験観点をもって適切なバランスの試験実施件数を おのおの試験観点に対して実施していく、これこそが 恥ずかしくないバグを発生させないための大事なポイントなのでしょう。バランスの良い試験観点の洗い出しは難易度が高いので、ある程度の技術力を持った他者による試験観点の提供も大切です。

マイブーム: 「ふけましたね」と言われること

ここ最近の仕事のなかで、ひさしぶりに お会いする人が多いです。そんな中、その久しぶりにお会いした人の第一声が「いがさん、老けましたね。苦労されてらっしゃるようで」である確率が非常に多いです。そんなに急激に白髪が増えたのかしら…。、、、なあんて書くと、よけいにその確率は向上してしまうかもです (笑)少なくとも、日記の写真と現状とでは、かなりの乖離があるのでしょうね。今調べたら、写真は２年前のものでした。

この日記について