Sider Blog

コードレビュー自動化サービス「Sider」を運営するSider株式会社のコーポレートブログです。



Sider 特別インタビュー GitHub アーロン・パターソン氏  コードレビューにとって大切なことは

2018年6月12日、13日の2日間にわたり、GitHub Satellite Tokyoが開催されました。 Siderでは、これにあわせて来日していたGitHub社のAaron Patterson(アーロン・パターソン)氏に、特別インタビューをお願いしました!気さくで日本語が堪能なアーロンさんは、終始笑顔で弊社CTOのSoutaroの色んな質問に日本語で答えてくれました。どうぞお楽しみください!

f:id:sideci:20180611122905j:plain  

GitHubでの日常 - RailsのアップグレードからGCの改善まで

Soutaro:
今GitHubでどんなことされてるのかをちょっと聞かせてもらえないかな、と思っています。

Aaron:
実はGitHubでは私は普通の開発者です。

Soutaro:
えっ??プロダクションのコードをバリバリ書いてるんですか!?

Aaron:
それは冗談。ジョーク(笑)。

GitHubでは私はメモリー使用量とウェブサイトの速度を改善しています。つまりパフォーマンスを中心に頑張っています。Rubyの開発だけをやるフルタイムコミッタではなくて、アプリケーションとRubyの両方を開発しています。

Soutaro:
RubyKaigiとかRubyConfとかで話していた、GCのやつとかですね。あれはGitHubで必要だったってことですか?

Aaron:
はい。GitHubのアプリケーションはすごくメモリを使うので、最近はRubyのメモリの使用量を減らす方法を考えています。

大体1年くらい前に、GitHub Enterpriseのサポートの人たちから「私たちのアプリケーションのメモリー使用量がだんだん増えてきた」と聞いて、それから調べ始めました。GHEとGitHub.comでは共有されているコードがありますが、GHEはお客様のハードウェアにインストールするものです。お客様のコンピューターのメモリはGitHub.comよりも少ないので、制約が厳しいんです。

Soutaro:
わかります。我々のSiderのオンプレ版も将来的にリソースが問題になると思っています。

Aaron:
私たちと同じ問題ですね。

Soutaro:
なんで最近あんなにメモリのことをずっとやってるのかなと思っていたんですよ。

RubyConf 2017で話されてたCompacting GCを僕はとてもすごいと思っていて、それまで「RubyでCompacting GCやってもほとんど意味ないんじゃ」って思っていたので、「あ、実際にできるんだ、効果あるんだ!」と思って。

Aaron:
ありがとうございます。開発は進んでいて、プロダクションにも入れてみたんですが、まだリリースしていません。バグがあるのでまだRubyコアにサブミットしてないんです。GitHubのプロダクションの一部で試したらバグが見つかったので、revertして。

GCの仕事はすごく楽しいけど、私の業務の割合としては20%くらいですね。普段はRailsの問題を修正しています。GitHubの開発で見つかったRailsの問題を直しています。

Soutaro:
同時にGitHubのコードも直していくっていう?

Aaron:
そうです。今のGitHubのRailsのバージョンは4.2ですが、1年前は3.2でした。今、5.2にアップグレードしている最中です。いろいろと問題が見つかってます。

Soutaro:
なるほど。入社されたときには3.2だったのを、これはアップグレードしないと駄目だって思って……

Aaron:
そうそう。プロダクションでRailsのmasterとRubyのtrunkを試したかったから、最初にアップグレードをしなくちゃならなかったんです。Railsのmasterを使えばアップグレードも簡単になると思います。いつもアップグレードしてくれるし、誰かがRailsにバグを入れたらすぐにわかるから(笑)。

Soutaro:
なるほど。それにしてもGitHubはすごいですね。RailsもRubyもわかってる人がチームにいて、直したRubyとRailsをすぐにプロダクションにデプロイできるっていうのは、すごく強いなと思います。

Aaron:
うん、強いと思います。

おそらくRubyだけを速くしても、Railsのことをわかっていないと結果はそこまで出ないと思うんです。今、WebアプリケーションのボトムラインはRubyというよりかはRailsなので。RubyとRailsの両方が理解できていると、もっと良い結果が出せるはずです。

Soutaro:
GitHubにジョインされることになったきっかけはどんな感じだったんですか?

Aaron:
GitHubは3回も入社を誘ってくれたんですよ。そのとき私はRubyのフルタイムコミッターになりたかったんですけど、GitHubは面接で「うちでそれができる」って言ってくれたんです。それが3回目の誘いだったので、もう4回目はないだろうと思って、入社しなくちゃならないと思いました。それが理由でした。

