こんにちは、投稿推進部の森川 (@morishin127) です。

エンジニアが既存のプロダクトの開発に携わる際、他人の書いたソースコードを読み解くところから始まります。過去に書かれたコードの意図を理解することは自分が書いたものでもしばしば難しく、他人が書いたものならなおさらです。この記事では過去に書かれたコードを理解するための工夫についてお話したいと思います。

なお、この記事ではプロダクトのソースコードはgitおよびGitHubのPull Requestを利用して開発が進められていることを前提としています。

特定の行から関連するPull Requestページを開く

クックパッドのソースコードには概してコメントがあまり書かれておらず、見ただけでは理解しづらいような特殊な方法をとっている場合のみコメントを書いている印象です。基本的に実装に関する説明はソースコード中ではなく、GitHubのPull Requestページに書かれていることが多いです。

そのためコードの意図を知りたい時にはその箇所の変更に関するPull Requestのページを見に行きますが、そのページを検索するのは少々面倒です。そこでコード中の特定の行からその変更に関わるPull Requestページに直接的に辿り着く方法をご紹介します。

特定のコミットハッシュからそのコミットを含むブランチのマージコミットを見つけるこちら(StackOverflow)の方法が社内でシェアされていました。マージコミットが分かればそのコミットログに含まれるPull Request番号からPull RequestページのURLを生成することができます。これをシェルスクリプトの関数にしたものが下記になります。(※一部Rubyが混入しています)

open-pull-request () {
    merge_commit=$(ruby -e 'print (File.readlines(ARGV[0]) & File.readlines(ARGV[1])).last' <(git rev-list --ancestry-path $1..master) <(git rev-list --first-parent $1..master))
    if git show $merge_commit | grep -q 'pull request'
    then
        pull_request_number=$(git log -1 --format=%B $merge_commit | sed -e 's/^.*#\([0-9]*\).*$/\1/' | head -1)
        url="$YOUR_REPO_URL/pull/${pull_request_number}"
    fi
    open $url
}

$YOUR_REPO_URLの部分にはhttps://github.com/<owner>/<repo>を設定してください。

(2015-11-17 17:05 追記)
こちらのツイートで言われているように、hubコマンドをインストールしている方は$YOUR_REPO_URLを`hub browse -u`に置き換えるのが良さそうです。

詳細を知りたい行でgit blameしてコミットハッシュを割り出せば、上記の関数を用いて該当のPull Requestページを開くことができます。

open-pull-request <commit hash>

Xcodeプラグイン

私は業務でXcodeを用いることが多く、上記のコマンドを実行するためにエディタからシェルに移りgit blameするのを煩わしく思ったためXcodeのプラグインにしました。Xcode上でショートカットキーを入力するだけで現在カーソルのある行に関連するPull Requestページを開くことができます。プラグインは新規に作成したのではなく近い機能を提供していたlarsxschneider/ShowInGitHubをForkしてその一機能として実装しています。

morishin/ShowInGitHub
https://github.com/morishin/ShowInGitHub

morishin/ShowInGitHubをcloneして手元のXcodeでビルドすると~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/以下にプラグインが配置されるのでXcodeを再起動すると有効になります。

最初に実装された時のコミットまで遡る

コードリーディングをする際にgit blameは強力です。blameすることで特定の行が変更された最新のコミットが割り出せ、そこからコミットメッセージやPull Requestの情報を辿ることができます。しかし最初の実装時の情報を知りたいのにその後にバグ修正などが行われ変更されていると、最初に実装された際のコミットが分からず困る場合があります。そこでtigというコマンドラインツールを用いるとblameを繰り返し簡単に過去に遡ることができます。

jonas/tig
https://github.com/jonas/tig

git blameと同じようにコマンドラインからtig blame <ファイル名>を叩くとコミット情報が表示されるので、さらにblameしたい行を選択して,キーを押すとその行が最後に変更されたコミットを起点として再度blameした結果が表示されます。これを繰り返すと簡単に目的のコミットを発見することができます。

古いコミットのコードを実行する時のgit-new-workdir

過去のコードを読むだけでなく、実際に実行して動作を確認したい場合は古いコミットをgit checkoutしてプログラムを実行します。昨今多くのプロダクトではパッケージマネージャを利用しており、checkoutの後にbundle installやpod installといったパッケージのインストールを実行する必要が多いかと思います。そして確認を終えて最新のコミットに戻ってきた際にも再びインストールを実行する必要があり、長い時間パッケージのインストールで待たされることになります。

このような場合はgit-new-workdirというコマンドを使って新たな作業ディレクトリを作成するとディレクトリ毎に別々のコミットをcheckoutできるので、最新にcheckoutしたディレクトリはそのまま置いておいて別の作業ディレクトリで古いコミットの動作確認をすることができます。git-new-workdirはgit-core/contrib/workdir/git-new-workdirに入っているコマンドです。ちなみにgit-new-workdirの存在はCTO氏から聞きました。使い方についてはこちらの記事が参考になります。

git-new-workdir が便利 - #生存戦略、それは - subtech
http://subtech.g.hatena.ne.jp/secondlife/20121207/1354854068

(おまけ) あるビューがどのクラスのものかを特定する

こちらはGitには関係が無いのですがコードリーディングに関連するのでおまけとして記載しておきます。

既存のプロダクトをさわる際、自分が手を加えたいビューに関するコードがどのファイルに書かれているものかを探るのは意外に大変です。コードを読もうにもどこに書いてあるかがわからずファイルの探索に時間を取られてしまう場合があります。RailsアプリとiOS/Androidアプリのそれぞれで、実行時に表示されているビューからそれを司るファイルを特定する方法をご紹介します。