どこまで人のコードに口を出して良いか悩む件

とあるシステムに対する新規機能追加を二人チームで行っている。

私ともう一人のチームメンバーをAさんとしよう。 私はこの部署に来たのが初めてのため、この部署特有のルールについてはまだ勝手がわからないことが多い。

Aさんはこの部署での経験は１年ぐらいあり、同様の機能追加の開発経験もある。

というAさんだが、ソースを見ると気になる点が幾つかある。 それを伝えるべきかどうかすごく悩む。

もちろんバグであったり、開発規約に反しているものは当然伝えれば良いのだが、コーディングスタイルの範囲と言えなくもない微妙なところ、例えば下記のようなところをどうしようか、最近迷うことが多い。

• わざわざメンバ変数にしなくてもそれローカル変数で良いじゃん
• 冗長な処理がダラダラと続いているのでメソッドに切り出した方が良いのでは
• Controllerが肥大化しすぎている。そのロジックはModelに書いた方がスッキリするのでは
• メソッド名が妙に冗長
• かと思えば、そこは略さなくても良いのではというところを略す（createをcrtとか、sendをsndとか）

というようなところはバグではないのだけど、なんかモヤっとして伝えるべきか伝えないべきか悩む。

コーディングは人それぞれ流儀みたいなものもあるし。

指摘してAさんが気を悪くしたら、今後やりづらいし。

ちなみに現在部署的にはレビューは「推奨」はされているけど必須ではない。

前職でSIの現場にいた時コーディング含めてレビューをするのが必須であり、レビューをするのは基本的に上の立場の人であった。リーダーであったり、また役職はなくても職位が上の人がするものであった。

今の開発体制は基本的にフラットであり、明確にチーム内に序列はない。リーダー的な役割の人はいるが、各メンバ間に上下関係はない。

会社によるのだろうが、自社で製品やサービスを開発しているところは、そういうところが多いのだろうか。 WEB開発の現場とかで、レビュー担当を週替わり持ち回りでやっているなんてのをたまに聞くので、そうなのだろうと勝手に思っている。

ここまで書いて思ったが、細かいところを指摘する前に、まずはレビューをするということ、そしてレビューの基準を明確にして全体でコンセンサスをとる、ということが先決な気がしてきた。そういう前提があれば指摘を受ける側も、悪い風には受け取らないだろう。そうやってレビューをする文化を作っていけたら良さそうである。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

WEB+DB PRESS Vol.72