2016年2月29日月曜日

【AndroidStudio】FindBugs導入

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近はAndroidStudioの検証を進めています。

現在は快適な環境構築を目指してプラグイン探しをしています。
本日はFindBugsに行ってみましょう。

FindBugsとは

FindBugsとは、一言で言えばプログラムの静的解析ツールとでも言いましょうか。
Java業界では結構有名なツールで、ソース中のバグらしき箇所を発見してくれる機能を提供してくれます。

結構有名なツールですので、調べれば色々出てくるでしょう。

前回紹介したCheckStyleと静的解析という意味では似ていますが、
CheckStyleは変数のネーミング規約とかそういう『可読性』に関するチェック機能に対し、
FindBugsは処理に問題無いかどうかという『ロジック』についてチェックしてくれるものです。

まあ正直言いますと、FindBugsで検出出来るバグって「自分で気付けよ!!」っていう程度の低レベルバグですので、
これに依存しているようではプロジェクトの品質はボロボロに決まっておる。。。
実装を根本から見直した方が良いでしょう。

とは言え、導入しても別に損はありませんから、入れるだけ入れるに越したことはありません。

では、入れてみましょう。

インストール

インストール手順は、前回のCheckStyleとほとんど同じ。

設定画面から「QAPlug」で検索するとCheckStyleと一緒に出てきます。


どうなってんだ???

CheckStyleとFindBugsは用途としては似たものですが、本来別物なんですけどね。
親切な人が便宜上一纏めにしてくれているのかもしれませんね。

上記画像に出ている「Hammurapi」と「PMD」とは?

どうやら全部静的解析ツールのようです。
今回のテーマはFindBugsですが、もういっそ全部インストールしてみましょう。


全部纏まって入りましたね。

設定とカスタマイズ


後は設定するだけですが、実はこれも前回と同じ。。。
「設定 ⇒ Other Setting ⇒ QAPlug」にある「Coding Rules」から設定をカスタマイズしていけばOKです。


ようやく分かってきました。
「CheckStyle」「FindBugs」「Hammurapi」「PMD」を全部一纏めにしてくれているのが「QAPlug」なわけですよ。

どこからどこまでがCheckStyleで、どこからがFindBugsで……。
Eclipseのプラグインだとこれらはそれぞれ別々にインストールして別々に設定する必要がありますが、
こちらQAPlugを使用すればそんな境界線を気にする必要はありません。

スパッと全部入れて、スッキリ品質の良いコードを書いていけばOKです。

終わりに


引き続きAndroidStudio関連の調査を継続していきます。

2016年2月7日日曜日

【AndroidStudio】CheckStyle導入

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近はAndroidStudioの検証を進めています。

現在は快適な環境構築を目指してプラグイン探しをしています。
本日はCheckStyleに行ってみましょう。

CheckStyleとは

かなり有名なツールなのでCheckStyleの存在をご存じな方も多いかと思いますが、手短に噛み砕いてご説明しましょう。
代表的なコードの静的解析ツールで、つまりJava実装のコーディング規約をリアルタイムでチェックしてくれます。

例えば、実装における一般的な規約として「ローカル変数の頭は小文字で始める」というのがあります。

  • String name = "遠藤 太志郎";

しかし、実装に慣れていない人が実装すると、こういった規約まで配慮が行き届かなくてガタガタになってしまうケースがあります。

  • String NaMe = "遠藤 太志郎";

こういう時、先輩格のSEが目視でレビューするのは大変ですよね?
そんな時がCheckStyleの出番です。
こういう規約に沿っていない箇所に警告を出し、目視し易いようエディター上に黄色く表示してくれます。

これで作業が随分と楽になります。
効率的な実装作業には欠かせないツールと言えるでしょう。

AndroidStudioにもこのプラグインを入れてみたいと思います。

インストール……失敗

では、インストールしていきましょう。
設定画面からCheckStyleを検索します。



え……。沢山出てきたのですが。。。

意味分かりませんが、とりあえずインストールしてみました。

まず、一番上の「CheckStyle-IDEA」って、これ罠だろう!!


