Linda Rising氏による「誰を信頼しますか?」
Agile2008の3日目、8/6(水)午前中の、Linda Risingによるセッションです。セッションの冒頭、Linda Risingはとてもゆったりとしたきれいな、わかりやすい英語で話し始めました。
作者 Jonathan Allen, 翻訳者 編集部 投稿日 2008年6月9日 午前12時59分
スタイル強制は長年にわたり激しく議論されてきたテーマである。チームはどのようなスタイルを標準化すべきかの議論だけでなく、標準のスタイルは存在すべきかどうかの議論もある。事態をさらに悪化させるような動きとして、Microsoftが社内で使用しているスタイル強制ツール、StyleCopを公開した。
Microsoft Source Analysis for C#としても(source)知られるStyleCopは、FxCopと同等のソースコード分析ツールである。FxCopと同様にStyleCopはもともとMicrosoftの社内で使用されていたツールであり、それが他の人にも役立つとMicrosoftが見なすまでに成長した。しかしFxCopと違って、それほど高度に設定可能なものではない。
Source Analysisの究極の目標は、コードを見るチームメンバーやその他の人が高い可読性を見いだせるような、優雅で一貫したコードを生成できるようにすることです。これを達成するために、Source Analysisは、そのルールを高度に設定可能にすることを許しません。Source Analysisは、コードのスタイル、レイアウト、および可読性のルールに対しオールマイティなアプローチを取ります。最初は、すべてのルールに同意できず、一部のルールを煩わしいとさえ感じる場合があるということは大いにあり得ます! しかし、Microsoft社内でこのツールを使用しているチームの大半が、短い調整期間後、Source Analysisによって強制されるルールを有り難く思うようになり、このスタイルで記述されなかったコードが読みづらいとさえ感じるようになったことに気付きました。
Jason Allor氏は、このツールで強制される約200のルールがVisual Studioにあるデフォルト設定と互換性があるということを主張している。残念ながら、彼は、Visual Studioには6つのまったく異なるデフォルト設定の集合があり、その多くがこのツールと直接に矛盾していることをきちんと述べなかった。
ツールがカバーしている範囲は次のとおりである。
.これらのルールを空のコンソールアプリケーションに対して実行すると、9つのエラーが返される。「Keep Tabs」をオンにしている場合は16のエラーが返される。一部のルールは、「using」ディレクティブをファイルの先頭ではなく名前空間内にする必要があるなど、かなり厄介である。
すでに、ツールの修正サポートの不十分さについての不平不満がある。Dustin Norman氏は次のように書いている。
このツールをかなり小さいアセンブリで実行した者としては、561の違反をこのツールがコードのセマンティクスに影響を与えることなく自動で修正できたとき、それを手動で修正することを考えるとちょっと気が遠くなります。
タブvsスペースに関する長年の議論が再び高まっている。特定のルールを無効にできないことについても議論されている。Nick Berardi氏は次のように書いている。
冗談でしょ。「タブは許可されません。代わりにスペースを使用してください。」とは、恐ろしい考えです。なぜなら、ある変数が3つのスペースを使用して別の変数が4つのスペースを使用する場合、レイアウトのブロックを混乱させるからです。とにかく、こうしたタブのルールのように、一部の無意味なルールは無効にすることです。
こうした一部のルールを無効にできたら良いでしょうに。それが最善の選択であるとあなたが言ったのを私は知っています。しかし、私はスペースよりもタブという考えにまったく同意できません。その論理的な理由はまったくありません。Viが最初に発売されて以来、開発者の間で繰り広げられた聖戦は除きます。私はぜひ自身のソースコードでこれを実行したいと思いますが、タブを含むすべての行について警告されるため、失敗に終わるでしょう。
一方で、Daniel Stolt氏はVBについて尋ねている。
これは.NET開発者にとって利用可能なツールセットへの大変喜ばしい追加です。しかしなぜ、C#専用なのでしょうか? コードの書式設定ルールの強制は、VB開発者にも非常に必要とされています!
確かに、VBコードエディタには、キーワードや記号付近のインデントやスペースに関しては自動書式設定に対する基本的なサポートがあるが、StyleCopがサポートするものには近づきすらしません。
ところで、私はタブvsスペースについて「nberardi」 [Nick Berardi氏] に完全に同意します。タブに関する問題は何ですか? 所定の地点に達するために矢印キーを4、5倍多く押さなければならないことは利点ですか? ソースファイルに4、5倍多くの空白文字を格納しなければならないことは利点ですか?
少なくとも自動修正をサポートすることに何らかの関心があるようだが、タイムラインは与えられなかった。
原文はこちらです:http://www.infoq.com/news/2008/05/StyleCop
Agile2008の3日目、8/6(水)午前中の、Linda Risingによるセッションです。セッションの冒頭、Linda Risingはとてもゆったりとしたきれいな、わかりやすい英語で話し始めました。
Web2.0 に対する関心は、引き続き高いものがあります。 ただ、その関心は、新しいビジネス・モデルと、プログラミング・スタイルの二つの分野に集中しているように思えます。 今回のセミナーでは、Google のサービスの基礎である分散処理技術に注目します。
Jean Tabaka氏の書いた書籍では、会議などのチーム活動において、ファシリテーションの手法とツールについて具体的かつ実践的に説明しています。8/8(金)、Agile2008の最終日の朝のセッションでは、Jean Tabaka氏自身が本の内容をベースとしたセッションを行いました。
Agile2008の4日目となる8/6(木)の8:30から、Hubert Smits氏による「ゲーム・デザイン・ワークショップ」がおこなわれました。ゲームと言っても単なる遊びではなく、「フレームゲーム」と呼ばれる、グループでの情報収集や意志決定、また教育やトレーニングの教材として使えるいろいろなゲームです。
eBayが日々挑んでいる主要なアーキテクチャの勢力は、スケーラビリティです。これはアーキテクチャや設計に関するあらゆる意思決定を特徴づけたり、駆り立てたりします。
Bean Validationフレームワークの初期ドラフトに関する以前の記事に続き、InfoQは専門家グループが求めているコミュニティの関与と提案について理解を深めるため、Emmanuel Bernard氏と対談しました。
ポーカーは他のトピックにも広く適用できるような数少ない教えを私にもたらしてくれたと信じています。実際私はソフトウェアを開発すればするほど、これら二つの仕事は非常に似ていると言う確信の度合いを深めています。
恒例の「バーチャルパネルセッション」で、InfoQは新しいOASIS BPEL4People技術委員会の代表と対談をし、この作業が何故必要であるかについて彼らのフィードバックを得る機会を得ました。
No comments
返信