Shiraji's Blog

プルリク駆動勉強

まとめ

勉強出来そうなプロジェクトを選らんで、pull requestを投げて、レビューしてもらうと勉強になるよ。

対象者

  • 息をするようにpull requestを投げられない
  • プログラミングの基礎は勉強したけど、今度どうすればいいのわからない

プルリク駆動勉強とは

30歳を超えて、会社では中堅になりました。昔は会社から与えられた仕事をこなすことによって成長を感じられていました。ここ数年は後輩に教えたり、リソース管理などをすることが多くなり、エンジニアとしての成長を感じられなくなってしまいました。(マネージメント力の成長は感じています。)このままではいかん！ということで、考え出したのがプルリク駆動勉強です。

プルリク駆動勉強とはpull requestを投げるためにそのプロジェクトを学んだり、英語でのコミュニケーションをしたり、その言語のベストプラクティスを体で覚えたりすることです。

とにかくpull requestを投げてレビューされることを目的にします。

pull request投げるなんて出来ない！怖い！って思うかもしれません。 確かに急に新しい機能の提案するのは中々通らないし、レビューすらしてくれないこともあります。しかし、すでにあるIssueのうち、プロジェクトオーナーが「これはやりたいけど、時間が〜」と言っているようなものはくそコードを投げつけてもしっかり受け止めてくれ、そのコードをより良いものに仕上げるようにアドバイスくれます。

このレビューが非常に良く、凄腕のエンジニアが無料でコードを見てくれてアドバイスまでくれるのでスキルアップに最適です。こっちは勉強のつもりなんですが、pull requestを送っただけで感謝されることだってあります。もしそのコードがマージなんてされちゃえば、有名どころのプロジェクトの一部が自分のコードで動くことになるわけです。これは嬉しい。

かといって、無闇やたらにpull requestを投げてもいいことはないので自分の経験からこれなら勉強出来る！というものを説明していきます。

プルリク駆動勉強の条件

自分は以下の条件でpull requestを投げるプロジェクトを選定をします。

  • GitHubのスターが500以上。出来れば5000以上
  • 開発が活発
  • Issueがラベルなどで管理されている
  • 放置されているpull requestが少ない
  • GitHubで完結している
  • 使ったことあるなしは気にしない

GitHubのスターが500↑

GitHubのスターが多いものは注目度が高く、利用価値が高いです。またこういうプロジェクトの開発に関わっている人は技術レベルが高く、pull requestへのレビューもかなり厳しくなります。こういうプロジェクトにコントリビュート出来るとモチベーションアップにも繋がるため、有名どころを積極的に狙います。

ただし、有名どころだと「バグ報告はありがたいけど、いきなりコードのコントリビュートはしなくていい」と言うところもありますので、CONTRIBUTING.mdは注意して読んで下さい。

開発が活発

1年以上放置されているライブラリだとマージどころかレビューされない可能性が高くなります。それでは意味がないので、コードレビューがされているかどうかの確認は絶対行います。

マージ権限があるユーザ(Collaborator)が複数いるとかなり良いです。マージしているコミッターが複数いるかどうかをコミット履歴から追ってみるとわかります。

Issueがラベルなどで管理されている

有名どころのプロジェクトはリソースがないから対応していないIssueが結構あります。新参者がいきなりそういうIssueに対してpull requestを送るのは怖いと感じるはずです。(pull request投げるのに慣れると特段気にならなくなりますが。。。)

Issueが整理されているプロジェクトでは、誰がコントリビュートしてもいいよ！というラベルが貼ってある場合があります。例えば、自分がちょくちょくコントリビュートしている、AndroidAnnotationsではContributionWelcomeがそれに当たります。 こういうラベルがあれば、いつでもバッチコイやと宣言しているので、新参者だろうと特に気にせず、pull request投げてしまいます。大抵の場合、何をするべきかということがしっかりIssueに記載されていますので、その通りに実装すれば良いだけです。

ラベルが管理されていないところでも、Issueにこれやってもいいかね？というコメントをしてしまうのもありです。マージしている人が上げているようなIssueは特に狙い目で質問もしやすく、レスポンスも早いです。

放置されているpull requestが少ない

一ヶ月以上前に上げられたpull requestが10件以上放置されているようなプロジェクトは危険です。

大抵、pull requestはマージしてほしいから出しているわけで、コントリビューター側の問題で放置されるというのは稀です。プロジェクトオーナーがレビューしてくれない、マージする気がない、忙しいことが多く、そういうプロジェクトにpull requestを投げても放置されるだけで勉強出来ません。時間の無駄です。

GitHubで完結している

GitHub内で完結していないプロジェクトは避けます。Issueが別サイトであったり、sourceがcloneで一発取得できなかったりするものです。そのプロジェクト特有のローカルルールはラーニングコストが高いわりに学んでもそのプロジェクトでしか使えないためです。

どうしてもそのプロジェクトのコントリビュートがしたい！という人であれば、全力で推奨しますが、そういうプロジェクトは新参者に対しかなり壁が高く、最初からそういうのを狙ってしまうと続けられなくなります。

使ったことあるなしは気にしない

ビルドやテストが通る環境が出来てしまえさえすれば、そのプロジェクトを使ったことあるなしは特に問題ありません。

