BT

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

寄稿

Topics

地域を選ぶ

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

  • DRY原則の利用: コードの重複と密結合の間

    DRYは重複とそれに伴うメンテナンスの問題を軽減するものだが、誤用すると密結合を生み、可読性を損うおそれがある。教訓:ソフトウェア開発原則は、ほかの原則やパターン、プラクティスを考慮して適用しなくてはならない。

  • 個人の生産性

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

  • 優れたコードだけでプロジェクトは成功するか

    開発者であり、アーキテクトであり、著書も持つSimon Brown氏はプロジェクトを成功させるには良いコード以上のものが必要だと考える。良いコードだけでは不十分と題したプレゼンで氏はプロジェクトの成功に必要なすべての要素について、事前の設計から運用尾のための文書まで、くまなく論じた。

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

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

  • 言語の制約に頼るべきか?開発者の責任に頼るべきか?

    Bruce Eckel氏、Michael Feathers氏、Niclas Nilsson氏、Keith Braithwaite氏などが次の問いに答える。プログラミング言語は、完全な柔軟性をもって開発者が好きなようにいじり回せて、開発者が自分でやったことには責任をもつと信じるべきなのか?それとも悪いコードやメンテナンス性や可読性をさげてしまうような失敗を避けるために、設計時に言語の中に明確な制約を設けるべきなのか?

  • ベロシティは何のため?

    最近、ScrumDevelopment Yahoo!グループでは、ベロシティの活用と誤用に関して様々な議論がなされている。ベロシティを生産性の基準として使うべきだろうか?イテレーション計画のために使うべきだろうか?もっと長期のリリース計画にはどうだろうか?

  • ソフトウェア職人マニフェスト:出撃命令

    Pete McBreen氏は2001年に『Software Craftsmanship:The New Imperative』を書いた。昨年、Bob Martinおじさんは『Clean Code: A Handbook of Agile Software Craftsmanship』を書いた。そして彼はAgile2008の基調講演の中で、アジャイルマニフェストに「クズなコードを書かずにソフトウェア 職人気質を持つこと」を追加して修正することを提案した。

  • ReSharper 4.5 ベータはパフォーマンス向上を保証する

    先日 JetBrains は ReShaper 4.5 ベータをリリースした。この新バージョンはパフォーマンスの向上とメモリの消費量の削減を保証している。新機能として VB9 のサポート、ネイティブな MSTest のサポート、「実装に移動」機能、そして F#、Compact Framework および Silverlight との互換性の改善が含まれる。

  • Article: スケーラビリティの構築とパフォーマンスの達成:バーチャルパネル

    InfoQ.com向けのこのバーチャルパネルでは、大企業やプロジェクトからスケーラビリティやパフォーマンスの著名人を招待し、みんなが夢に描いているような結果を達成するための秘密を明かしてもらいました。

  • チームで新しい習慣を身につける報酬は?

    チームが新しい習慣を身に着けようとして、なかなかうまくいかないときがある。習慣とは、ユニットテストを書く、コンパイラの警告をなくす、ビルドを壊さない、などのことだ。どうしたら、チームにこうした習慣を植え付けることができるだろうか?Clint Shankはメンバーを移行させるために、あるゲームをデザインした。

  • JetBrainsがReSharper 4.0をリリース、C# 3.0のサポートのほか多くの機能改善

    JetBrainsは、大変待ち望まれたツールであるVisual Studioアドイン、ReSharper 4.0をリリースした。Resharper 4.0には機能の改善や新機能が多数ある。

  • StyleCop – MicrosoftのC#用スタイル強制ツール

    スタイル強制は長年にわたり激しく議論されてきたテーマである。チームはどのようなスタイルを標準化すべきかの議論だけでなく、標準のスタイルは存在すべきかどうかの議論もある。事態をさらに悪化させるような動きとして、Microsoftが社内で使用しているスタイル強制ツール、StyleCopを公開した。

  • Review Board - コードレビューをオンラインで

    コードレビューは品質を高め、情報共有とメンターシップの優れた方法となる。 残念なことにこれまではサポートツールの準備に手間がかかったりそもそも準備されなかったせいでコードレビューは後回しにされることが多かった。Review Boardはコードレビューのプロセスをサポートするアプリケーションによってこの状況を変えようとしている。このアプリケーションのいくつかの機能をあげよう。

  • オピニオン: スタイルを強制するのはプログラミング言語ではなくチームであるべき

    大規模なマニュアルにはプログラミングに関する問題を解決するために従うべきシンプルなルールが必ず書かれていると信じている人たちがいる。これはウォーターフォール型の開発手法ではよくある考え方だろう。XP だと、安全な構造とクリーンなスタイルを開発者に強制するプログラミング言語を求める人がいる。Reg Braithwaite 氏はこの信念を批判している。

BT