自動Javaコード品質チェック（反復1）

このシリーズの記事は、プロジェクトで自動コード品質チェックがどのように構成されているかに関するいくつかのパートのストーリーとして計画しています。 このプロセスは、一見単純に見えますが、明らかではない詳細に満ちていることが判明したため、差し迫った困難とその解決策を幅広い聴衆に明らかにし、誰もがレーキをバイパスしてコードを少し改善できるようにしたいという要望がありました。



その結果、ビルドサーバーで検査、スタイルチェック、およびメトリック計算が追跡され、プロジェクトの内容が全員に理解されるようにする必要があります。 さらに、理想的には、サーバー上で機能するすべてのチェックはIDEでも機能する必要があります。これにより、チーム全体がそれらについて知る前に、コードに関するコメントを削除できます。 アプローチが改善されると、反復が追加されて公開されます。



この反復では、検査チェックを構成します。 JetBrainsの IntelliJ IDEAとTeamCityをチームとして使用しているため、それらが提供するツールを使用できます。 まず、IntelliJ IDEAは検査プロファイルを設定します。検査プロファイルは、TeamCityを使用して各アセンブリ中にコードのコンプライアンスがチェックされます。 これは通常の方法であり、TeamCityの公式ナレッジベースに記載されていますが、すべてが非常にスムーズになったわけではありません...



まず、何を確認するかを決定し、これを行うには、IntelliJ IDEAを起動し、プロジェクトを開いて設定を見つけます。 次に、検索を使用するのに便利な検査セクションに移動します。 その結果、このような画像が表示されます-グループに分けられた検査の完全なリスト（青で、設定が標準のものと異なる検査が強調表示されています）：







創造性には素晴らしい分野があります。各検査は、それが評価される深刻さと比較することができます。 すべての検査をオンにするだけでは、脳をオンにせずにコードを完全に記述することはできません。 検査では、前に悪臭を放つだけです。 したがって、たとえば「比較の左側の定数」と「比較の右側の定数」など、まったく逆の検査があります。 ここでの選択は、あなたの好みとあなたが維持しようとしている標準に依存します。 本当にたくさんの検査があります、一杯の通路は数時間かかるので、良いお茶を買いだめすることを忘れないでください。



有用な注目すべき検査から：

• I / Oリソースは開かれているが安全に閉じられていない -開いているすべてのリソースに対して、さらに適切な場所で（JDBC、JNDI、およびnioと同様に）閉じるが呼び出されることを確認できます。
• オーバーライドアノテーションの欠落 -エラーとして扱われるという厳しい決定をしました。これらのエラーが非常に多いためです（ Scalaがそのような宣言に必要なキーワードを使用しているわけではありません）。
• 'keySet（）'の繰り返しは 'entrySet（）'の繰り返しに置き換えることができます -奇妙なことに、2番目の方法がより高速であり、存在すらあるとは考えていません。
• 'instanceof'チェックのチェーン -悪意のあるLSP違反者に、あなたが異なって生きることができることを示唆できます。
• 過度に長いメソッド 、 メソッドが多すぎるクラス -メソッドとクラスが時間内に破損し、適切な数の画面に配置されることを監視できます。

必要な検査セットが選択されている場合、彼は自分の名前を割り当てることが最善であり、一番上の行の右端にある「 エクスポート」ボタンをクリックしてエクスポートできます。 次に、プロファイルとともにxmlファイルを保存する場所を選択します。 ファイルをバージョン管理システムにアップロードし、TeamCityをセットアップするときにさらに使用するために、すぐにプロジェクトフォルダーにファイルを保存しました。



[ インポート ]オプションを使用して、保存されたプロファイルを他のチームメンバーにインポートして、チーム全体で同じようにチェックが機能するようにすることができます。 確かに、プロファイルを変更するたびに、チームはインポートを再実行する必要があります。エクスポートされたファイルへの変更は自動的に追跡されないためです。



