Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Pugh教授が開発したFindBugsは静的解析をおこないJavaコード中のよくある欠陥を見つけ出すオープンソース(LPGLライセンス)ツールだ。Microsystemsのような有名企業、そして氏が客員研究者となっているGoogleをはじめ多くの企業で利用されている。CheckstyleやPMDのようなより広範なスタイルベースの提案方式でコード品質を改善しようとするツールとの一番の違いが、欠陥を見つけることに注力している点だ。FindBugsの解析エンジンもまたCheckstyleやPMDとは違い、ソースコードというよりはクラスファイルを直接扱う。GUIあるいはEclipseやNetBeansのプラグインからおこなうこともできる。出力はXMLあるいはテキストにできる。FindBugsの解析エンジンは現在約300のパターンをテストすることができる。そのために利用される検出法は概して分かりやすく、またプラグイン形式を採用していることで、ユーザが独自の検出法を追加できるようにもなっている。PMDがしているようなパターン言語によってバグを記述するやり方ではなく、Javaによって書く方法を採っている。ディベロッパたちは静的解析ツールをさまざまな方法で利用しているが、典型的な2つの方法は、新しく書かれたモジュールのコードレビューに属するものと、既存のコードベースに対するより広範なレビューに属するものだ。これら2つの方法はまったく異なる要件をもっている。前者ではツールが見つけた疑わしいコードは、たとえそれがアプリケーションの挙動に関わらなくてもディベロッパがレビューをおこない修正する。それとは対照的に、既存のコードベースをレビューする方法では、製品になにか明白な問題が起きているわけでもなく、またディベロッパがそのコードについてよく知っておく必要があるため、コード変更をおこなう敷居が高い。FindBugsの解析エンジンはどんどん改善がされていっており、バージョン1.3.9のリリースでは12の新しい検出法が追加されたが、1.3.9から以降で重要視されているのは後者の方法だ。FindBugsではこれまで各バグパターンを正常性、バッドプラクティス、パフォーマンス、国際化のカテゴリにグループ分けしていた。各グループは優先度の高低を設定できた。これは大規模なコードベースからあまり重大でない欠陥を選り分けたいディベロッパにとっては便利であり、実際そういう利用法が広くおこなわれている。1.3.9のリリースでは、このコンセプトが拡張され、バグランキング(1から20)とこのランキングによるフィルタリングの機能が追加された。年内にリリースされる2.0では独自のバグランキングが設定できるようになる予定だ。2.0で予定されている主要機能のひとつはコミュニティレビューで、これはオープンソースプロジェクトの問題をレビューできるようにし(たとえば問題を"修正必須"や"危険度小"のようにマークする)、そしてそのレビューを保存して自動的に他のレビュアーと共有できるようにするものだ。1.5以降)で利用できるようになる。この機能はGoogleのバグ潰し大会でも用いられた。FindBugsのホームページにはこう書かれている。5月13日から14日にかけてGoogleが開催したグローバル大会で、コーディングの誤りを見つけるJava解析ツールであるメリーランド大学のFindBugsが対象になりました。この大会の目的は、Googleで使われているFindBugsによって見つかった4000の問題についてフィードバックを得て、Googleのエンジニアがどれを修正すべきか決めるようにするものでした。多くの場所で700名以上のエンジニアがFindBugsを実行しました。そのうち250名以上が8000以上の問題のレビューを入力しました。バグ以外などのカテゴリに分けられます。75%以上のレビューが修正必須か要修正か修正予定に分類されました。危険な部類の問題の多くには10以上のレビューが付きましたエンジニアはこれまでに3800の問題のうちの1100を解決する変更を既におこなっています。1700以上のバグレポートもアップされ、そのうち600が既に修正されています。この大会によって提起された問題を解決する作業は続いており、FindBugsがGoogleのソフトウェア開発に組み込まれる見通しとなっています。この大会はFindBugsにクラウドコンピューティングやソーシャルネットワーキングを支える性能があることを示しました。問題のレビューは他のディベロッパも見ることが出来る場所にただちに永続化されます。Googleではバグレポートをアップしたり閲覧するためのツールやソースファイルのバージョンコントロールをおこなうツールとFindBugsが連携するようになっています。この大会では自分がレビューを入力しないと他のエンジニアからのレビューも見れないようにFindBugsのモードが設定されましたが、今後はレビューを入れなくても他のエンジニアからのレビューが見られるようなオープンな設定に変更がされる予定です。静的解析ツールは万能薬ではない。設計やコードレビュー、テストといった他の手法の方が重要かもしれない。正しく使うことでディベロッパ各人やプロジェクトにとって有益なものになるのだ。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。