2018/06/14
雑多なアウトプット
- gemでprivate repositroyをbundle installするとき、トークンとか設定しないといけない場合がある。こういう設定gemの追加方法もあるのかと、再認識
- gemのバージョン指定で
~>ってあるけど、例えば、~> 1.5とかあれば、1.5.x系の最新のマイナーバージョンをインストールしてくれる。1.6系が出た場合はインストールしてくれないので注意。 - gemファイルにトークンを組み込む方法はあるけど、直接トークンを書くより環境変数に入れたほうが良いかも。
反省点
今日はかなり反省するべき事があった。先に反省点を言うと、「コミット・PRを小さく保つべきなのに、そのPRとは関係ないコミットなどを積んでしまった」ということ。
ちょっと前の日記で、ボーイスカウト・ルールとかを見て「おお！確かに見つけた不具合は、見つけた時に次いでに治すのが効率的だし、なにより通りがかったついでみたいな感じだから修正を入れる手軽さがある！！」と思い、早速実践したのも裏目に出たと思う。
とあるAの修正を目的としたPRがあり、そのAの修正とは直接的には関係ないが、次いでに近くにあるメソッドやテストexampleをリファクタリングした。オペレーションとしては、コードをリファクタリングしているのでそこまで問題ではなかった思うが、判断が良くなかった。すでに書いているが「ついでに」なのだ。レビュワーとしては、見る範囲をできるだけ小さくしてもらいたい気持ちなのに「ついでに」で入った修正も見る羽目になると辛い。その「ついでに」が実は他の部分に影響している可能性も充分あるわけだ。こうなるとレビュワーに優しくないPRができてしまう。
趣味の個人開発ではなくチーム全体で仕事をしているのでもう少し広い視野を持ってコードを書いて欲しいと思いました。
この指摘を受けて、「あーレビュワーに優しいPRを作ろうなんてブログ記事を書いておきながら、実践できてないな俺・・・。」と反省した。
あとはコミットの粒度も悪い点があって「AもやってBも次いでにやった」みたいな感じ。これも「実を細かく分割しないほうがレビュワーも見やすいのでは？？？」とか思ってやったが裏目に出た。 これは何が悪いのかというのを経験豊富な先輩方からレビューいただけたのだが、
- 将来、その修正箇所に問題があったとしてコミット履歴をもとに調査を行う
- しかし、コミットが「AもやってBも次いでにやった」とあるので、どっちの修正が影響しているのかわからない。
- 結果、エスパーして修正をしてみないとわからない ということが起きる。ということなので、コミットも調査の重要な資料となる。確かに、githubとかでblameで誰がいつどんな修正を入れたコードなのか？を自分もよく見る。コミットもできるだけ小さくわかりやすいものを書く癖をつけないと、後々の面倒なことになることを先に知れてよかった。
PR、コミットは小さく保つのが大事 ちょっと違うかもだけど、書いて思い出したのが、Unixという考え方って本にあったsmall is beatiful.って概念と似てるな〜と思った。あとはメソッドの責務を小さくするとか。
コラム
ジョカノと「旅行に行きたいね〜」って話はしているのだけど、どこが良いのか迷い中。なんか文化的な街とかでブラブラしたい、歴史あるところに行きたいらしいのだけど、とりあえず京都が脳内を専有してくる。歴史ある街 = 京都という自分の連想プロセスもかなり偏っているなw。