プロジェクトを読み込めません : com.intellij.ide.plugins.PluginManager$StartupAbortedException: com.intellij.diagnostic.PluginException: org/infernus/idea/checkstyle/CheckStylePlugin : Unsupported major.minor version 52.0 [Plugin: CheckStyle-IDEA] [Plugin: CheckStyle-IDEA]

起動しなくなりましたわ。

起動しなくなったのでアンインストール画面も起動出来ねえし……。

こうなったら強制削除しかありませんね。
うっかり入れてしまった人は以下フォルダの該当フォルダを手動削除してください。

  • ユーザホーム\.AndroidStudio1.5\config\plugins

よく見ると画面に「INSPECTION(評価版)」って書いてありますね。

ログの「Unsupported major.minor version 52.0」ってのは、実行JREのバージョンが古かったりする時に見るエラーログなんですが、環境変数見直したりJREを再インストールしなおしても結局直りませんでした。

もしかしたらAndroidStudioの本家である「IntelliJ IDEA」なら普通に動くのかも。だとしれば、もしかしたらプラグインも最新版ではなく少し古いバージョンなら動く……。
など考えましたが、結論としてはもう一つのプラグインを使うことにしましたので調査打ち切り。

デバッガーの人なら何か手があるのかもしれませんが、初心者は寄りつかない方が賢明でしょう。

インストール

仕切り直していきましょう。

QAPlugというプラグインの方が正解です。

QAPlugとは、日本語情報が全くありませんが、どうやらIntellij IDEAのプラグインのうち、コード解析を中心に活動しているプロジェクトのようです。


CheckStyle以外にもプラグインを提供しています。
他のプラグインは後日記事にしますので、今回はCheckStyleのみ。

QAPlugは

  • 本体プラグイン:QAPlug
  • 拡張プラグイン:QAPlug - CheckStyle

この二段構えになっていますので、両方インストールして下さい。

設定とカスタマイズ

インストールすると、「設定 ⇒ Other Setting ⇒ QAPlug」が出現しています。
デフォルトでもある程度設定されていますが、Coding Rulesから設定をカスタマイズしていきましょう。


この画面の「+」ボタンを押すとこのような画面が出てきます。


このようにEclipseで作成した設定ファイルをこちらにインポートすることも出来るわけですね。
Eclipseで使っていた設定ファイルをこっちに持ってこれるので楽チンです。

実行

では、登録したCheckStyleの設定でソースを走査してみましょう。

これがまた分かり辛いんですが、右クリックなどで「分析」などを探して、そこから「Analyze Code」を実行すれば良いです。
AndroidStudioにはCheckStyle以外の分析機能も備わっていますから「CheckStyleで分析」とか書いていてくれないとどれがどれやら分からねえ……。


次の画面ではどの設定でチェックするか選択出来ますので、先ほど自分で作成した設定でチェック実行。


コンソール画面にチェック結果が出てきました。


後は警告が無くなるまでこれを繰り返して綺麗なソースを作るだけですね。

終わりに

やっぱりEclipseとは相当使い勝手が違いますね。
慣れるまでは時間をかけて使っていく必要がありそうです。

引き続きプラグイン探しを行います。

2016年2月1日月曜日

【AndroidStudio】フォーマッター設定(Eclipse Code Formatter)

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

ただ今、業務都合によりAndroidStudioの検証を進めています。

今週からは色々とプラグインを探しつつ、快適な実装環境を模索していきたいと思います。

フォーマッターを使おう!!

新しく開発環境を導入した時に最初に着眼するべき所は必ずコレ。フォーマッターです。
ご存じの方も多いかと思いますが、話の前振りとしてフォーマッターの意義をご説明しましょう。

まず、言うまでもありませんがソースというのは可読性が非常に重要になります。
偶に「え? 動けばいいんじゃね?(=何もしなければコストダウンに繋がる)」みたいな事を言う人もいますが、
いやいや、可読性が低いソースを残すことはいずれ大きな弊害を招きます。
バグの見落とし然り。開発効率の低下然り。

とは言え、既に本番稼働に入ってしまったソースを修正するのは新しいバグを生み出す可能性も高く、
上記の通り「動いてるんだから何もするんじゃねえよ」という話に繋がってしまい、未来永劫に修正する機会を得られないケースも少なくありません。

