Help us understand the problem. What is going on with this article?

Pull Requestに対して何かしてみませんか?

More than 1 year has passed since last update.

この記事は「IDOM Engineer Advent Calendar 2017」の9日目の記事です。

はじめに

現在私は大学院にいるのですが,大学院でのチーム開発ではGitHubを利用して開発をしています.
そこで,GitHubのPull Requestで私が工夫として導入してみたものを紹介したいと思います.

コードレビューを自動で行う

コードレビューは大事なのですが,やっぱり開発が忙しかったりとすぐにはコードレビューできない場合あったりしますよね...
あと,ちょっとしたレビューの見落としなど...

そこで,今回はSonarQubeというソースコードの品質チェックを行ってくれるものを利用しました.

使い方としては,Travis-CIでビルドおよびテストを行った後に,SonarQubeを利用して,GitHubのPull Requestに対して,ソースコードの品質をチェックした結果を返しています.

このソースコードの品質チェックとして,対応しているプログラミング言語は,以下の言語などがあるようです.

  • C/C++
  • JavaScript
  • Python
  • Java
  • PHP
  • Swift
  • etc...

実際にJavaのプロジェクトで使った様子は以下の図のようになっています.

image.png

こんな感じに
「変数名がスネークケースで書かれてるぞ!!!!キャメルケースで書けよ!!!オルァ!!!」
と教えてくれますね!

その他にも,

  • Move the array designator from the variable to the type.

[]は,変数じゃなく型に付けましょうというものだったり

int hoge[][]; // NG
int[] hoge[]; // NG
int[][] hoge; // OK
  • Use a StringBuilder instead.

文字列連結は+で繋げずにStringBuilder使いましょうというものだったり

// NG
String str = "";
for (int i = 0; i < arrayOfStrings.length ; ++i) {
  str = str + arrayOfStrings[i];
}

// OK
StringBuilder bld = new StringBuilder();
for (int i = 0; i < arrayOfStrings.length; ++i) {
  bld.append(arrayOfStrings[i]);
}
String str = bld.toString();

を見てくれます.

これらは,SonarQubeのルールに反したコードを指摘しています.
ルールの詳しくはこちらで確認することができます.

しかし,SonarQubeでは変数名の妥当性やプログラムの柔軟性などまでは見てくれなさそうです・・・
ですがちょっとしたコードのミスを開発メンバーの手を煩わせることなく修正することができそうですね.

まぁJavaScriptとかだと,Lintとか使えば手元で分かるので,そっちのほうがいいかもしれませんが...

導入してみたい方はこちらの記事を参考にしてやってみてください.
SonarQube と TravisCI を使って Github でのコードレビューを自動化する

テストコードのカバレッジを投げる

テストコードを書くのって機能の開発と同等の時間かかったりするので,面倒という理由でさぼって書かなかったりする人もいるかもしれません.また,テストコード書いたのに果たしてカバレッジがどの程度なのか分からなかったりします.

そこで,今回はiOSのプロジェクトに対して,Pull Requestに関連するテストコードのカバレッジを返すようにしました.
こちらも先程と同様に,Travis-CIでビルドおよびテストを行った後に,,GitHubのPull Requestに対してカバレッジの結果を返しています.

それを実現するのために,ビルドやリリース作業の自動化などを行えるfastlane利用しました.
fastlaneには様々な機能があるのですが,今回はテストコードのカバレッジを調べるxcovとPull Requestに通知できるdangerを利用しました.

実際に利用して行った結果を以下に示します.

image.png

こんな感じに,テストコードが書かれていないと,💀や🚫などの絵文字が表示されます.
こうすることで,毎回の機能の開発でPull Requestを出すとテストコードのカバレッジを見ることになり,開発メンバーはテストコードを書くようになるかもしれません.
※テストコードを全体的に充実すべきかどうかはまた別の話なので,話を省きます.

実際に利用してみたい方は以下の記事を参考にしてください.
iOS 開発での Pull Request と テストカバレッジの連携

おわりに

今回GitHubのPull Requestに対し,コードレビューの自動化や,テストコードのカバレッジの可視化を行ったことについて紹介しました.
この他にもDangerを利用してPull Requestに様々なチェックをしている方などいますので,参考にしながら活用してみては如何でしょうか?

次は@manekineko_glvさんによるAngularの話です〜

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away