自分の場合、今直近で出しているpull requestは全て使ったことがないプロジェクトだったりします。 (ぶっちゃけると使ったことがないほうがマージされて壊れちゃっても業務に支障出ないし、気楽だったりします。)

必要なスキル

プルリク駆動勉強で必要なスキルは以下です。

  • gitの基礎やfork->commit->pull requestまでが出来る
  • コードレビューでも折れない心
  • 自分のスキルではまだ出来ないと思わないこと

gitの基礎やfork->commit->pull requestまでが出来る

pull requestを投げるまでの流れはググればすぐ出てくるので、説明省略。

それ以外でもgit/githubの問題はやっているとちょくちょく出てきますが、都度やりたいことをググれば出てきます。勉強して下さい。どうしてもわからない場合は直接聞いてしまってもいいです。

fork元のブランチとの同期方法が最初の壁だと思います。面倒であれば、forkしたリポジトリを消して再度forkして同期を取るのもありです。 (ただし、マージ前のpull requestがあったりすると面倒なので、注意。) これも勉強だと思って、わからないのであればググッてみて下さい。「fork 更新 追随」とかで検索すれば出てきます。

コードレビューでも折れない心

特に経験の少ない人や潰れていった人に多いのがコードレビューの指摘点がその人に対して言っているのでは？と勘違いしていることです。

コードレビューはコードに対して言っているのであって、そのコードを書いた人に対しては言っていないです。

この考えになってない人は早めに切り替えないと精神的に病みやすいので気をつけて下さい。 辛辣な意見があるかもしれませんが、あなたを否定しているわけではないです。 (逆にコードを書いた人を否定するような意見をするレビュアーがいる場合、さっさとそのプロジェクトから離れるなり、転職するなりしたほうがいいです。そういう人と一緒にコード書いても精神的に疲れるだけです。)

自分のスキルではまだ出来ないと思わないこと

プルリク駆動勉強で一番問題なのが、「自分のスキルではまだ出来ない」と思う心の壁です。

どれほどしょぼいコードでもpull requestを投げることで、そのプロジェクトに関わっている人に指摘してもらい、コードをどう書けばいいのかがわかってきます。

自分の場合、一度も書いたことなかった言語を触りたいからということで、コード読んでpull request投げたこともあります。

最終的に良いアウトプットになればいいわけで、最初から完璧を目指す必要がないです。また最初からほぼ完璧なコードが作れるのであれば、プルリク駆動勉強はもう卒業しています。

会社でのプログラミングは社内の特殊なルールがあったりし、社外で通じないことが多々あります。有名どころのプロジェクトではベストプラクティスを求められるため、じっくり設計し、自分が考えたさいきょうのコードを作り上げることが出来ます。どんなことでもコントリビュートしてくれたことに感謝してくれるプロジェクトが多いです。無料で世界レベルのエンジニアに教えてもらい、さらに感謝までしてもらえます。そのコードがマージまでされれば、世界で使われるような有名なプロジェクトが自分のコードで動くことになります！

個人的な成果

まだ3ヶ月ほどですが、これをやるようになって、Java8, Groovy/Gradle, Kotlinの勉強が出来ました。Rubyや英語のスキルも上がったことを実感しています。

また、gitの知識もかなり深まりました。他人の途中のpull requestを自分のpull requestとして取り込み、修正し、投げるみたいな貴重な経験も出来ました。小さいアイコンと大きいアイコンが一度に出るようなコミット見たことありますか？

気をつけること

時間をかければかけるだけ勉強は出来ますが、業務に支障が出たり、最悪体を壊してしまいます。

以前はブログを書いたり、本を読んだりと夜遅くまでダラダラをやっていました。でもいまいち成果が出なかったです。今は短い時間で集中して結果を出していくことを心がけています。夜12時には寝ます。お昼休みの食後30分と子供が寝た後の1時間だけやっています。無理は絶対にしません。だって、納期はありませんから。

一日多くの時間がないので、毎日コミットは出来ません。Issueやコードを読むだけで過ぎてしまう日もあります。でも週1くらいのペースでpull requestを投げられています。

スケジューリングに時間を使うのも無駄なので、一個終わったら次のIssueへという流れにしています。

pull requestが怖い人へ

そんなこといってもお前スキルあるからやれるんでしょ？みたいな人がいるかと思うので、実際に自分がつい最近送ったくそpull requestを晒しておきます。

https://github.com/excilys/androidannotations/pull/1673

すでに指摘を受けて修正していますが、最初のpull requestを投げたタイミングで、「It’s ready for review.」(ﾄﾞﾔｱ)と言っておきながら、 AndroidManifest.xmlのActivityタグにViewクラスを指定するという意味不明な行動をしていたり、newInsanceVarというtypoをかましていたりといろいろひどいです。それでも罵られたりすることはないです。(いい加減罵られたほうがいいんじゃねーか？というレベルなのですが・・・)

最後に

この勉強法を使って経験が浅い若手や学生がどんどん世界で腕を磨いてくれたらと思います。特に時間のある人は積極的にコードを公開し、レビューを受けて腕を磨いて下さい。早ければ早いほど学べることが多いと思います。

自分もスキルに自信がついたら・・・とGitHubでpull requestをほとんど送ってこなかったのですが、そんな自信はやらない限り絶対につかないです。どんどん他人のプロジェクトで失敗して、腕を磨いて下さい。