セルフコードレビュー

自分の書いたコードのレビューを依頼するとき, 必ず先にセルフレビューするようにしていて, まあまあ上手くいっていると思っている.

元々のモチベーションとしてはコードの品質の向上と (本物の) レビュワーとのコミュニケーションのつもりだったけど, 本来レビュー時に行われるはずだったやりとりが削減されることで開発が高速化される効果もありそう.

ルフレビューにかける時間は, 典型的な規模 (差分 500 行以下くらい) の場合で修正込みでだいたい 15 分 〜 30 分程度で, そこに至るまでの実装にかけている時間が 1 〜 2 時間くらいと考えるとまあまあ時間は割いている. ただこれは他の人のレビューを待って, 一往復に数時間 〜 数日かけてやりとりして同じ変更を加えるよりはずっとマシ.

何かの参考になるかもしれないので私のやり方を書いておきます:

  • 他の人のコードをレビューするときと全く同じ方法で行っている
    • 私の場合 GitHub 上で見て, 現在の Pull Request の差分のみに注目している
    • コードを書くエディタ上とは環境を変えることで, 客観視しやすくもあると思っている
  • 注目するところも他の人のコードのレビューと同じ
    • 設計
      • イケてるか
      • 意図を説明できるか
    • 実装
      • 規約や慣例に従っているか
      • 命名や記述に一貫性があるか
      • コードが読みやすいか
      • コードやコメントなどから実装の背景や意図が伝わるか
      • リファクタリングの余地があるか
    • テスト
      • 意図通りの内容をテストできているか
      • 網羅性は十分か
  • 洗い出された問題点を修正する
  • 加えて本物のレビュワーへの手紙をレビューコメントとして残す
    • 背景や意図が伝わりにくい箇所を補足する
    • 現時点ではまだ仮実装であるといった文脈を補完する
    • 自信がない箇所であれば表明して意見を求める
  • 書いたレビューコメントを見直して, コード中にコメントを残した方が良い内容であればコードに転記する
    • 例えば背景や意図が伝わりにくい箇所は, 今からコードを読むレビュワーだけではなく, 後からコードを読む人にとっても伝わりづらいはず

やり方は違うかもしれないものの似たようなことをしている人はもちろんいて, レビューする側として見た場合に, セルフレビューを経て細かい問題が取り除かれ, 適宜補足コメントなども書かれたコードのレビューはとてもやりやすいという印象も持っている.

f:id:susisu:20210308022313p:plain

アプリケーションのコード規模に対する雑感

  • 主観です
  • 規模はコード行数 (LOC) で考えています
  • あくまでアプリケーションについての話です
    • ライブラリについてはまた事情が変わってくる
  • コードについての話しかしません

LOC 〜 102

  • アプリケーションというより, ちょっとしたスクリプト程度
  • すぐに全貌を把握できる
  • 困ったことがあったら作り直せば良いので, 正直何でも良いと思う

LOC 〜 103

  • おそらく単機能のアプリケーション
  • 全貌を完全に把握していられる
  • 一人で開発しているなら何でも良いと思う
    • 規模が小さいので, 型検査や lint のような静的解析は目視でもなんとかなる
    • 機能が少ないので, テストは手動でもなんとかなる
    • もちろん便利だと思うならコスト次第で使えば良い
  • 複数人 (あるいは一人でも時間が離れている) で開発するのであれば, CI にある程度コストを払ったほうが良いかもしれない
    • 機械的に型検査や lint がされていた方が安心だが, 全員が同程度の練度かつ規約を共有していれば必須とも限らない
    • 自動でテストが行われていると安心だが, 全員が十分にコミュニケーションをとれていれば必須とも限らない
    • コストの具合によっては一人で開発するよりも大変なこともありそう
  • まだ困ったことがあったらなんとか作り直せる規模なので, 設計は最低限でも絶対に悪いわけではないと思う
    • 複数人でわけがわからなくならない程度になんとかなっていればよいはず

LOC 〜 104

  • 複数の機能があるアプリケーション
  • 全貌を完全には把握できなくなってくる
  • ふつう複数人で開発することにはなっていそうで, そのために CI にはコストが払われていてほしい
    • 機械的に型検査や lint はされていてほしい
    • 自動でテストが行われていてほしい
  • 何か破綻したときにすぐに一から作り直せるような規模ではないので, 設計は重要になってくるはず
    • LOC 〜 103 から成長してきたときは, 大きく改修は必要だとしても, 規模的になんとかはなりそう

LOC 〜 105

  • おそらく多数の機能があるアプリケーション
  • 全く把握できていない部分も出てくる
  • CI はないと成り立たないと思う
  • モノリシックな設計には限界が来る規模だと思われる
    • 全部把握すべき設計で把握できていない部分があるのではなく, 把握すべきところを絞った設計になっていて, そうでないところは全く気にしなくても良くなっていてほしい
    • LOC 〜 104 から成長してきたときに大きく改修が必要だと, 規模が規模なのでつらいことになりそう
      • なので成長が見込める場合はある程度は予期して設計おくべきなのであろう
    • つらい

LOC 〜 106

  • この規模のアプリケーションの開発経験がないのでよくわからないし, 想像もほとんどできない
  • みなさんはどのくらいの規模まで行けますか