めずらしくお仕事の話です。ソフトウェア開発の現場ではレビューがよくあります。
それは設計書のレビューだったり、コードレビューだったり色々です。
誰かが作ったモノを、他の人が見て、改善したほうが良いと思う部分を指摘します。
このレビューですが、大体の人が嫌いだったりします。自分の作ったモノを他の人にアレコレ言われるのは良い気がしないですからね。
レビュー嫌いは人間として当たり前のことでしょう。技術者は意地悪というか、優しくないというか、あまり他人の気持ちを考えない人が多いですし。
レビューは、レビューする人によって観点が違うことがけっこうあります。というか、今まで私が経験してきたレビューでは100%そうです。
本当は、レビューでどんなことを指摘してほしいのか？何を見るべきなのかをちゃんとプロジェクトメンバー内で意識合わせして実践する方がいいのですが、理想論です。
そんな現場は無いのです。いやどっかの技術レベルバリ高なプロジェクトではあるのかもしれませんが、私にとっては異世界のことなので無いのと同じです。
今の現場はコーディング規約すらないですからね。そもそもコーディング規約に沿っているかどうかのチェックは人間がやるべきじゃないですけど。
そんなこんなで私がレビューする側の場合、意識している観点は「お金かけてでも直したほうがいいか」です。
お金を払うのはクライアントです。私はクライアントに雇われたフリーランスエンジニアなので、クライアントの幸せのために仕事をするべきです。
レビューで指摘すると、修正方法について議論したり、そもそも修正が本当に必要なのか！？みたいな口論のような状況が生まれます。
で、なんやかんやあーだこーだ言って、最終的に修正することになったとしましょう。その成果物に、そこまでに掛かった時間に対するお金が見合うのかどうかです。
コードレビューの場合、明らかなバグは指摘します。そのバグを放置すると、後からもっとお金が掛かる事態がやってくるからです。
テスターの人がテストして、バグが見つかって、開発担当者に連絡が来て、バグの再現確認をして、バグを修正して、テスト済みだった他の部分についても影響範囲であればテストやり直しです。
それを考えるとコードレビューの段階で潰しておくべきですよね。当たり前のことです。
でも、変数名や関数名が変だったり、同じ処理が2箇所に分かれて書かれていたり、インデントが揃ってなかったりはスルーします。
別にお金掛けて直すほどでも無いと思うから。もし私がクライアントで「変数名直すのに5千円掛かりますけどいいですか？」って聞かれたらそのままで良いって言うもん。
同じ処理も10箇所あるならまとめて関数化しろって指摘しますけど、3箇所ぐらいまでなら別にいいんじゃないかと思います。
コスト意識って大事だと思うんですよね。なんせ私ケチですし。
なるべくコストは抑えたい派です。
ってやってると、なんか私がレビューした時だけ指摘が少ないんですよね。
なんかちゃんとレビューしてないみたいに見られてるかも！？