コード品質の向上(その2) ~ Visual Studio 2012 ソリューションシナリオ

<< ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   このソリューションシナリオでは、「コード品質の向上 ~その1~」の後編として、ソースコードの品質を向上し、よりメンテナンス性の高いコードを書くための Visual Studio 2012 の支援機能を紹介します。     プラクティス3:冗長なコードはリファクタリングによりシンプルなコードにしよう。 Visual Studio 2012 では、「コードクローン分析(コード複製分析)」機能により、プロジェクトにおいて点在している「似た」コードを素早く特定します。これにより、リファクタリング対象となるコードを効率的に見つけることが可能です。 例えば下記は前述した C# のReversi アプリケーションにおいてコード複製の分析を行った結果です。 この中で「弱い一致」を示すコードが2か所発見されており、そのうちの一つに関してコードの内容を比較したところ、該当箇所約30行のうち、色がついていない7行については全く一致しており、またその前後にある何行かのコード(赤色、もしくは緑色の強調がされている行)においても若干の違いがあるものの、類似のコードとなっている、という分析結果が示されています。 このようなコードに対して、ロジック的に問題がないか確認を取りながら、リファクタリング可能なコードはメソッドとして抽出し共通化する、といった作業を行うことで、コードをよりシンプルに保つことが可能になります。   また、異なるアプローチとして、選択したコードに関して同様のコードがないかを確認する、といった使用も可能です。   あるコードを修正しようという際に、似たようなコードがソリューション内に存在しないかどうかを事前に確認することで、同様の修正を行う必要がないかどうか、あるいはそれらの箇所をまとめてリファクタリングし、シンプルなコードにできないかを検討することが可能になります。       プラクティス4:実行時のパフォーマンスの観点からもコードのチェックをしよう。 Visual Studio 2012 においては、ユーザーが行うであろう操作シナリオに基づいて実際にアプリケーションの操作を行い、その際の関数(メソッド)呼び出しの関連性や、各関数にて使用しているCPU、メモリリソースの測定を行うことが可能です。   例えば、下記は 「Huo Chess」 というコードに対してパフォーマンス分析を行った結果です。 関数の呼びたし回数に関する詳細なデータを取得する “インストルメンテーション” によって、アプリケーション実行時に実際に呼び出された関数のデータを取得し、また CPU の使用率をグラフとして表示しています。     パフォーマンスチューニングを行う際には、開発者がこれまでの経験や知識などを頼りにチューニングを進める方法もありますが、実際にチューニングを行うべき箇所(パフォーマンス上のボトルネックとなっている箇所)を明確に見つけ出すことは容易ではありません。…

0

コード品質の向上(その1)~ Visual Studio 2012 ソリューションシナリオ

<<クロスポスト:この Blog は、「Visual Studio 日本チーム Blog」へ投降した「コード品質の向上(その1)~ Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>> << ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   開発プロジェクトにおける最大の成果物は “動くソフトウェア” であり、またその “ソースコード” でもあります。 一方で全く同じように “動くソフトウェア” であったとしても、「ユーザーからのフィードバックを受け、継続的に価値を提供し続けていく」という視点で考えた際に、メンテナンスが容易な “ソースコード” と、冗長なコードが多かったり、メソッド名がわかりづらい “ソースコード” では、ソフトウェアのライフサイクルを勘案した時に前者のほうがより価値があるのは明らかです。 今回のソリューションシナリオでは、「コード品質の向上 ~その1~」と題して、ソースコードの品質を向上し、よりメンテナンス性の高いコードを書くための Visual Studio 2012 の支援機能を紹介します。   開発チームにおいてコードのメンテナス性に関する取り組み姿勢や基準を共有しないままプロジェクトを進めてしまうと、以下のような問題が発生します。 チームメンバーそれぞれが勝手な命名規則や、独自のコーディングルールに基づいてコードを書いてしまい、プロジェクト全体としてのまとまりがなくなってしまう。また、そのためにコードの可読性が大幅に落ちてしまう。   メンバーによって「メンテナンス性」、に対する意識が異なるために、チーム全体としての基準があいまいになってしまう。またプロジェクトが進むにつれ、どうしても「甘い」基準に引きずられてしまう。   場当たり的なコーディングにより、コピー&ペースト等で似たようなコードが散在してしまい、問題が発生した際に修正個所が複数個所にまたがってしまう。   開発プロジェクトにおいてはアプリケーションのライフサイクルの観点から長期的な視野に立ち、メンテナンス性もソフトウェアの品質の一部であるととらえ、コードの品質を向上させることが重要になります。   コードのメンテナンス性、品質に関する課題に対し、以下のようなプラクティスを推進することで、コードの品質の向上への取り組みを進めることが可能です。   コーディング規則やコーディングのプラクティスを活用しよう チームで開発を行う場合、それぞれの開発者が自分の基準で命名を行ったり、コードの見た目を変更したりすると、コード全体としての統一性がかけてしまい、保守性が犠牲になってしまいます。コードの共同所有を進め、チーム全員でコードのメンテナンスがスムーズに行えるよう、標準的なコーティング規則を定めておきましょう。 また、過去の経験から得られた知識や守るべきガイドラインをまとめておき、共有することでチーム全体でのコード品質に対する意識やナレッジを高めましょう。 例えば、MSDN…

