プルリクエストで心掛けること
最近、社内のチームでプルリクエストの運用を開始しました。
以前から個人的には数回行っていましたが、いまいちうまく機能しなかったので、チーム内でプルリクで心掛けることを改めて話し合いました。
プルリクエストのタイミング
- WIP RP(Work In Progress Pull Request)の方式を採用する
- コードを書き始めた段階からプルリクを発行し、設計の序盤からレビューしてもらえる体制をとる
- とても小さな変更で、設計者に不安がない場合はプルリクは不要とする
→これはプルリクの乱立により、より重要なプルリクを見落とさないため
当初はWIP PRを知らなかったため、設計完了してからプルリクを登録しており、レビュワーも割り込み作業という感覚が強かったです。そのため、「プルリクエストをリリース間近に出しても見れないよね」という切り口から話題に上がりました。
WIP PRを行うことで、レビュワーの負担も少なくなります。また、序盤で指摘されれば、手戻りも少なくて済みます。
プルリクエスト登録時のコメント
- レビューしてほしいポイントを記載する
- 完了希望日を明記する
- 仕様に関する情報などを記載する（Redmineのチケット情報など）
レビュイーがレビュワーに必要な情報を記載することにしています。プルリクが登録されたけど、変更点多すぎてどこを見たらいいかわからい、いつまでに見たらいいの、などの意見がありました。
特に重視したいのはレビューしてほしいポイントを伝えることです。レビュワーも効率よくレビューすることができ、内容によっては「そこよりもこっちのほうが問題だよね！？」みたいな温度差も分かりやすくなるのでいいのでは、とも思ってます。
コードレビューする文化があまり育っていない環境なので、これを機に気軽にレビューできるようになればいいな！
設計するときの私の考え方
自分がプログラムなどを設計するときにどういった思考で物事を考えているかを、改めて書き出してみたいと思います。
重ね合わせの理
私は学生時代は電気科でした。そこでこの「重ね合わせの理」を学んだ時に漠然と「複雑そうに見えても単純化できるってこういうことなんだなー」と思っていました。
この「複雑そうなことを単純化して重ね合わせる」という概念が、設計を行うのに非常に役に立っています。当たり前っちゃ当たり前ですが、今でも、「この仕様は、○○と△△の仕様（要件）が重ね合わさってるな」と考える癖がついています。
プログラムを作る時も、その考えが「機能分割」に繋がっています。自分の考え方を改めて思い返すと、この考えがかなり根底にあるなと思いました。
ドラクエの職業熟練度
私はドラクエが好きで、まだ園児ではないだろうかくらいの時にＳＦＣのＤＱ５をやっている写真が残ってました。。。
この熟練度ですが、そのまんまです。例えば仕様追加の要求があったとき、その部分について詳しくない場合は、理解できるまで（使いこなせるまで）いじり倒します。コードに限らず、（私は産業機械の組み込み系なので）アクチュエータの動作パターンについても、思いつくままにいじります。「おおよそ理解できたな」と感じるときは、まるで新しい武器が装備できたときのような感覚になります。熟練度で言うと★５で板についてきた感じです。こうなると、コード書きながら、心の中ではめちゃめちゃ気分よく剣振り回してます。
逆に、この状態にならずに設計を進めると、へんなところではまることが多い気がします。動作パターンの計算ミスだったり、検討した仕様に不具合があったり…。
まあ結局、納期まで時間がなくて、周りに急かされる場合なんですけどね。
チームメンバーの反応を想像する
何かを検討するときは、自分の中でメンバーとの会話を想像してます。「あの人ならこういうこと言ってくるよな」とか、その人の口癖みたいなのを想像したり。これをするだけでかなり客観的に物事が見れて自分には無い考えがふっと出てきたりします。（想像した内容を実際に指摘されるかは別ですが）
ただ、書いていて思いましたが、あまりチーム間のコミュニケーションが多くないので、特定の人物しか想像してないかもしれません。もう少しいろんな人の考え方とかを想像できるようになると、もっと自分の中で考える幅が広がりそうです。
煮込んでいる間に皿を洗う
私は昔からよく料理をするのですが、なるべく片付けながら料理することを心掛けています。味噌汁、煮物などは、火にかけておく時間があるので、その間にほかの作業をすることができます。
結局のところ、これはマルチタスクやクリティカルパスの話ですね。人にお願いする作業（検証作業や、図面の確認など）はなるべく早く回し、その間に自分は他の作業をすることで並行して作業が進められます。人を渡る作業を優先することでスループットもよくなりますしね。
最後に
いざ書き出してみたら、一般的なことだなーと思いつつ、「みんなこういう一般的なことを自分なりに解釈しやすいように噛み砕いているんだよね…？」と気になりました。
もしかしたら、私の理解できてない概念とかも、誰かの独自解釈だと理解しやすかったりするかもしれないですね。チーム内でこういう発表会しても面白いかも。
輪読会始めました
今日から初めて輪読会を始めました。
書籍は「リーダブルコード」です。有名な本ですが、実は最近まで読んだことがありませんでした。読んでみると内容も分かりやすく、メンバーに共有したいことも多かったので、輪読会をしてみることにしました。
書籍：リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
当日の進め方
進め方としては、以下のような流れです。
- 事前に担当者を決めて、自分の興味がある章を読み、要約を準備しておく
- 当日に要約を説明しながら簡単に読み進めていく
- 節ごとに少し間をおいてメンバー間で意見交換をする
- 最後に、次回の担当者を決める
事前にみんなで読んでおきたいとも思いましたが、みんなで本を揃えるのは少しハードルが高いので断念。要約を発表する形式にしました。
要約はスライドなどを準備するわけではなく、本の流れに沿って説明していきます。説明が続くと意見交換のタイミングが難しいと思ったので、節ごとに少し意見交換の時間を意識的にとるようにしました。
黙読をする時間は設けていません。これも書籍の準備の関係と、テンポよく進めたかったためです。もしかしたらメンバーはもう少し本読ませてって思ってたかもしれませんが・・・。
また担当者については、次回以降は立候補制にしました。強制でやらされてる感を出ないようにしたかった為です。立候補者がいなければ私が続けるつもりでしたが、こちらもやってくれる人がいたので、なんとか回りそうです。
感想
初回は私が発表を担当しました。要約だけで伝わるかな？と心配でしたが、思ったよりいろいろ意見が出てきて、時間が足りないくらいでした！
特にいいなと感じたことは、本を免罪符に若手メンバーが既存のコードに対して積極的に意見を述べてくれたことです。普段言いづらい雰囲気を出しているわけではありませんが、改めて指摘するタイミングってなかなかなかったと思います。リーダブルコードの内容とも相まって 、指摘するハードルがかなり下がったのではないでしょうか。
始める前はどうなることかと心配していましたが、かなり満足のいく結果だったと思います。参加メンバーからの意見も取り入れていきたいので、アンケートみたいなのを軽く取りたい気もしています。
これをきっかけに技術書を読む癖がついたり、メンバー間で情報交換が盛んになれば良いなと思います。
※今回の輪読会を開始するにあたり、以下の記事を参考にさせて頂きました。ありがとうございます。