このような事態を未然に防ぐ最善完璧ベストの手段は、もちろんコレです。


  • 最初から綺麗なソースを書く。


コレですよ。最初が肝心。
綺麗に実装出来る環境を最初に整えることが一番肝心なのです。

しかし、綺麗な実装というのはある程度の実力者ならば可能ですが、
チームメンバーは全員が実力者揃いばかりとは限らず、実力者同士の組み合わせであっても個人の癖があります。

キチッと統制を取ってやらなきゃソースの可読性なんてあっという間にガッタガタ。
開発効率は日を追うにつれてどんどん下がっていきます。

そんな時、フォーマッターを導入することである程度まではソースの癖を統一して可読性を向上させることが出来ます。

開発リーダーが最初にやるべきことは、メンバー全員の開発環境を洗練して統一することなのです。
その第一歩がフォーマッターの導入というわけですね。

「戦争のプロは兵站を語り、戦争の素人は戦略を語る」(アントワーヌ=アンリ・ジョミニ)という格言がありますが、
開発で言うとこんな感じですかね。

  • 「開発のプロは環境を語り、開発の素人は技術を語る」(Tacy)

OK?

フォーマッター実行

細かいカスタマイズは後述しますが、まずはAndroidStudioでフォーマッターを実行するコマンドはこれです。
さあ、やってごらんなさい。

  • Ctrl+Alt+L

ガシャツっとソースが動いたら、それはあなたが今までフォーマッターを使っていない危険環境で実装していたことを意味しますのでご注意を。

なお、「ソース保存時に自動的にフォーマッターを実行する」ということも出来るようです。
しかしこちらはマクロを組んだりする必要があり、ちょっと大変なのでまた後日。

フォーマッターのカスタマイズ

フォーマットするだけなら上記のコマンド一発で完了です。
しかし、やっぱりソースに拘りを持つ者としてはフォーマッターの設定をカスタマイズしたいところですよね。

AndroidStudioはデフォルトでフォーマッターが入っており、カスタマイズする場所は以下です。

  • 設定 ⇒ Editor ⇒ Code Style


設定は細かい所まで出来ますのでそれぞれの現場で最もマッチする設定を模索してみると良いでしょう。

問題は、作った設定の共有。。。
自分で構築した設定をチーム内に共有するにはどうすれば良いのだろう?

調査すると「androidstudioホーム/config/codestyles」に設定ファイルがあるという情報を見つけたのですが、そんなフォルダ無えよ。。。

真相不明ですが、この設定って古いAndroidStudioの話なんじゃないの?
今のAndroidStudioだと「設定のエクスポート」を使う以外に手段は見つかってないです。

しかしこれはフォーマッター以外にも色々と一緒になってエクスポートしてしまったりして、
ちょっとチーム共有という観点だと柔軟性に欠けるという印象。。。

そんな時は次、Eclipseのフォーマッターを使っていきましょう。

Eclipse Code Formatter

EclipseをメインとするJavaエンジニアのTacyとしては、やっぱEclipseの資産を使っていきたいなぁ。。。

そう思っていたら、ありました。やっぱみんな想いは同じなのですね。
Eclipseのフォーマッター設定をAndroidStudioに移植する人気プラグインが存在しています。

その名は、Eclipse Code Formatter。

公式プラグイン置き場にありますので、さっそくインストールしてみましょう。


インストールして再起動すると、設定にEclipse Code Formatterが増えています。


後はEclipseからエクスポートしてきたフォーマッターをセットすれば良いという寸法です。

注意点は「Eclipseで設定してからAndroidStudioに持ち込む」という二段構えの設定である所ですね。

AndroidStudioだけで全て完結している現場だったらシンプルにデフォルトのフォーマッターでやりくりすれば良いかと。
しかしEclipseと二刀流をやっている現場ではEclipse Code Formatterの方が馴染み易い印象。

まあ、この辺りは絶対的な決まりは無くて、開発者の好みな部分の気がしますね。
実際に現場に導入してみて、評判を見てどちらか一本の統一するのが良いでしょう。

終わりに

引き続き環境構築向けのプラグイン調査を行っていきます。