BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Delivering Quality に関するすべてのコンテンツ

  • アジャイルで開発速度を上げるには

    企業がソフトウェア開発へのアジャイル導入を望む理由として挙げられるのが,提供までの期間の短縮だ。開発速度を向上するためには,アジャイルをどのように使えばいいのだろうか?

  • 組み込みシステムのソフトウエアに対するテストの重要性

    Chip Design Magazine誌は記事で、組み込みシステムに搭載されているソフトウエアと連携した携帯無線システムの普及により、新しい課題が生まれていると指摘している。それは、とりわけセーフティクリティカルシステムにおいて、品質に特別な注意を払う必要があるということだ。同誌が指摘するように、テストツールが今後ますます重要になるだろう

  • ソフトウェア品質入門

    Chappell & Associatesの代表であるDavid Chappell氏は、最近発表した2つのホワイトペーパーにおいて、ソフトウェア品質のさまざまな側面(機能的、構造的、プロセス的)と、品質に直接関心のあるグループ(ユーザ、開発者、スポンサー)、外部向けもしくは内部向けソフトウェアが時間とともに直面する欠陥の結果について説明している。

  • 個人の生産性

    Tony Wong氏(プロジェクトマネジメントのブラックベルト)は個人の生産性にとって実践的なポイントをいくつか挙げている。この記事では、これらをいかにソフトウェア開発に適用するかを考え、彼のリストと他のリストを比べる。

  • 応用心理学はソフトウェア技術者に役立つか

    11月1日,ソフトウェア技術者で著作者である John R. Fox 氏が "アナログ世界におけるデジタルワーク (Digital Work in an Analog World)" という著書を出版した。副題の "応用心理学によるソフトウェア工学改善" が示すようにこの書籍は,実はソフトウェア工学を考察したものではない。本書が注目しているのはむしろ,技術者の心理学的側面や実務に関連する部分なのだ。

  • Facebookはどのようにコードを出荷しているか

    Facebookは今日おそらくもっともホットな企業であり、大きな興味を駆り立て、詮索の対象となっている。高度なセキュリティに守られている中、SkypeのプロダクトマネージャYee Lee氏はFacebookでどのようにコードが出荷されているかの詳細を書いたメモの膨大なコレクションをまとめた。

  • バグを残さずにストーリーを完成させるには

    受け入れられないほど多くのストーリーが"完���"になっているにも関わらず、品質に多くの問題がある場合、どうしたらいいだろうか。

  • 技術的負債の支払い方

    技術的負債を顧客の価値と直接つなげるのは難しいことがあるが、顧客の価値を納品することは、そもそもアジャイルプロセスが何かということに関係している。では、アジャイル開発環境において、どうやって技術的負債を追跡して、減らすことができるだろうか?

  • 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つのうちから必要なものを選んで個別に検証するのか選ぶこともできる。

  • アジャイルテストで挑戦

    Gerald Ford 国際空港に、駐車料金計算機があり、 Matt Heusser氏は、それにひどいバグがあるのに気がついた。そこで彼は、世界中のテスターに、挑戦状を送った:ParcCalcに存在するバグを見つけて欲しい。それに答えたのは、James Bach氏、Selena Delesie氏など多数いた。

  • 技術的負債を貨幣化する

    ほとんどのアジャイルチームが,技術的負債(Techninal Dept) は悪いものである,という考えを持っている。金銭的な負債と同じように利子負担を伴なうからだ。技術的負債の利子はソフトウェアを維持・拡張するために要する余分な労力,という形で支払われる。アジャイル実践者たちの多くが技術的負債を可能な限り早く返済するよう勧めているが,それを定量的に把握するための貨幣化(monetize)を実現できているアジャイルチームは稀である。

  • 一時的なコードと継続的に使うコード、そしてその間にあるすべてのコード

    よくテストされリファクタリングされた長く使われるコードがある一方で、数日で捨てられることを前提にして書かれるコードもある。そしてこの両極の間に巨大なグレーゾーンが横たわっている。このグレーゾーンに属するコードはいつか削除されるという想定の元に書かれているが、決して消されることがない。

  • コメントを書くべきか書かざるべきか

    開発者ならだれもが、自分のコードに最低一行はコメントを書いているはずだ。コメントをたくさん書いて、コードをもっとわかりやすくしようとする人もいる。この記事では、コードにコメントを書くときに使われるプラクティスを集めてみた。

  • 継続的デプロイのプラクティス

    継続的デプロイは、リーン開発の"仕掛排除"運動で最近注目されている。多くの人が、これについて興味を持ち、価値のある目標を見出している一方、これが実際どのように達成されたかをなかなか可視化できていない。Ash Maurya氏は会社で起こった自身の経験を説明することで、このギャップを埋めようとしている。

BT