GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Robert Bazinet , 翻訳者 編集部 投稿日 2008年7月19日
どのようなツールであっても、その使い方を知っている開発者が手にして初めて効果をもたらす。NDepend(リンク)は強力なツールであるが、NDependが扱うソフトウェアメトリクスを理解するアーキテクトや開発者はあまりにも少ない。
今年の1月、製品NDependがどのようなもので、優れたソフトウェア構築にどのように役立つのかを理解するため、NDependチームのPatrick Smacchia氏と話をした(参考記事・英語)。その後、NDependは複数のアップデートを行い、以下のような多くの機能を誇っている。:
ドイツの.NET開発者、Andre Loker氏(リンク)は、最近、NDepend利用に関する開発者の視点での優れたチュートリアル(リンク)を作成した。Andre氏のチュートリアルは、チームに対するNDependの貢献、ツールに期待すること、および、最良の利用方法について解説している。NDependのメトリクスは特に興味深い:
- 求心性結合(Ca:Afferent coupling)
このメトリクスは、所定の型またはメソッドを使用する現在のアセンブリの外部からの型およびメソッドの数を表す。この値が高ければ高いほど、アセンブリ利用者にとって、所定の型またはメソッドが重要である。- 遠心性結合(Ce:Efferent coupling)
Caに対応するメトリクス。このメトリクスは、特定の型/メソッドが使用する、アセンブリ外部の型/メソッドの数を示す。この値が高い場合は、特定の型/メソッドが外部アセンブリへの依存が高いことを示している。- 関係結合性(H:Relational cohesion)
1つのアセンブリ内の複数の型の相互関係性の強さを表すメトリクス。一般に、アセンブリ内の型は、関係が強いことが望ましいが、強すぎてははらない。- 不安定性(I:Instability)
あるアセンブリが、依存するアセンブリの変更にどれほど影響されるかを示すメトリクス。遠心性結合(Ce)と合計カップリング(Ca+Ce)の商で算出される。- 抽象性(A:Abstractness )
アセンブリの抽象型の割合を示す。- メインシーケンスからの距離(D)
不安定性と抽象性は、一種のバランスにある必要がある。私自身の言葉で説明すれば、このバランスは次のようなものである。抽象性の高いアセンブリは、他のアセンブリの入力アセンブリとして使用されることが多いため安定性が高い。もしもそのアセンブリが不安定であれば多くの場合、遅かれ早かれ変更の必要があり、その変更はこのアセンブリに依存するアセンブリ全体に波及する。一方、非常に具体的な(抽象性の低い)アセンブリは、依存図の端にあることが多く、そのため、それに依存するアセンブリはほとんどない。したがって、非常に不安定である。- 結合性の欠如Lack of cohesion (LCOM)
コヒーレントな(coherent)クラスでは、大部分のメソッドは、そのクラスのフィールドを処理する。クラスのメソッドの多くがフィールドのサブセットだけを処理している場合は、クラスの責任範囲が広すぎ、クラスを分割する必要があることを示している可能性がある。- 循環的複雑度(CC:Cyclomatic complexity )
このメトリクスはメソッドが持つパスの数を示す。メソッドの制御フローは各条件文、ループ、その他の文で分岐する。CCが高いメソッドほど維持が難しい。
Andre氏のチュートリアルは、ユーザがツールをまったく知らないという前提で、NDependの使用方法に関して一からあらゆる点を網羅している。Andre氏はNDependを用いて、ユーザを第一歩から始めさせる:
プロジェクトの作成は簡単で、次の2モードうちのいずれかで実行できる。:
Visual NDependは2つの操作モードをサポートしている。2つの違いは、プロジェクトファイルを明示的に作成するかどうかだけである。すぐに解析を行う場合は、単にメニュー「Select .NET assemblies」を選択する。これによって、明示的にプロジェクトファイルを作成することなく解析を実行できる。もう一つのオプションは明示的にプロジェクトを作成することで、解析を2回以上実行する必要がある(継続的なビルドなど)場合に推奨される方法である。
一度すべてのアセンブリが選択されたら、Run Analysis(解析を実行)を選択してプロセスを開始する。
Resultウィンドウが、NDependの本体である。チュートリアルに示されるように、様々なウィンドウによって、NDependが伝える内容の理解を促進している。以下の各ウィンドウは情報の重要な部分を示している。:
Andre氏はNDependのこの部分を使って、アセンブリのほとんどの情報をレポートすることを好む:
正直にいって、この機能は本当にすばらしい! NDependは多くのメトリクスを吐き出すが、ソースコードに関して必要な情報の大部分を集めることのできる強力なクエリ言語も提供している。
CQL (Code Query Language)はSQLに似たクエリ言語で、私たちの大部分がSQLに慣れているのでSQLは最もクールな言語である。CQLを使用するとメトリクスの大きな集合に問い合わせができる。このクエリ言語がいかに複雑であるかは、CQLの定義を一目見るだけで分かる(リンク)。
簡単なCQLクエリの例を示す:
1: SELECT TYPES WHERE NbFields > 6
CQLは、多くの開発者が毎日使用するT-SQLクエリに類似しているため、CQLの習得はとても簡単である。
プロジェクトアセンブリの解析結果とそれをHTMLに静的に保存することは、その時点でのプロジェクトの状態を知る非常に優れた方法である。チュートリアルでは、レポートに保存する重要なメトリクスを以下のように指摘している:
- 全般的な利用メトリクス
- コードの行数
- IL命令(IL instruction)数
- コメントのある行の数、コメントの割合
- アセンブリ、種類、インタフェース、構造体などの数
- パブリックタイプとパブリックメソッドなどの割合
- タイプごとのフィールド数、タイプごとのメソッド数などの平均。
- アセンブリごとのメトリクス
- LOC、IL命令数、...
- 結合メトリクス(Ca、Ce、関係結合性、不安定性、抽象性、不安定性-抽象性-バランス)
- アセンブリ依存性
- CQLクエリおよび制約結果
- 不成功の制約に対する警告
- メトリクスの種類
- LOC、IL命令数...
- 結合メトリクス(Ca、Ce、結合性の欠如...)
- 循環的複雑度
- 直接派生クラス数と間接派生クラス数、インスタンスツリーの深さ
- 依存性の種類(当初は利用できない)
- どの型がどの型に依存しているかを規定する
レポートには依存性ビュー(Visual NDepend のMetricsウィンドウと同様)、依存性図(Visual NDepend のMetricsウィンドウと同様、ただし64ビットをサポートしない)、および、抽象性と安定性のバランスを示すグラフも含まれている。
NDependの最適な利用方法については、Andre Loker氏のブログ(リンク)のチュートリアル全体を参照のこと。NDependの詳細については、NDependのWebサイト(リンク)を参照のこと。
原文はこちらです:http://www.infoq.com/news/2008/07/ndepend-tutorial
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信