凪瀬 Blog
Programming SHOT BAR

目次

Blog 利用状況
  • 投稿数 - 260
  • 記事 - 0
  • コメント - 47035
  • トラックバック - 192
ニュース
広告
  • Java開発者募集中
  • 経歴不問
  • 腕に自信のある方
  • 富山市内
  • (株)凪瀬アーキテクツ
アクセサリ
  • あわせて読みたい
凪瀬悠輝(なぎせ ゆうき)
  • Java技術者
  • お茶好き。カクテル好き。
  • 所属は(株)凪瀬アーキテクツ
  • Twitter:@nagise

書庫

日記カテゴリ

 

Kanazawa.processというテスト駆動開発の勉強会が開催されたので参加してきました。話題に上がったネタの技術的な部分をいくつか補足しておきます。

副作用

この勉強会ではテキストとしてテスト駆動開発入門を用いました。 第一章で出てくる「副作用」という表現。あまりにも一般用語然としていますが、プログラミングの専門用語として「副作用」と言う場合、 状態の変更によって得られる結果が変わることを言います。 wikipediaにも 副作用 (プログラム)という項がありますね。変数の破壊的代入というような言い方もします。

関数型言語では関数が副作用を持たない、つまり、同じオブジェクトを引数に渡したとしても、オブジェクトの状態が変わったことによって メソッドの呼び出し結果が異なる、といったことが起きません。そのために変数への代入は初期化のみが許されて、 再代入(破壊的代入)は許されないという特色があります。

その利点にあやかるべく、値を表すオブジェクト(バリューオブジェクト)には Immutableパターン というデザインパターンが適用されることが多くあります。 Javaの標準APIでは、Integerなどのプリミティブ型に対するラッパー型や、BigDecimal型などがこうした設計になっています。 これらは不変オブジェクトと表現されることもあります。

今のJavaには破壊的代入をコンパイラにチェックさせる機構がありませんが、JavaVM上で動作するScalaなど、 関数型の流れも汲み入れた新しい言語ではこれをサポートする機構が存在します。 Scalaの場合は変数宣言にvarとvalというキーワードで再代入可能な変数と再代入不可の変数を使い分けることができます。 IT Proの記事がわかりやすいでしょうか。

また、Java7での拡張に含まれる予定のJSR 305では バグを根絶するための各種アノテーションの提案がされています。 マイコミの記事が詳しいですね。 この候補として@Immutableというものも候補に挙がっており、Java7ではコンパイラでチェックできるようになるかもしれません。

不変オブジェクトとGC

Javaの理論と実践: パフォーマンスの都市伝説 でも述べられているように、不変オブジェクトを用いることによって目に見えるようなパフォーマンスの劣化が起こることはありません。 90%のオブジェクトは作られてすぐに廃棄されると言われており、近年のGC(ガーベッジコレクション)は世代管理をして こうしたライフサイクルの短いオブジェクトの回収を効率的に行えるように設計されています。

オブジェクトの再利用を行う機構を作ったとしても、不変オブジェクトの生成と破棄を行うスタイルと 目に見えるほどのパフォーマンスの改善を得ることはなかなかできません。 下手に頑張ったところで残るのは再利用や修正のしにくい醜い設計のプログラムだけです。

ソフトウェア品質の12の属性で取り上げたとおり、 パフォーマンスチューニングによる効率性の向上のためには、柔軟性、相互接続性、保守性、移植性、信頼性、堅牢性、試験性、使用性が犠牲になります。 そこまでの多大な犠牲と、パフォーマンスチューニングにかける時間、労力、そしてわずかばかりの効率性が釣り合うのかを冷静に判断してください。

大規模開発と静的解析

大規模特有の難しさと言うのは「人」が増えることによる開発の難しさなんですよね。 多くの人が関わって作業をすると言ったときに、メンバーの技術的ばらつきは大きくなる。 作業のやり方を統一することも難しいし、何より人間はヒューマンエラーを起こすのです。 これを漏れなく拾うことの難しさ、そしてフィードバックして個々人をレベルアップさせることの難しさがあります。

まぁ、ぶっちゃけて言えば手が回らない。なので、人海戦術はやめにして、機械化しましょう。 システム開発を機械化で高生産にするわけです。ビバ産業革命!

技術を持った人が注意深く作業する必要のある単純作業なんてのは、機械にやらせてしまいましょう。 そう、リファクタリング機能です。EclipseやNetBeansには高度で信頼できるリファクタリング機能が搭載されています。 静的な構文解析に裏打ちされた安定した機械的なリファクタリングを活用しましょう。

FindBugsプラグインなどの静的解析ツールによる機械的なコードレビューを活用しましょう。 命名規約やフォーマットのチェックなんてのはCheckStyleプラグインで機械的にチェックしてしまいましょう。 データ型の不一致をあぶり出す机上デバッグなんてやめて、ジェネリクスを使ってコンパイラでの静的型チェックをしましょう。

技術を持った人が注意深く、ヒューマンエラーと戦いながら退屈な単純作業をやらなきゃいけないなんて そんな低生産なやり方はガーベッジコレクションに回収させてしまいましょう。 もっとも、頭の固いエライヒトがいつまでもそのやり方を参照しているとリークしていつまでも回収できないのですけどね。

投稿日時 : 2009年5月19日 0:19
コメント
  • # re: Kanazawa.processで挙がった話題の補足
    Geo=TK3
    Posted @ 2009/05/19 2:12
    はじめてコメントさせていただきます。
    本エントリからリンクを辿ろうとして気付いたのですが

    >その利点にあやかるべく、値を表すオブジェクト(バリューオブジェクト)には...

    に続く「Immutable パターン」という言葉に張られているリンクの href 要素が""で囲まれていないようです。
    その為 Firefox3/Internet Explorer 6 では

    >その利点にあやかるべく、値を表すオブジェクト(バリューオブジェクト)には IT Proの記事がわかりやすいでしょうか。

    と表示されてしまっています。
    お手すきの時にでも修正していただけると助かります。
  • # re: Kanazawa.processで挙がった話題の補足
    凪瀬
    Posted @ 2009/05/19 20:26
    失礼しました。タグの不備などを修正しました。
    ご指摘感謝します。
  • # re: Kanazawa.processで挙がった話題の補足
    Geo=TK3
    Posted @ 2009/05/20 2:40
    いえ、こちらこそ早速修正していただき、どうもありがとうございました。
タイトル
名前
Url
コメント