0

手動テストの品質向上~Visual Studio 2012 ソリューションシナリオ

<<クロスポスト:この Blog は、「Visual Studio 日本チーム Blog」へ投降した「手動テストの品質向上~Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>> << ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   開発プロジェクトにおける手動テストは、開発者が行う単体テストや結合テストと異なり、ユーザーの代弁者としてアプリケーションに対する操作を通じて品質検証を行う活動です。従ってアプリケーションに対しては技術的な視点よりも、ビジネス的な視点に立って検証を進める必要があります。   このソリューションシナリオでは、手動テストの実施に当たって、どのようなことを考慮することで手動テスト自体の品質向上を図っていくことができるのか、またその中で Visual Studio 2012 のどのような機能を活用できるのかを紹介します。   開発の現場において手動テストを実施する際には、経験豊富なテスト担当者によって用意されたテストドキュメントをもとに、担当者が実際にアプリケーションを操作しながらアプリケーションの検証を進める、といったスタイルがとられることが多いのではないでしょうか? この過程においては、以下のような課題が発生しがちです。   経験豊富なテスト担当者に依存しがちになり、他のメンバーにとって十分なドキュメントが用意されていなかったり、品質基準の定義があいまいなままテストが進んでしまう。   手動テスト(特に探索的テスト)においてバグに遭遇した場合に、再現性のあるシナリオの特定に手間がかかってしまう。   手動テストによってアプリケーションのどれだけの割合がテストできたのかが把握しづらい。   いくつかの条件の組み合わせが必要なテストシナリオの場合、アプリケーションの操作が長くなってしまい、テスト途中における操作の抜けや誤りによって、再度テストを初期状態からやり直す必要がある。   同様の場合に、操作の誤りに気づかないままテストを続けてしまい、間違ってアプリケーションのバグを報告してしまう。あるいは、アプリケーションのバグに気づかずにアプリケーションをリリースしてしまう。   自動化が行いやすい単体テストや負荷テストと異なり、手動テストは人による関与が大きいため、設定したテストシナリオによってアプリケーションの品質が十分に検証できるのか、テストにおけるアプリケーションの操作自体に誤りがないのか、等の基準があいまいなまま、担当者の経験に依存して実施されることが多くあります。   このような問題を解決し、手動テストの品質を向上するには、以下のようなプラクティス(行動)の実践が挙げられます。   手動テストの実施環境を整えよう 手動テストにおいては、特別な実施環境を用意することなく、テストシナリオが書かれたドキュメント(多くの場合は Excel や Word に書かれた操作手順)と、アプリケーションを使用するであろう一般的なユーザーと同様のPC環境でテストを実施することがほとんどです。 しかし、テストにおけるアプリケーション操作の間違いを最小化し、またバグ(あるいはその可能性)を発見した際に、再現性のあるシナリオ特定をスムーズに進めるためにも、テスト担当者に対する支援環境を用意し、テストメンバー全員が同じ手順で、同じ品質基準をもとにテストを実施できる環境を用意すべきなのです。 手動テストの実施環境としては、(1) アプリケーション操作を間違わないためにもわかりやすくシナリオ(操作手順)を伝える環境、(2) テスト実施時の操作やアプリケーションのふるまいを効率的にまとめることのできる環境、(3)…

0

チーム開発における単体テストの実践~Visual Studio 2012 ソリューションシナリオ

<<クロスポスト:この Blog は、「Visual Studio 日本チーム Blog」へ投降した「チーム開発における単体テストの実践~Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>>   << ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>> ソフトウェア開発において、「開発者テスト」とも位置づけられる「単体テスト(Unit Test)」は、Java における JUnit、.NET 開発における NUnit、また Visual Studio 2005 から提供されている Microsoft Test、といった様々な Unit Testing Framework の登場により、開発現場において広く受け入れられるようになってきました。 また一方で、Test Driven Developmenr (TDD)に代表される方法論の浸透により、単体テストは単なる「テスト」という位置づけではなく、「設計」ツールの一部としても活用されるようになりました。   通常のコードに加えてテストを書く必要のある単体テストの実践は、一見すると、書くべきコードが増え、生産性および保守性の両面でマイナスの影響を与えるように思われがちですが、実際には洗練された設計とコード変更に対する自信をもたらし、開発者に多くのポジティブな影響をもたらしています。     このソリューションシナリオでは、チーム開発における単体テスト実践の際にどのようなプラクティスがあり、また Visual Studio 2012 の機能をどのように活用できるのかを紹介します。   単体テストは手軽にできるテストである反面、チーム開発においては以下のような課題が発生しがちです。       チーム開発においてはメンバー間でのテストに対する「レベル感」の違いがあり、テストの抜け、漏れが起こったり、あるいは必要以上のテストを用意してしまい余計な工数を消費してしまう。   現場においては、新規のコードに新規のテストを書く、というだけでなく、既存のコードに対する単体テストのニーズや、異なる…