それから、入社を決めたもう一つの理由に、「GitHub.comのコードを見たかったから」というのもありました。

Soutaro:
GitHubのコードはどうでした?

Aaron:
結構問題あるけど……。今までにもっと悪いコードも沢山見たことあるから、実際はにはそんなに悪くないと思います。でも、もちろん問題ではあります(笑)。

面白かったのは、defunkt*1のバグを直したときですね(笑)。defunktが書いたバグを私が直したんです!つまらないバグでしたが、結構古いコードで、誰が書いたか知りたかったのでgit blameしたら、defunktが書いたのがわかった。

 
 

RubyとRails、スタイルに関して

Soutaro:
先日、Siderで松田明さんにインタビューをしたときにRubyとかRailsでのコードレビューとかコーディングスタイルについての話を聞いたんですが、何か補足とか、意見とか、これはウソでしょうみたいなことってありますか?

Aaron:
あの記事は面白かった。

コーディングスタイルはRailsとRubyは全然違いますね。例えばRailsではスペースだけを使っているけれど、Rubyの中ではスペースとタブを共に使ってます。

Soutaro:
あの記事を見て、Rubyコミッターの卜部(うらべ)さんが「Rubyも最近はスペースに統一することになってる」ってツイッターで言ってて。

Aaron:
本当!?

Soutaro:
えっ??

Aaron:
Wow! 知らなかった。

Soutaro:
この話をコミッター3人として、そのうち2人が知らないっていうのはどういうことだ……

Aaron:
スペースかタブかは私にはどっちでもいいので、その話自体を見てなかったです(笑)。Vimで自動でスタイルを合わせてくれるから、私には全然問題がない。

Vimは、設定すれば自動的にスペースかタブを選んでくれるんですよ。このVimの設定は特別な設定ですが、おそらくみんな同じファイルの中でスペースとタブをあんまり使ったりしないから、ほとんど知られていないんだと思います。 *2

Soutaro:
Railsはもう最初からスペースは2つなんですね。

Aaron:
スペース2つ。

でも好きじゃないところはprivateのキーワード。privateと書いた下にはさらに2つスペースを入れます。それは変だと思います。GitHubでは使わない。他のプロジェクトで見たこともあるけど、その開発者はもともとRailsの開発者でした。

Soutaro:
ちなみにDHHインデンテーションのメリットは何だと思いますか。

Aaron:
……分からない。

彼の主張では、「何がプライベートのメソッドか簡単に分かる」という点ですね。でもそのインデントがなくても、privateのキーワードを見たらすぐ分かると思います。その下はプライベートだから、これは意味がないと思う。

Soutaro:
ですよねえ。

Aaron:
スタイルの話で言えば、Seattle.rbのスタイルは括弧を使わない。

メソッドの宣言では引数に括弧を入れないんです。このスタイルはみんな嫌いなんですけど、私は好きです。なんでみんな嫌いなのかわからない。

Soutaro:
えっと、僕も嫌いです(笑)。

Aaron:
なんで嫌いなんですか?

Soutaro:
Cみたいな感じかな……うまく説明できないけど。

Aaron:
私が括弧を使わない理由は、RubyはLispみたいな言語ですが、括弧を使わないLispがかっこいいと思っているからです。Lispは括弧は多すぎるから。

Soutaro:
僕はOCamlも書くので、そのときの感じで書いちゃうのかも。OCamlは複数の引数をタプルで渡すか高階関数にするかの2通りがあって、型が違うんですよ。(int * int) -> intint -> int -> intの違いで。

Aaron:
ああ、なるほど。ここでは括弧の意味があるから。

Soutaro:
そうですね。あとは、Rubyだと「ここの括弧がなくても絶対に曖昧にはならないんだから書かなくていい」って聞いたことがあって、それはちょっと納得しました。

Aaron:
多分、みんなはC言語みたいななものに慣れているから、括弧がないと気持ち悪いんだと思います。

いずれにしても、一番重要なことはそのチームのスタイルを使うことです。Railsを開発するときはRailsのスタイル、GitHubを開発するときにはGitHubのスタイルを使っています。私の好きなスタイルはあるけど、それに対する私の個人的思い入れはそんなに強くないですね。

「もしも自分のスタイルを使いたいなら、自分のプロジェクトを開発したほうがいいですよ」と言いたい。

Soutaro:
プロジェクトによってスタイルが違うと、何か混乱したりとかしませんか?

