InfoQ ホームページ 品質 に関するすべてのコンテンツ
-
-
Googleの品質保証
以前はMicrosoftのアーキテクトを務め、現在はGoogleのテストエンジニアリングのディレクターであるJames Whittaker氏は“How to Break Software” シリーズで何冊かの著書がある。氏はGoogleがどのようにテストをしているかについて数回に渡って記事を書いた。Googleではテストは開発と共に行われ、テスターの数は比較的少ない。各製品は多くの人に触れられる前に一連のチャンネルで評価される。
-
-
Facebookはどのようにコードを出荷しているか
Facebookは今日おそらくも���ともホットな企業であり、大きな興味を駆り立て、詮索の対象となっている。高度なセキュリティに守られている中、SkypeのプロダクトマネージャYee Lee氏はFacebookでどのようにコードが出荷されているかの詳細を書いたメモの膨大なコレクションをまとめた。
-
-
Sonar 2.4: アーキテクチャ制約ルールとMaven 3のサポート
オープンソースのコード品質管理ツールである Sonar の最新バージョンは、アーキテクチャ制約ルールとカスタムなダッシュボードをサポートする。SonarSourceチームが最近、この製品のバージョン 2.4をリリースした。Maven 3のサポートとSonarプラグインをインストールし、アップグレードするアップデート センターも含まれている。
-
技術的負債の支払い方
技術的負債を顧客の価値と直接つなげるのは難しいことがあるが、顧客の価値を納品することは、そもそもアジャイルプロセスが何かということに関係している。では、アジャイル開発環境において、どうやって技術的負債を追跡して、減らすことができるだろうか?
-
どの色があなたのあなたのバックログ?
最近ウエリントンで開催されたソフトウエア開発に関する会議で、Philippe Kruchten教授は“どの色があなたのあなたのバックログ”と題した講演を行った。彼の講演の主眼点はシステムの機能実現とともに、アジャイルプロジェクトにおけるソフトウェアアーキテクチャ面からの重要性に焦点をあてることである。彼は4種類の作業の重要性を図示するために、色の例えを用いる。
-
Big Ball Of Mud（大きな泥だんご）は依然最も人気あるソフトウェア設計手法
Big Ball Of Mud（大きな泥だんご）は、でたらめに構築され、乱雑で無秩序、ダクトテープで繋ぎ合わされたようなコードのジャングルのことである。何年にもわたって、この泥を扱うための年月をかけて考えられた凝集性の高く結合度の低い種々のガイドライン、例えば SOLID、GRASP、KISS など、を紹介してきた。しかしながら、その状況は厳しく、Big Ball of Mud はいまだソフトウェアを設計し構築する最もポピュラーな方法のままである。
-
W3Cがウェブ検証ツールUnicornをリリース
W3CはUnicornをリリースした。 Unicornはウェブページの品質向上を手助けするワンストップのツールだ。UnicornはMarkup Validator、CSS Validator、mobileOk Checker、Feed Validatorの4つの人気ツールをひとつのインターフェイスに統合したツールだ。つまり、4つのウェブサイトを巡らなくても、ひとつのサイトを訪問すればウェブページの品質検証ができる。また、一度に4つの検証をすべて行うのか、4つのうちから必要なものを選んで個別に検証するのか選ぶこともできる。
-
レイヤ化アーキテクチャで、.NET技術を使った.NETとAzureのサンプルショーケース
マイクロソフトのコンサルタントであり、Microsoft pattern&practices Application Architecture Guideの寄稿者でもあるSerena Yeoh氏は、後にAzureに移植されたレイヤ化アーキテクチャデザインパターンのアーキテクチャ基盤として様々な.NET技術(WPF、WCF、WF、ASP.NET、EF)を使用した.NET 4.0向けのレイヤ化アーキテクチャサンプルを作成した。
-
アジャイルテストで挑戦
Gerald Ford 国際空港に、駐車料金計算機があり、 Matt Heusser氏は、それにひどいバグがあるのに気がついた。そこで彼は、世界中のテスターに、挑戦状を送った：ParcCalcに存在するバグを見つけて欲しい。それに答えたのは、James Bach氏、Selena Delesie氏など多数いた。
-
技術的負債を貨幣化する
ほとんどのアジャイルチームが，技術的負債(Techninal Dept) は悪いものである，という考えを持っている。金銭的な負債と同じように利子負担を伴なうからだ。技術的負債の利子はソフトウェアを維持・拡張するために要する余分な労力，という形で支払われる。アジャイル実践者たちの多くが技術的負債を可能な限り早く返済するよう勧めているが，それを定量的に把握するための貨幣化(monetize)を実現できているアジャイルチームは稀である。
-
一時的なコードと継続的に使うコード、そしてその間にあるすべてのコード
よくテストされリファクタリングされた長く使われるコードがある一方で、数日で捨てられることを前提にして書かれるコードもある。そしてこの両極の間に巨大なグレーゾーンが横たわっている。このグレーゾーンに属するコードはいつか削除されるという想定の元に書かれているが、決して消されることがない。
-
コメントを書くべきか書かざるべきか
開発者ならだれもが、自分のコードに最低一行はコメントを書いているはずだ。コメントをたくさん書いて、コードをもっとわかりやすくしようとする人もいる。この記事では、コードにコメントを書くときに使われるプラクティスを集めてみた。