バックエンドエンジニアの小椋です。まだしばらく加湿機が手放せないですね。 今年はIntelliJを使えるようになりたいと思います。
普段の仕事でコードは書くよりも読むことの方が多いと思います。最たるものはコードレビューですね。 コードレビューで気になるところはみなさんいろいろあると思いますが、今回は自分が気にしているところを挙げていきます。
ポジティブコメントを意識する
コードベースを意図して汚そうとする人はまずいません。ついついレビューは修正指摘になりがちなので、変更意図が読めるかどうか、 他人に対してリーダブルなことを意識してもらえているかを探すようにします。tips的な発見のある書き方をされていれば勉強になる的な 感想を残すのもよいと思います。
レビュー着手を速くする
レビュー待ちでリリーススケジュールが止まるのはもったいないことです。逆に言えばレビューも開発サイクルに入っていなければなりません。 レビューの反応を速く返すことは、レビュイーであるデベロッパーの開発リズムをキープすることに寄与するだけでなく、 チーム全体のリズム感を醸成することにもつながります。 自タスクがかなり集中を要する優先度の高いタスクがない限りは早めに反応することを心がけた方がよいと思っています。 すぐの反応が難しいときはいつまでにレビューしてほしいかをレビュイーと合意をとって、先にスケジューリングしておきましょう。 GitHub連携していればSlackのreminder設定を活用することで漏れを減らせます。
また、自分がレビュイーの立場になったときは事前の文脈理解がしやすいようなdescriptionを書くようにします。 相互に負担を減らせるとさらにいいサイクルの構築につながっていくでしょう。
最重要視するものは何かを見定める
レビュー対象のコードが与える影響がどの領域に及ぶかで見るべきものが変わります。 アプリのトップ画面のように、アクセス頻度が高く、多くのリソースの読み込みが発生するエンドポイントへの変更であれば、速度や負荷を意識する必要があります。 例えば、N+1問題が発生していないかといったあたりは事前に把握できそうです。私達の開発環境ではbullet gemが入っているので手元で動かして確認するといったこともできます。 また、更新、追加系の操作に対応するところであれば、永続化データの状態を気にすることと思います。 トクバイではお店の方に商品データを投稿していただくことがありますが、その際にメタデータと画像データは別々に保存されます。 適切にトランザクションが用いられているかといったところはチェックする観点のひとつになるでしょう。 レポーティングのような、ログの集計を行うような処理であればデータの完全性や、リスタート時の冪等性担保ができているかは運用フローの設計に関わります。
歴史をふりかえる
それなりに運用してきたサービスのコードは、変更経緯が読み取りにくいものもあります。 シンプルな書き方にしようとして網羅していたパターンを落としてしまうようなことも起こりえます。 これらを避けるために、経緯を知っていそうな人がいればメンションして追加で聞いたり、適切にテストパターンが網羅されているかを確認した方がよいでしょう。
まとめ
普段レビューで意識していることをざっと挙げてみました。最近は自分の体調不良もあって打ち返しのスピードが落ちてしまっていたり、 レビュー依頼を抱えすぎて自分の開発時間が削られてしまうといった問題もありますが、これは別で対処を考えていきたいところです。 歴史のあるサービスだけに大掛かりに変更を加えていくことが難しい状況ですが、引き続き頑張ろうと思います。