Aaron:
あんまりない。だいたいのプロジェクトにはRuboCopとかがあるし、間違えたら誰かが教えてくれる。大丈夫です。

Soutaro:
RuboCopは好きですか?

Aaron:
実は、RuboCopは初めは嫌いだった(笑)。でも今は慣れました。

最初は「何で私にスタイルを押し付けてくるんだ」と思って嫌でした。でも考えてみれば、一番いいことは、同じチームのみんなが同じスタイルを使うことです。だから今はもう嫌いではないです。RuboCopを使うべき理由を分かっているから。RuboCopによってチームのスタイルが統一されることが大切。

Soutaro:
そうですよね。 Railsのレビューの話も聞かせてもらえますか?

Aaron:
ああ、いいよ。Railsのレビュープロセスは、私は簡単だと思う。レビューされていないから(笑)。

直接masterにプッシュしちゃうからレビューされない。もし間違えても、他の人が直してくれるから問題ないです。多分悪いことだけど…。

Soutaro:
Rubyみたいになってますね。

Aaron:
そう。最近PRを作るようになったけど、前は全然使わなかった。なんでかって言うと、PRを作るのが面倒くさいから。

でも、直接pushしてCIが落ちちゃったときにCIを直す方がすっごく面倒くさいことに気づいたので、今ではPRを作るようになりました。

 
 

GitHubの開発プロセス

Soutaro:
ここまでRailsとかRubyの話を聞いたんですけど、GitHub社内ではどんな感じでコードレビューをしてるんですか?

Aaron:
みんなとだいたい同じだと思います。普通はバグとフィーチャーを作るときにブランチを切って、変えて、開発をして、レビューをして、直して。

そのブランチは、プロダクションにデプロイして、問題がなければマージします。つまりmasterはいつもステイブルのブランチです。

Soutaro:
GitHubではPRをマージする前にデプロイする。

Aaron:
開発者がそれぞれフィーチャーブランチを切るんですけど、PRを出して、アプルーブされたらプロダクションにデプロイします。何も問題がなければそのままmasterにマージします。もしもエラーが増えるとかの問題があったら、masterをプロダクションにデプロイします。

デプロイのときは、まずは3%のマシンにデプロイされます。それでエラーの状況を見て、エラーが増えてなければ全部にデプロイ。その後でmasterにマージします。3%はトラフィックの絶対量としては多いけど、お客さんの割合としてはあんまり多くありません。なのでもし問題があったら簡単にロールバックできる。

つまり、masterは常に安定版になっていて、いつでもロールバックできるようにするための存在です。この辺は他の会社と違うと思います。

Soutaro:
はい。われわれは違いますね。PRをレビューして、マージしてからデプロイしています。ロールバックしたいときには、GitHubの画面からRevertしています。

Aaron:
なるほど。

Soutaro:
ちなみに、PRがアプルーブされてからデプロイ完了までってどのくらいの時間が掛かるんですか?

Aaron:
今、それは会社の中で大問題になっています。デプロイ自体は10分か20分で終わるんです。でも問題は、デプロイ待ちのキューで、キューで待たなくちゃならないということです。キューにはいつも10人とか5人くらいの人が入っていて、それぞれ10分か20分かかるから、1時間〜2時間待たないといけない。

でも私は今日本にいるから、時差のおかげでキューには誰もいない。みんな西海岸にいるから。今だったらデプロイは10分で終わります。

Soutaro:
すごい。デプロイし放題だ。

Aaron:
そう、そうです。デプロイの時間があまりかからないから。私はSlackで「みんな日本に引っ越したらいいよ」と言っています(笑)。

今、この問題を解決する方法をみんなで考えています。多分マイクロサービスとか何かを使うことになるのかと。アプリケーションが分かれれば、キューがたくさんになるから、待ち時間が短くなるはず。

Soutaro:
そうですね。今のはデプロイの話でしたが、レビュー自体は普通にやるって感じですか?

Aaron:
はい。RuboCopも使ってます。デフォルト設定は使ってないけど。公開されているGitHubのスタイルがあるので、そのスタイルを使っています。

でもGitHubのスタイルは、いつもダブルクォートを使うんです。私はいつもシングルクォートを使っていたから、入社したてのときにこれは面倒くさいと思った。RuboCopはいつも怒ってました。

Soutaro:
あれ?ダブルクォートはRailsも一緒じゃないですか?

Aaron:
Railsは、ダブルとかシングルのどっちでもいいと思います。

