どこまで人のコードに口を出して良いか悩む件
スポンサーリンク
とあるシステムに対する新規機能追加を二人チームで行っている。
私ともう一人のチームメンバーをAさんとしよう。 私はこの部署に来たのが初めてのため、この部署特有のルールについてはまだ勝手がわからないことが多い。
Aさんはこの部署での経験は1年ぐらいあり、同様の機能追加の開発経験もある。
というAさんだが、ソースを見ると気になる点が幾つかある。 それを伝えるべきかどうかすごく悩む。
もちろんバグであったり、開発規約に反しているものは当然伝えれば良いのだが、コーディングスタイルの範囲と言えなくもない微妙なところ、例えば下記のようなところをどうしようか、最近迷うことが多い。
- わざわざメンバ変数にしなくてもそれローカル変数で良いじゃん
- 冗長な処理がダラダラと続いているのでメソッドに切り出した方が良いのでは
- Controllerが肥大化しすぎている。そのロジックはModelに書いた方がスッキリするのでは
- メソッド名が妙に冗長
- かと思えば、そこは略さなくても良いのではというところを略す(createをcrtとか、sendをsndとか)
というようなところはバグではないのだけど、なんかモヤっとして伝えるべきか伝えないべきか悩む。
コーディングは人それぞれ流儀みたいなものもあるし。
指摘してAさんが気を悪くしたら、今後やりづらいし。
ちなみに現在部署的にはレビューは「推奨」はされているけど必須ではない。
前職でSIの現場にいた時コーディング含めてレビューをするのが必須であり、レビューをするのは基本的に上の立場の人であった。リーダーであったり、また役職はなくても職位が上の人がするものであった。
今の開発体制は基本的にフラットであり、明確にチーム内に序列はない。リーダー的な役割の人はいるが、各メンバ間に上下関係はない。
会社によるのだろうが、自社で製品やサービスを開発しているところは、そういうところが多いのだろうか。 WEB開発の現場とかで、レビュー担当を週替わり持ち回りでやっているなんてのをたまに聞くので、そうなのだろうと勝手に思っている。
ここまで書いて思ったが、細かいところを指摘する前に、まずはレビューをするということ、そしてレビューの基準を明確にして全体でコンセンサスをとる、ということが先決な気がしてきた。そういう前提があれば指摘を受ける側も、悪い風には受け取らないだろう。そうやってレビューをする文化を作っていけたら良さそうである。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本(ソフトカバー)
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (140件) を見る
- 作者: 近藤宇智朗,生井智司,Dr.Kein,tokuhirom,森田創,中島聡,堤智代,A-Listers,はまちや2,竹原,川添貴生,久保達彦,道井俊介,飯田祐基,中村知成,規世やよい,後藤秀宣,天野祐介,奥野幹也,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2012/12/22
- メディア: 大型本
- 購入: 11人 クリック: 94回
- この商品を含むブログ (10件) を見る