0

受け入れテストのリスクコントロール~Visual Studio 2012 ソリューションシナリオ

<<クロスポスト:この Blog は、「Visual Studio 日本チーム Blog」へ投降した「受け入れテストのリスクコントロール~Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>>   << ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   ソフトウェア開発において、受け入れテストがなぜ重要なのでしょうか?   受け入れテスト、は開発チームが実施してきた開発プロセス~要求定義、開発、そしてテスト~の最後の活動として、ユーザーによって実施される活動です。受け入れテストが完了することにより、開発チームの努力が具体的なものとして認められ、そしてその価値をユーザーに届けることができる、重要な区切りとなるのです。   このソリューション シナリオでは、受け入れテストにおけるリスクコントロールのためにどのようなプラクティスがあり、Visual Studio 2012 がどのようにその実践を支援するのかを紹介します。   受け入れテストにおけるビジネス上の課題、リスクにはどのようなことがあるのでしょうか? 例えば、以下のようなことが起こりがちです。   要求で明示されていない事柄に対する期待値と実現内容のギャップが存在する(例:表形式の一覧情報の表示画面において、任意の項目をキーにしたソートができない、等必要な機能が実装されていない)   要求と実際の開発のギャップに開発後期で気づくため、スケジュール的に後戻りできず、また責任の所在もあいまいなまま不十分なソフトウェアを受け入れてしまう。   これらの原因の一つは「あいまいな要求」によって引き起こされます。   「ソフトウェア開発」は、ユーザーと開発チームの共同作業であり、その認識を如何にすり合わせることができるか、が成功のカギを握っています。 「あいまいな要求」をそのまま放置し、お互いに「行間を読む」ことで、自身に都合のよい内容を「期待」しつつ、ギャップを埋める努力をせずに開発を進めていると、受け入れテスト間際や、あるいは受け入れテストのその瞬間に、ギャップが顕在化し、問題になってしまうのです。   このような問題を解決し、受け入れテストにおけるリスクをコントロールするための本質的な方法は、ユーザーと開発チーム(および、関連するその他の関係者)の認識を早期からすり合わせ、ギャップの顕在化を早めに行うことです。 これを実現するための代表的なプラクティス(行動)として、以下のような項目が挙げられます。   早期から、頻繁にユーザーを巻き込み、要求の定義と検証を段階的に行おう。 「あいまいな要求」への対策としてはいくつかの方法が考えられますが、「ユーザーを巻き込む」というのが最も本質的で、かつ効果的な対策といえるでしょう。 もし、「顧客があまりに多忙で、そもそもこのソフトウェアを「なぜ作らねばならないのか」といったプロジェクトの本質を説明する時間すらさけぬだと知ったら、本来そんなソフトウェアは作られるべきではない」のです(※)。まずは、開発の予算だけでなく、プロジェクトに関わろうとするコミットをユーザーから得ましょう。そして、要求定義を一度だけ行うのではなく、プロジェクトのチェックポイントを設定し、段階的に要求の定義と検証を行うようにしましょう(アジャイルプロジェクトであればイテレーションやデリバリーごとに。ウォーターフォール型であっても各フェーズ毎に見直すことは可能です)。 ※ 「アジャイルサムライ ― 達人開発者への道」 ISBN978-4-274-06856-0 P.70…

0