そこで、TeamCityのセットアップに進みました。 TeamCityでは、さまざまな方法でプロジェクトを構築できます。 さまざまな方法、いわゆる ランナー：Maven、Ant、その他約12個。 それらの中には特別な-インスペクションランナーがあります。 それを使用するには、別個のアセンブリ構成を作成するか（構成）、または既存の構成にステップを追加する必要があります（ビルドステップ）。 次の図は、このステップの完成したフォームを示しています。







Mavenプロジェクトがあり、私が見つけたのは驚きでした。「指定されたパスは、チェックアウトディレクトリからの相対パスでなければなりません。 ディレクトリベース （.idea）プロジェクトのプロジェクトファイル（.ipr）またはプロジェクトディレクトリのいずれかを参照する必要があります。 "、この主題に関するドキュメントの利点は明確です。" Maven2プロジェクトの場合：pomへのパス。 xmlファイル。 私たち自身は、マルチモジュールMavenプロジェクトのモジュールの1つ（ tinkoff-portal-web ）を収集するため、その中のpomファイルへのパスを示します 。 作業ディレクトリもそれぞれ修正する必要があります。



別の興味深い点：メモリ消費。 標準の最大割り当てメモリサイズとPermanent Generationのサイズを増やすことなく、検査検査は失敗します。 たとえば、システムにインストールされた6.5.6のTeamCityの新しいバージョンでは、 JVMコマンドラインパラメーターフィールドには次のように事前に記述されています。

-Xmx512m -XX:MaxPermSize=150m
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同じフィールドで、TeamCityで特定のパッケージをチェックするかどうかを選択できます 。たとえば、 Webサービスを操作するために生成されたスタブに対するクレームを確認するのはあまり面白くないので、自分で記述したクラス（Mavenの場合、パスは、チェックされているモジュールのルートに相対的であることがわかります）。

 -Didea.include.patterns=src/main/java/ru/tcsbank/portal/*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次の項目は、検査プロファイルを含むxmlファイルへのパスです。 パスはルートを基準にして指定する必要があるため、プロジェクトは異なるエージェントで、したがって異なるフォルダーで収集できます。 理論的には、プロファイルファイルをビルドサーバー上の別の神聖な場所に置くことができますが、それを変更することは非常に困難です（ちなみに、これはある観点からは合理的かもしれません）が、実行されたチェックをすばやく修正できるようにしたかったです 名前に適したすべての環境パラメーターを実験して記録することで、レシピが見つかりました。

 %system.teamcity.build.checkoutDir%/tcsInspectionsProfile.xml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IDEAに保存するときに設定したプロファイルの名前と、致命的と見なされる警告とエラーの数を示すためだけに残ります。この場合、プロジェクトは収集を停止します。

最初は、失敗したチェックの総数よりわずかに大きい数を取りました。その後、コードの品質が向上するにつれて、この数は減少し、減少し続けています。



したがって、アセンブリを開始すると、 次のように表示されます。



さて、今では、コミットによってコードの品質が向上したか悪化したかが常にわかります。



結論として、TeamCityはMavenよりもIntelliJ IDEAプロジェクトをビルドする可能性が高く、いくつかの制限があります：Mavenに加えて、IDEAインスタンスがサーバーにロードされます（アセンブリ中、「Starting up IntelliJ IDEA 10.5.2 ... "）その他...検査ランナーは特定の種類の検査で奇妙な動作をします。たとえば、「未使用のインポート」が匿名継承を作成するために使用された未使用のクラスを検討した場合がありました。 残念ながら、検査の正確性を損なわないために、そのような検査はオフにする必要がありました。



その後の検査の選択は、 Pizza-Driven-Developmentメソッドを使用してチームと一緒に実行できます。



次のイテレーションでは、「IntelliJ IDEA Project」ランナーを使用する予定です。これにより、アセンブリがより高速になり、検査の精度に関する問題を修正し、一定の再インポート検査プロファイルを放棄できるようになることが期待されます。