Soutaro:
そうだったっけ……?

Aaron:
そうかな?間違ってるかな……。

(この間Soutaroにhttps://github.com/rails/rails/blob/v5.2.0/.rubocop.yml#L120-L123 を見せられているAaron)

f:id:sideci:20180611121052j:plain

Aaron:
Oh, No!(笑)

Soutaro:
えー。何で気付かないんだろう……文字列リテラルをあんまり書かないんですかね。

Aaron:
あんまり書かないのかな……。

ダブルクォートと言えば、一般的なキーボードでダブルクォートを打つ時にシフトとクォートを押さなくちゃいけないのが面倒なので、私のキーボードで1つのキーを押したらダブルクォートが出せるようになってます。自分のキーボードで。

Soutaro:
えっ、すごい!

Aaron:
あと、私のキーボードだとホームポジションで括弧を書けるんです。このボタンを押して、DとFで括弧が出ます。これは括弧のオープニングとクロージング。

編集注:気になったので、後日アーロンさんのInstagramを覗きにいったら、自作キーボードの写真が色々載ってました。興味のある方はぜひどうぞ!

コードレビューで大切なこととは

Soutaro:
GitHubでの仕事のコードとRailsとかのオープンソースのコードでは、レビューに関してなにか違いはありますか?

Aaron:
私からすると違いはないですね。だけど、オープンソースのほうが良いレビューをしようとする気がします。ちゃんとコメントを書いて、フィードバックをあげる。企業での開発ではそうはいきません。みんな、コメントも短いし、レビューもあまりされなかったりする。

なので、私はオープンソースでレビューをするように、会社でも質の良い、丁寧なレビューをしようと心がけています。みんながそうしているかはわかりませんけど。私にとっての違いはその辺でしょうか。

Soutaro:
コメントの質が違ってくる理由は何だと思いますか?

Aaron:
会社だと同僚同士でお互いを知る機会があるので、もっと手っ取り早くレビューができてしまうんじゃないでしょうか。OSSでは、知り合いではなかったり違う企業で働くもの同士が協力しあうので、そうはいきません。もっとコミュニケーションを取る必要が出てくる。

でも私は、それは良いことだと思っています。なので、会社でも同じようにレビューしようと心がけています。新しく入ってくるメンバーに読んでもらいたい状況が出てくるかもしれないですし、後から見直したくなることだってあるかもしれない。自分でも忘れてしまうことがあるんだから、記録が残ってるほうが良いと思います。

あとは、企業とOSSの開発速度が違うのも関係するのではないでしょうか。会社での開発はOSSと違って時間があんまりないので、それがコメントのスタイルにも影響しているんだと思います。

Soutaro:
コードレビューをやっていく中で大事なことは何だと思いますか?

Aaron:
レビューで大事なことは、コードの変化を理解することです。そのコードがプログラムの挙動をどう変えているのか、何をしているのかが分かること、これが一番大切だと思います。でもdiffだけで見ていたら、そのことがわからない時もあります。そのあたりがPRでレビューをするうえでの難しい点だと思います。つまり、どうやって全容の理解に取り組むか、が大事です。

Soutaro:
僕はGitHubのPRはレビューの効率をすごく改善したと思うんですけど、まだ十分ではない?

Aaron:
レビューのコメントを書くことができたりとか、PRはすごく便利だと思います。

でもdiffだけ見ていると、どうやってプログラムが動くのかわからないときもある。diffを見たらコードの何が変わったかは分かりますけど、その変更が全体のシステムにどう影響するかがわからないことがあります。他のコードがどう影響するかがわからないから。それが自動でわかるようになるといいと思います。

Soutaro:
クラスの定義を変更したときに、他のコードから参照されているところで何かがおかしくなっていた、みたいな話?

Aaron:
そう。それが自動的で分かるとすごく便利。

Rubyで、なにかコードを解析してくれるものがあると、大きなプロジェクトですごく便利だと思う。

Soutaro:
型検査ツールとか?(笑)*3

Aaron:
そう。

でも……実は型を書きたくない(笑)。


f:id:sideci:20180611112743j:plain Aaronさん、お忙しいなかありがとうございました!

*1:編集者注: GitHubの共同創業者でありCEO

*2:編集注: 以下がその設定。https://github.com/tenderlove/dot_vim/blob/c5e3c7c1bb5273c9b4be4d1a6eb5f1312bd3915a/vimrc#L129-L133

*3:編集注:Soutaroが開発中の型検査ツールの話をしています

SiderにおけるFlake8サードパーティープラグインサポートのお知らせ

SiderでFlake8のサードパーティープラグインが使えるようになりました。

Flake8は コードのスタイル、エラー、循環的複雑度をチェックすることができるツールです。 Flake8のコア機能だけでもある程度有用な指摘を得られるかもしれませんが、 さらに詳細な指摘を必要とする場合、Flake8の基本的なチェッカーのみでは不十分なことがあるかもしれません。

そこで、SiderではFlake8のサードパーティープラグインをサポートすることにしました。

この機能を有効にするためにはsideci.ymlを以下のように記述してください。

linter:
  flake8:
    plugins:
      - flake8-bandit
      - flake8-builtins==1.4.1
      - flake8-mypy>=17.3.3

詳細はこちらをご覧ください。

何かご不明な点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

7月分の解析ツール更新を行いました

こんにちは。プロダクトチームの渡邉です。Siderでは毎月解析ツールのバージョンを見直しております。この度、7月分の更新作業を完了しましたので、お知らせします。更新内容は以下の通りです。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、RuboCop, ESLint, TSLint, stylelintに関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

PHP_CodeSnifferのデフォルトバージョンを3系に変更します

いつもSiderをご利用いただきありがとうございます。

2018年8月20日をもって、デフォルトで実行されるPHP_CodeSnifferのバージョンを2系から3系に変更いたします。

現在、SiderではPHP_CodeSnifferを実行するとき、デフォルトでは2系の最新版である2.9.1が実行されます。このとき、3系(7月17日現在の最新版は3.3.0)を使う場合は、sideci.ymlversionオプションを使い、明示的に設定する必要がありました。 今回のデフォルトバージョン変更により、PHP_CodeSnifferの解析を利用するお客様は、今後、明示的に設定することなく3系で解析が行われます。 また、既にversionオプションを利用して、バージョン指定を行っているお客様は、設定を変更することなく、これまでと同様に、設定したバージョンで解析が行われます。

デフォルトバージョン変更後も従来通り、PHP_CodeSnifferの2系を使って解析を行う場合は、以下のように、sideci.ymlにて、2系を選択する設定を記載してください。

linter:
  code_sniffer:
    version: 2

2系と3系の変更点の詳細につきましては、以下のリリースノートをご覧ください。

https://github.com/squizlabs/PHP_CodeSniffer/releases/tag/3.0.0

また、現時点でSiderでのPHP_CodeSnifferの2系のサポート終了時期は未定です。 なお、PHP_CodeSnifferの2系では、リリースノートにあるように、今後新規機能の開発は行わずセキュリティアップデートのみ行うことになっており、3系への移行を推奨していることから、SiderでPHP_CodeSnifferの2系を使う予定のお客様につきましてもアップデートの準備・対応をお願いいたします。

何かご不明な点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

RubyKaigi ’18 特別企画 Jonan Scheffler 氏インタビュー

f:id:sideci:20180602114040j:plain五月末にRubyKaigi 2018が仙台で開催されましたが、既にお伝えしている通り、私たちSiderチームも参加してきました。そこで幸運にも、開発者であり、HerokuのDeveloper Advocateでもある、Jonan Scheffler(ジョナン・シェフラー)氏にインタビューする機会をいただくことができました。

RubyKaigiでのジョナンさんの知名度は高く、特にセッションの合間に突然始まる非公式イベント「デカ外人クイズ」の主催者・出題者として親しまれています。そんな気さくなジョナンさんに、今年のRubyKaigiでの新しい試みから、Herokuでの仕事の話、日本の温泉まで、幅広い話題を語ってもらいました。

なお、本記事でのインタビューは日本語で行われました。日本文化を大学で専攻していたジョナンさんが、日本語で回答してくださったものを、少しだけ読みやすく編集して掲載しています。どうぞご覧ください!

f:id:sideci:20180602113904j:plain
左:SiderのCTO 松本宗太郎 右:ジョナン・シェフェラー氏

ポーカーリーダーからプログラミングへ

Soutaro:
RubyKaigiの参加者の間では、ジョナンさんは「RubyKaigiに来ると会える”デカ外人”」っていう感じでみんなに知られていますけど、それ以外の方のために自己紹介していただけますか。

Jonan Scheffler:
私のことをみんな知ってるって言われると照れますね。5年前からRubyKaigiに来ているので知り合いは結構いるんですけど、その頃はソフトウェア開発を始めたばかりでした。実は私、昔はいろんな仕事をしていて、ソフトウェア開発の前はポーカーリーダーでした。

Soutaro:
え?

Jonan Scheffler:
カジノでポーカーディーラーをやってました。他にも車の営業とか、いろいろやりました。ホテルのフロントとかね。

ソフトウェアの道に進むことになったきっかけは、コードスクールという、アメリカの6カ月ぐらいでソフトを学べる学校に行ったことです。Hungry Academy (ハングリーアカデミー)というんだけど、ほんとに(コードスクールの中でも)最初にできた学校だったから、入れたのはすごくラッキーだったと思います。運がよかった。

でも、その学校に入る前にはすでにRubyKaigiに来ていました。少ししかソフトウェア開発はわからなかったけど、RubyKaigiに参加しに来日していました。

Soutaro:
そのときは趣味でやってたんですか?それとも大学とか、そういうところで勉強していた?

Jonan Scheffler:
大学ではJavaを勉強しました。そのときは友達も大体Java系の人しかいなかったんですけど、そのみんなはゲームの会社に入って何だかすごく辛そうな仕事をしていたので、「いやあ、楽しそうじゃないな」と思って途中でやめました。最初は学位を2つ取ろうとしていたんだけど。コンピューターサイエンスと、もう1つは日本の文化。日本語の文法もやったけど、文化を中心に勉強しました。だからまだ漢字は読めません。

実は高校卒業後、ロータリーの交換留学で日本に1年間いました。それで日本語を覚えていたので、アメリカの大学の初年度にテストを受けて、大学3年レベルの日本語の授業にいれられました。ただ、大学3年に進級した時、自分の履修していた大学院レベルの日本語の授業が、コンピューターサイエンスの3年次の授業と時間がかち合っていたんです。その二つの授業を同時に取る人は他になかなかいないでしょうしね。どちらかを選ばなくちゃいけなくて、日本文化の方を選びました。

そうこうして、会社に入りました。グラフィックデザインの仕事でフォトショップを使ったりもしていました。仕事でRubyを使っていたので、それでコードスクールに行きました。7年前の話です。こんなところでしょうか。

 
 

RubyKaigiと日本

Soutaro:
RubyKaigiへは5年前に初めていらっしゃったということなんですね。それから毎回いらしてるんですか?

Jonan Scheffler:
そうですね。最初に来たのは、Final RubyKaigiというKaigiでした。多分2011年。その次の年、RubyKaigiがなかった年以外は全部行きました。築地と広島と京都とここ(仙台)と、あともう一つの東京で開催されたものがありましたよね。その5つ。

Soutaro:
RubyKaigiによくいらっしゃってるんですね。日本に頻繁に来ているんですか?

Jonan Scheffler:
私は日本にいろんな知り合いがいるから。留学していた青森県によく行きます。

だから、私は温泉などの、青森とかの田舎にあるものがすごく楽しいなと思います。温泉は絶対に入ったほうがいいです。もしRubyKaigiに来ることがあったら、温泉に入んなきゃならない。あっ、でも恥ずかしかったら、家族風呂をおすすめします。もしホテルに家族風呂があれば、予約すれば一人で安心して入れますから。でも、もしできるなら、みんなで入る日本の文化にチャレンジしてほしいですけどね。無理だったら家族風呂がいいですね。

Soutaro:
日本で一番お勧めなのは温泉?

Jonan Scheffler:
温泉かな。温泉とお寿司ですね、やっぱり。

アメリカで出てくるお寿司は大体が日本のコンビニで売っているみたいな寿司です。もちろんアメリカにも素晴らしい店はありますけど、だいたいの店の魚は冷凍したものだからまずい。ウニは特にまずいですね、冷凍すると。その日に獲れたウニが一番おいしいから、日本に来たらぜひウニを食べてほしいですね。アメリカでウニを食べて、「あ、これは食べられない」と思う人は多いと思うので、日本で再挑戦してほしいです。いろんな食べ物を楽しんで、自分の食の嗜好の幅を広げてほしいなあと思います。

Soutaro:
ありがとうございます。RubyKaigiに出席するために日本に来た際には、こんな風に日本を楽しんでもらえたら良いですね。RubyKaigi自体は、どんな風に楽しんでますか?MAGIC?

Jonan Scheffler:
ええ。今年は『MAGIC : The Gathering』というカードゲームの選手権をやってます。「国際Ruby MAGIC選手権」です。

これまで3〜4回ぐらい、カンファンレンスでMAGICをやりました。すごく楽しいんですよ、みんなでやると。友達も作りやすくなりますしね。RubyKaigiでやったのは初めてだけど、来年も絶対やります。

その他では今回生放送をやってます。ペアプログラミング。それもすごく楽しいです。みんなの前でコードを書いて見せるのは、初心者に親切だと思う。プログラミングを始めたばかりの人たちは恥ずかしがったりしますよね。先輩たちのすごさを見て、自分はできないんだって思いますよね。例えば、あなたがgemを出したら、初心者はその完成したコードを読んで「ああ、すごい。これは素晴らしい。私には絶対書けない」って思うかもしれない。

だけど、あなたもそのgemを開発している最中に何回も失敗してきたと思うんです。私は、その失敗を初心者の人たちに見せたいんです。「みんなもこういう失敗するから大丈夫だよ、それで」って初心者にも安心してもらいたい。そういうことを見せるために生放送をやっています。
 
 

コードレビューと自動化

Soutaro:
今の、実際に良いコードを書ける人たちがプログラミングしてるところを初心者に見てもらって、「どんな風にやってるか」「どのくらい失敗しているか」っていう様子を見せたいっていう話、すごく興味深かったです。

Jonan Scheffler:
そうですね。別にうまい人だけが入ってくるところではないですね。みんなとやりますけど。みんなで楽しむためにやっています。

Soutaro:
今の発想みたいなのは、仕事をされているなかで、コードレビューとかトレーニングとかをやってきたうえで出てきたアイディアなのかなって思ったんですけども、どこからそういう考えを得たんでしょうか?

Jonan Scheffler:
Herokuにはわたしを含め、Developer Advocateが二人いるんですけど、主な活動はカンファレンスに行くことと、ブログを書くことの2つです。カンファンレスによく行くとは言えないけど、(カンファレンスがどんなものか)だいたいのことはわかりました。

その他に、デベロッパーとコミュニケーションをとる方法を探していたところ、Twitchという生放送を行えるウェブサイトに出会いました。これはゲームの話をしている動画が大半なんですが、最近プログラミングのカテゴリーも出てきて、「ああ、これやってみようかな」と思い始めました。

それを使って、コードレビューをHerokuの内部でやっています。コードレビューや、いろんなエンジニアがどんなソフトを開発しているのかなどの皆に共有したいことについて、Herokuの内部用に非公開のビデオを撮ったり、ポッドキャストを作ったりしています。Herokuの社内の人のカンファレンスが今度あるんですが、その時も社内用のビデオを作って、コードレビューとかの話をします。

Soutaro:
Herokuではコードレビューはどういう風にやっていますか?大事なことだと思うのですが?

Jonan Scheffler:
もちろんですね。大きい会社では、PCIコンプライアンス(Payment Card Industry Data Security Standardクレジットカード業界のデータセキュリティ標準)とかHIPAAコンプライアンス(米国の医療保険の携行性と責任に関する法律)などの様々なコンプライアンスのために、コードレビューが必要です。HerokuでもHIPAAに準拠したサーバーを出していますし、そういったサーバーをリリースする前にも、チーム内で頻繁にコードレビューを実施しました。チームによって違いますが、いろんなツールを使っていました。RuboCopを使っているチームもたくさんあって、私がいたInternal toolsのチームでも使っていました。一般に公開されるツールというよりは、Herokuのソフトウェアエンジニアのためにツールを作るチームでした。

その頃はRuboCopをよく使いました。SaaSの製品も使いますし、flayみたいな複雑さやコードの重複を検出するツールも使っていました。そういうツールを使って、例えば、プログラムの中で頻繁に変更されている部分、つまりコードチャーンが見えるようになります。もしあるコードが何度も編集されているようだったら、やばいところだと思うので、ちょっと目をかけた方が良い。

Herokuの中でも、そういうことをよく行っています。

f:id:sideci:20180602113809j:plain  
Soutaro:
今のはHerokuの話だったんですが、これまで幾つかのソフトウェアの会社で仕事をされてきたと思うんですけれども、それぞれでレビューのスタイルの違いとかはありましたか?

Jonan Scheffler:
GitHubで”Approved”とかレビューの結果を表現できるようになる前に、きちんとレビューが通ったことの確認をできるようにしていたことがあります。2、3年前ぐらいの話だけど、絵文字をコメントに書いたらレビューの結果になるようなツールをツールチームで作っていました。チームメイトがレビューして、Pull RequestにThumbs upとかスマイルフェイスを書くと、Approveの意味でそれでマージしてもokになる。もしApproveの前にマージしてしまったら、それはバツで、そのアプリが「誰かがまずいことをやった」ってEメールを送る。

これはチームメイトがApproveするんだけど、Herokuの前の職場はそうではなかった。そのときは、実装の前にアーキテクトの人たちに聞いていました。「こういう考えがあって、これをやりたい」と話して、で、実装してからまたアーキテクトにレビューしてもらう。私はそういう形はあんまり好きじゃなかった。なんか上に偉い人がいて、「あなたたちこれを書け」とか、書いた後は「どうです?」とか、そういう形はいや。ソフトでみんな一緒に頑張れば楽だ。

Soutaro:
ピアレビューイングのほうがやりやすい?

Jonan Scheffler:
やりやすいよね。そもそもアーキテクトって会社の中で3人か5人ぐらいしかいないから、忙しいじゃん。だから、私たちが書いてるコードにすごく詳しいわけじゃない。誰がこのコードについて一番知ってるか?それは私、私たち。だからそういう人に聞けばいいんじゃないって。そっちの形の方が好き。

Soutaro:
ピアレビューする方法と、アーキテクトみたいな「レビュアー」がいる方法、2つを比べたときに、書けるコードの品質とかプロダクトの品質という観点ではどちらが良いと思いますか?

Jonan Scheffler:
作ってるものはピアレビューで強くなると思う。なぜかというと、速く書けるようになるから。それだけで強くなるわけではないけど、速く書けるようにするには、上の(立場の)誰かが見る形は駄目ですね。

例えば私たちが2人でコードを書くと、この2人は全部分かるよね。わたしがあるファイルを書いていたとしたら、チーム全員がその内容を理解できているのが理想的。ただ、チームが少し大きくなって、合計8人くらいになるともう難しいですよね。でもその大きいチームの中でも、ピアレビュープロセスがあれば、みんながコードがわかるようになります。周りは何をやっているところだとか、いろんなPRでコードの全部を見ることができるので、深くまでは見えなくても把握できるようになります。で、そのシステムの全容が分かれば、これはレビューのプロセスとしてうまくいくと思います。

逆に、レビュアーが決まっていてその人だけが確認するような形だけを使うとすると、それは一番まずいと思います。チームの中で他の誰が何をやっているか分からなくなってしまうので。
 
 

レビュー自動化サービスの使い方

Soutaro:
ありがとうございます。ところでSiderはご存知ですか?

Jonan Scheffler:
Webサイトぐらいは見たことあるけど、まだサインアップしてない。RubyKaigiに来てから知ったので、これから試したいと思いますけど、やっぱりKaigi中はちょっと忙しいので。

Soutaro:
ちょっと説明すると、Siderはコードレビューを自動化するためのサービスです。いくつか競合がいますけど、我々は「プルリクエストをレビューするときに役に立つ」っていうところにフォーカスしています。

Jonan Scheffler:
Herokuの中でも同じようなサービスは使っているんですけど、みんなあまり見てませんね。大体のエンジニアの人たちが、送信されてくるメールをきちんと読まない。セットアップするときに、あまり気にせず適当にやってしまうので、ちゃんと通知設定ができていなくて、すごくたくさんのメールが来てしまう。そうするとうるさくなってしまって、「まあいいよ、これは。ひとまずおいておこう」って感じに相手にされなくなる。

だから開発を始めるときに、丁寧にやるときには通知の設定をきちんとやります。あんまりうるさくならないように、1日1回だけとか、1週間で1回だけとかに設定します。RuboCopとかも、どのルールを有効にしてどれを無効にしてというのを、丁寧に設定する。きちんと設定しておけば、警告が出たときに無視されることがなくなってちゃんと直してもらえるし、あとは遅いコードの検出とかも見過ごされることがなくなる。

Siderも多分同じで、問題が検出されたときに無視されないようにデザインするのが大切。「あ、これは絶対いけない」みたいな問題から、すぐに直さなくても大したことがない警告までいろいろあるので、その通知を上手く設定できるようにできたら強いプロダクトになると思う。

今はそういうサービスを使っているけど、前の職場では自分たちでflayとかそういうgemを使って、レビュー自動化の仕組みを作っていました。上手くやるのはとても難しいんだけど、ほんとに大切なことだと思うから、いろいろな会社があればいいねって。Siderを使うのはすごく興味がありますね、私は。

Soutaro:
そうですね。ありがとうございます。

Jonan Scheffler:
どうもありがとうございます。
 

f:id:sideci:20180602114040j:plain

ジョナンさん、お忙しいなかどうもありがとうございました!