概要:
Githubに上がっているOSSやライブラリなんかのコードをできるだけ読むようにしてわかったことや得られたもののログ。
発端:
多分具体的な行動に移るきっかけになったのはRails Developers Meetup 2017から。
そこで紹介されたブログのコミットログを読むようになった。
y-yagi.hatenablog.com
あとKyoto.rbのSlackに参加しているのだけどそこにRailsのコミットログを流す rails_commit というチャンネルがあってそこにjoinした影響も少なからずあるかも。
結論:
具体的にいくつかのメリットがあったと感じている。
- コミットの粒度とコミットログの良い書き方
- コードのベストプラクティスな書き方
- 英語を読もう/書こうという気持ち
ちょうどRailsチュートリアルを始めた影響やチェリー本を読んだ経緯などもあって「やってみるか」という軽い気持ちで始めたがそこそこ続いている。
軽い気持ちで始めた割にはそこそこいい感じだなと思っている、具体的な効果に関してはまだまだ出ていないというのが結論。
ただコミットログを見るのは文字を覚えるためのドリルのようなものだと思っているので焦らず今後も続けていこうかなと思っている。
なにより綺麗なコードを日々見続けるので汚いコードを読んで頭を悩ませる…みたいな無駄な時間を減らせるんじゃないかと考えている。
コミットの粒度とコミットログの良い書き方
ぼくが日頃読むようにしているコードは多くがrubyやrails、そしてvue。あるいはGolangだ。
だからなのか、非常に細かいコミットの粒度のPRを目にする。
多くのPRのコミット数が1〜5くらいで変更されたファイルに関してはほぼスクロールしなくてもいいくらいのコード量。
Railsなどのような利用者が多いOSSにおいて粒度の大きなPRというのは害悪だと思うので非常に納得がある。
鑑みるに自分のコードのPRはまだまだ巨大だなと感じており、改善すべき点だと改めて認識した。
ところで、どのPRだったのか覚えていないのだけどrubyかrailsのPRにとあるメソッドの返す値を変えたPRがあった。
そのコミットログに変更前と変更後の期待値が書いてあり、レビュアーにとって非常に助かるコミットログで真似していきたいなという学びがあった。
いままで他人の書いたコミットログで感心したことがあまりなかったのだけどこの件では大いに感心した。
これは業務で行うコミットの場合多くがコンテクストが取れている前提であるためだと思う。
OSSのような多種多様なバックボーンがある場合コミットログにbefore/afterな期待値が書かれているほうがレビュアーの普段が少ないということだろうと思う。
ただこの工夫は業務でも活かせるものだと思うので今後リファクタリングなどで期待値を変える場合に真似していく。
コードのベストプラクティスな書き方
読んでいるコードの多くがいままで携わってきたPHPではなくRuby/Rails、Vue、golangだからだと思うのだが
その言語におけるベストプラクティスなコードの書き方というのが少しずつ自分の中に浸透している気がしている。
慣れない言語を書いていて「Aとも書けるがBとも書ける、どちらのほうが良い書き方なのか？」というのが気になることがある。
慣れ親しんだ言語であるとある程度経験則だったり、他のエンジニアのひとが書いたブログを読んでいて知識として知っているパターンが多い。
仕事などのプロダクトのコードの場合は既存のコードがどうなっているのか？を調べることである程度傾向がつかめることがある。
ところが学習時にそれらのコードをどう書けばいいのか？というのはなかなか判断しにくいものがある。
特にRubyやRailsはそのあたりの書き方がよくわからないケースが多い。
そんなときにGithubにガンガンコミットしているような第一線級のエンジニアが書いているコードというのは非常に有効な参考になるなと思った。
実際にはまだコードを読んでいたことで書き方の指標が出来たとは思っていないのだがジャブのように後々効いてくるんじゃないかなと最近感じている。
あと綺麗なコード、一読するだけで何をしているコードかわかるというのが具体的にどういうことか？という点においても非常に有用だなと思う。
英語を読もう/書こうという気持ち
当たり前だがOSSの多くは英語でissueやPRが書かれている。
タイトルをみても何書いてるかわからない、コメントをみてもわからない…だとかなりつらい。
その点Githubはよく出来ているなと思うのだがやりたいことがissueにかかれており、その解決策としてのコードと一緒にPRが出されているのでなんとなく「こういうことがしたいのかな？」と思ったときに英語の読解に自信がなくてもコードを見たときにやりたいことが伝われば英語の読解に対する補強になると最近感じるようになった。
特に生きている英語を使ってやり取りがされているので教科書でよくみかける「私はジョンです、彼女はミカです」といった
お前はそれを日常会話でいうことが現実的にあり得るのか？みたいな英語じゃないし、
issueのdescriptionは仕方がないがタイトルやコメントは比較的短い英語であるので苦手意識を少しずつ減らしていけそうだなと思っている。
まとめ:
先日会社でも「最近GithubのOSSなコードを読むようにしていて、なかなかいいぞ！」といった主旨の発言をしたのだが
せっかくなので文章ログとしても残しておこうと思った。
以前からOSSに貢献しようぜ！という話しは各所で聞いていたのだけどまずはコードを読むところから入っていくのでもいいんじゃないかなと思う。
結果、そこでなにか問題があればissueなりPRなりを出していけばいいしなにより美しいコードを読むのは勉強になるがそれ以上にワクワクするものがある。
まずは趣味としてのコードリーディングから入るのも悪くないんじゃないかなとおじさんは思いましたまる
