コードレビューをするときには、フォーマットや慣例的な書き方とか、名前ちゃんとした方が良いよとか、処理にも名前をつけようねとか、そういうことは伝えるんだけど。それよりももっと気にするのは、「ここで見つけておかなきゃいけない」ってことだなぁってふと思ったのだった。
ここで見つけておかなきゃいけないこと?
仕様に従ってるかどうかとかは、動かしてみれば分かるし、PDM(Product Manager)が受け入れテストとして見てくれたり、QAと呼ばれるテストのチームがやってくれたりもする。ので、そこまで気にしてない。
気にするのは、エンジニアがソースを読むことでしか見つけづらいバグ。かな。特定の条件が重なったときにだけ発生するようなやつとかそういうの。10msのタイミングで発生するとか、12/31の0時にだけ発生するとか、エラーが発生したときにだけ発現するとか、今は大丈夫だけど2年後ぐらいに発火する爆弾とか。
で、そういうのって、知ってるか知らないかということも多くて、知らない人がどれだけ頑張って読んでも知らないから気づけなかったりする。ので、自分が知ってることはできるだけ、伝えていった方がいいんだろうなって。思ったり。
で、具体的には？
って、ここまで書いといて、特に何も考えてないんだけど・・・。
適当に思いついた順番で
- 文字列の比較に==使わないでね
- オートボクシングのぬるぽに気をつけて！
- intどうしを割り算してもintにしかならないんよ
- 金額の計算にはfloatやdoubleじゃなくてBigDecimalを使うんよ。誤差が出るから。
- 1つの処理の中で現在日時をその都度取得してたら、時間がずれるよ
- このデータ量だとintが1年後にあふれるかも？
- longでマルチスレッドあぶないんじゃないっけ？ってかマルチスレッド使うときは落ち着いて考えよう（僕が
- guavaのTransformはその場で作られてるわけじゃないから変更するときは気をつけて
- SimpleDateFormatはスレッドセーフじゃないからstaticで持たないでね。てかJava8のDateTimeFormatter使おう。
- フォーマッターのyyyyをYYYYって書くと年末に死ぬから気をつけて
- SpringのComponentのスコープはデフォルトでSingletonだから状態を持たないでね
- DBのトランザクションの分離レベルどれにしてる？
- とか、どこのレイヤーで開始してる？てか、開始してる？
- コミットせずにクローズするとロールバックされる？コミットされる？
- ログの内容が実際に発生したやつと違うよ？
- ここで例外が発生したらログを出そうとしてるけど、メッセージ作るところでぬるぽになりそう？
とかとか。また思いついたら適当にメモっとこっと。
(2017-10-22 追記) @irofさんありがとー