日本マイクロソフト 大手町オフィスにおける開発者向けセミナーのご紹介

  今回は、日本マイクロソフトの大手町オフィスにおけるセミナーのご紹介です。   ご存知の方もいらっしゃるかとはおもいますが、日本マイクロソフトでは、2年前に東京都内にて分散していたオフィスを集約し、品川オフィスへの移転を行いました。   そんな中、開発拠点でもある調布オフィスとともに、品川に統合されずに残ったのが、大手町のオフィス、通称「大手町テクノロジーセンター」(OTC)です。   この大手町オフィスには、マイクロソフト イノベーション センター(MIC) があり、検証用のデータセンター施設や、トレーニング用の施設などが完備されています。         ということで、今回のエントリの本題なのですが、この MIC においては開発者の皆様のスキルアップを目的に、セミナーやハンズオンラボが開催されています(前置きが長くなったのは、品川オフィスと間違えられるといけないので、大手町を強調したかったためです 🙂 )。   今月&来月の開催では、C# の入門コースや、LINQ プログラミングのコース、XAMLプログラミング(基礎編と応用編)といった開発者としての基礎体力作りに役立ちそうなコースをはじめ、Windows 8 アプリケーション開発のためのコース(UI編と機能編)、あるいは Kinect for Windows のコースなど、豊富なメニューで展開しています。   一部半日のコースもありますが、ほとんどが1日のコースで、しかも無償で参加いただけるセミナーですので、開催内容と日程がマッチするようであれば、ぜひ参加ください!!     <<スキルアップ カリキュラムのページ>>     それでは!

0

見せてもらおうか、占有インスタンスの性能というものを!! ~ クラウドアプリもロードテスト♪

本 Blog は “Visual Studio Advent Calendar 2012” の8日目の記事として、知られているような気もするけど、使われていない気もしている Visual Studio のロードテスト機能を紹介する記事です。   ということで、さっそくはじめましょう(意外と長くなっちゃた)。   ■■■ お品書き ■■■ (1) Web を最速で立ち上げる “Windows Azure Web サイト” (2) Visual Studio におけるロードテストの手順概要 (3) Web パフォーマンステストの作成とカスタマイズ (4) 複数シナリオの用意 (5) ロードテストの実施 (6) Windows Azure Web サイトのスケールの調整 (7) ロードテスト機能の利用権に関して     ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ (1) Web を最速で立ち上げる “Windows Azure Web サイト”   さて、タイトルに…

1

Azure、ASP.NET、C#、F#、ALM、Visual Studio、そしてさらに。あすから Advent Calendar はじまります♪

  今年があと1カ月で終わりだなんて、信じたくないっ!     と叫びたいところですが、いよいよ明日から12月。 マイクロソフトの開発者コミュニティの皆様が、年のしめくくりにと各種 Advent Calendar を企画されています。   読むのはもちろん、書くほうとしてもぜひ参加くだいませー♪   ◆ Windows Azure Advent Calendar jp: 2012 ~サンタさん日本にデータセンターをください   ◆ One ASP.NET Advent Calendar 2012 ~ ASP.NETに関するネタはなんでもOK!   ◆ Visual Basic Advent ~ Visual Basicが絡めば.NETでもVBでもOfficeでもOK!   ◆ C# Advent Calendar 2012 ~昨年に引き続き C# アドベントカレンダーでございます。   ◆ F# Advent Calendar 2012   ◆ ALM Advent…

0

Visual Studio 2012 の Update 1 がご利用いただけるようになりました。

※ 本 Blog ポストは、Microsoft において開発ツール製品(Visual Studio / .NET Framework)の開発チームをリードする Somasegar (ソマセガー)の Blog ポスト 「Visual Studio 2012 Update 1 Now Available!」 を簡易翻訳したものです。     “最初に”、非常に興奮しています。 この興奮は、他者との競争によって感じているものではありません。この興奮は、むしろ、自身とのあるいは過去の自分たちとの競争によるものだ、といってよいでしょう。そして、我々がなしえてきた事、あるいはなしえてきた方法についてそれらを日々改善し、さらに良いものと届けようとしてきた事、また、我々が提供する開発ツールを使っていただいている開発者の方々や開発チームの皆様に対して提供することのできる価値に対して興奮しているのです。   9月に行われた Visual Studio 2012 と .NET Framework 4.5 のローンチイベントにおいて、私は継続的に価値を届けること(Continuous Value Delivery)に対して固い約束をし、またより短い期間で Visual Studio のアップデートを提供する新しいアプローチについてお話をさせていただきました。         そして、お約束したアップデートの最初のリリースとなる Visual Studio 2012 Update 1 が本日からご利用いただけることになったことをお知らせできることに興奮しています。   Visual Studio 2012…

0

【イベント】 Developer Camp 2012 Japan Fall ~ クラウド時代のアプリ開発者に贈る一歩進んだ開発スタイル ~

  来る10月4日(木)、5日(金)、渋谷ヒカリエにて、開発者向けイベント Developer Camp 2012 Japan Fall が開催されることとなりました。   このイベントでは、Windows Azure のアプリケーション開発チームのトップ Scott Guthrie (スコット ガスリー)をキーノートスピーカーとして、怒涛の進化を続けるクラウドプラットフォームの Windows Azure と、最新の開発ツールである Visual Studio 2012 の情報を2日間にわたってお伝えします。   現在申し込みを受け付け中ですが、定員(600名)がありますので、ご興味のある方はお早目の登録をお勧めいたします♪   それでは!

0