BT

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

寄稿

Topics

地域を選ぶ

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

  • 経営陣によるアジャイル導入へのサポートの三本柱

    ひとたび自分達のチームに対してアジャイルが正当だと説明し、トレーニングにお金をかけると、経営陣の仕事は終わらない。移行を成功させるためには、経営陣が持続的なサポートをする必要がある。Esther Derby氏は少し時間を取り、この継続的なサポートの、3つの最も重要な側面であると彼女が考えていることを述べている。

  • 分散アジャイルプロジェクトの早い段階での終焉を確実にする方法?

    分散モードで作業している場合、アジャイルを導入して、実行するのがますます難しくなる。分散アジャイルは、地理的分離、異なる時間帯、文化の違いの観点から、独自の課題を突きつける。

  • 何がRESTを良くするか?

    先ごろRoy Fieldingは、SocialSiteのREST APIに対して、RESTfulではないと批判した。Royは、RESTだと主張するシステムが、多くの場合にRESTから程遠いことの例として、SocialSiteのREST APIを取り上げた。

  • コードカバレッジには要注意

    Christian Gruber氏はコードのカバレッジをメトリクスとして使うことに対するTDDのスタンスを、時間をかけて明確にしようとしている。

  • MSの経験から生まれた分散アジャイルですべきこととすべきではないこと

    Microsoftのpatterns & practicesグループの開発マネージャ、Ade Miller氏が分散アジャイル開発の記事を発表した。この記事で、分散アジャイル開発をしようする際の課題を明らかにしている。さらに、主としてMicrosoftのpatterns & practicesグループ内のチームの経験に基づき、これらの課題に取り組むための提案を行う。

  • Article: Rubyのオープンクラス:猿のようにパッチを当てない方法

    最近リリースされたRuby 1.8.7のプレビューリリースをウオッチしていたRails開発者はすぐに1.8.7プレビュー1に関してあることに気がつきました。それは、1.8.7プレビュー1がRailsを破壊してしまうということです。

  • Article: RESTアンチパターン

    本稿では、Stefan Tilkov氏が「RESTful」な設計であると主張するアプリケーションに見受けられる最も一般的なアンチパターンのいくつかについて説明し、それらを避けるための方法を提案しています。

  • Article: 改善、成功と失敗: 中国でのスクラム導入

    InfoQ Chinaは中国でスクラム(Scrum)がどのように導入されているかに関する調査を行いました。私たちはこの記事のために5つの事例をピックアップしました。これらの事例は、異なるさまざまな会社によるもので、異なるプロセスが利用され、異なる結果が生じたものです。

  • 議論: アーキテクチャの書き直しは避けるべきか?

    ソフトウェアを新しい需要や要件に適合させることが困難になるほど、アーキテクチャを更新するためにソフトウェアを再構築するという誘惑は強くなる。その取り組みはむしろリスクが高く、適切な戦略を採用することが不可欠である。

  • Interview: Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。

    JAOO '07 で「今時、ユニットテストを実施してないコードを納品するのは無責任な開発者だ」というBob Martin氏の主張について、議論が起こった。このInfoQビデオは、BobとJim Coplien氏がこれに関連する話や、いくつかの他の話題について議論する様子を納めたものだ。

  • 問題を抱えたプロジェクトの舵取り:まず酸素マスクを確保せよ

    Fiona Charles氏によるStickyMindsでの最近の記事は、問題を抱えたプロジェクトの舵取りについて触れている。「前進のための融通の利かないプロセスのための時間ではない」と強調し、プロジェクトを好転させるのに役立つ貴重な洞察を提供している。

  • 生産性第一主義によって余儀なく下された決断:原因、巻き添え、限界

    ソフトウェアプロジェクトにかかわる多数の決断は、生産性が第一に考慮される。プロジェクトが成功し、その市場が成長し、ドメイン知識とクライアントニーズの両方で複雑さが増している場合、特にその傾向が強くなる。適用範囲が予期せぬ転換になる可能性は高く、プロダクトにはカスタマイゼーションが益々必要になる。

  • 私は自信がない。あなたの聞いたことが、私が言ったと思っていることかどうか。

    コミュニケーションそれ自身は難しくも何ともない、と言わんばかりに、私たちの職場は専門用語であふれている - ビジネスドメイン用語、製品用語、開発者用語など。そのため私たちはそこにコミュニケーションがある、と言われても驚きはしない - しかし私たちは、目をぐるぐる回したりマーフィーの法則を引用したりする代わりに、それを捉え、対処することができているのだろうか?

  • 階層アーキテクチャは開発者と彼らが作るソフトウェアの間にギャップを生むか?

    今日のソフトウェアコミュニティにおける努��の多くは、ソフトウェア開発のプロとビジネスピープルとの間のギャップを解消するための橋渡しを目標としているが、一部のブロガーは問題をすこし異なった視点から見ており、開発者と彼らが作るソフトウェアとの間のギャップを強調している。

  • Active Recordパターンを使用中の柔軟性の保持

    Rails、Hibernate、他のORMツールに使用されているActive Recordパターンはdatabase rowのオブジェクトへのマッピングを許容するデータ持続パターンである。しかしながらこの実用的なツールはBob Martin氏によると混乱の源であるそうだ。 柔軟性を保つにはBob Martin氏はActive Recordをアプリケーションから分離させることを提案しており、そうすることによって後者はオブジェクトの周りで単一でデザイン、また構成することができるのである。

BT