クソコードに対する怒りとコードレビューにおける人格攻撃について
7つの秘訣の1〜5は本当にそのとおりだと思います。
「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。
「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。
じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒りを覚えることはあるし、プロフェッショナルであるからこそ怒る部分もあると思う。
「エンジニアと怒り」で思い出すのは@r7kamura氏が「ぶつかり稽古」で発表した「勤労と感謝とプログラム」である。
スライドからは推し量れないが、彼の狂気と本気が詰まった非常に素晴らしいプレゼンだった。本当はもっと素晴らしいプロダクトになるはずだったものがクソコードの山になってしまったことによる怒りをパワーに変えて一日でChankoを書き換えた話などをしていた。
あんちぽさんのblogエントリに的確な表現があったので引用させてもらう。
好きすぎて憎い、そんな思いが爆発して「一日で作りなおす芸人」と成り果ててしまった彼の異常な高意識
「怒り」というものは元々好きだからこそ相転移で発生することもあり、それが力の源にもなることもある。そういう意味では重要な感情でもある。
また「怒り」ってのは自分や他者がそういう感情を抱いた時にそこを深堀りすると自分や他者のことを知ることができるチャンスでもあると思ってる。
「怒る」ことへのスタンスは僕は前職で結構変わって、以前は「怒る」のは絶対ダメだと思ってたんだけど、今はそういう感情も共有してこその良いチームなのでは無いかとか感じるようになっている。
なんでコードに対して怒りを覚えるかというと以下の2つがあると思う。
- 汚いものを見たことに対する怒り
- きれいなものを汚されたことに対する怒り
前者は分かりやすい話だが、大きな怒りにつながるのは後者の方だと思う。
汚いものを見たことに対する怒り
もっと細かく分解すると以下の様なものがある。
- メンテ不可能なコードに対する怒り
- 意図がわからないコードに対する怒り
- 設計や命名、テスト等の考慮不足に対する怒り
- 書いた人の無知に対する怒り
こう書くと、単にコードに対する美的感覚だけの問題ではなくて、どうしたって書いた人間の否定につながってしまうことがあるのが分かるのではないか。
単にスキル不足だったら許せるかもしれないが、明らかにいい加減で考慮不足でテスト不足な責任放棄的なコードを見てしまったら、書いた人に対して怒りを覚えてしまうこともあるだろう。
スキル不足だったら仕方がないかというと、大半はそれで済むんだけど、中には「知らなかったでは済まされない」ような「無知は罪」とか言いたくなるような「明らかな勉強不足」みたいな問題もあったりする。
余り良い例えがすぐには思いつかないんだけど、例えば以下の様なもの。
ORDER BY RAND()- URL操作したら丸見え
- ダメな正規表現(ネットからコピペとか)
- コピペまみれ
単発だったら良いけど、明らかに勉強不足で典型的な地雷を踏みまくったりすると「ちょっとは勉強しろよ」とか怒りを覚えてしまうことはあると思う。
自分が昔踏んだ地雷だったり、自分が書いてしまったクソコードだったら許せるとかそういうの人間ぽいとか思ったりする。
ただ、この項目に関しては「怒り」までに行くことはそこまで無いとは思ってる。
きれいなものを汚されたことに対する怒り
怒り度合いはこっちのほうが大きくなりうるのではないかと思う。例えば以下の様な話である。
- 綺麗な設計を、設計の意図を汲み取らない筋の悪いコードによって乱される
- もっと良いプロダクトになるはずだったものが、そうなってないことに対する怒り
- 前提が覆るような仕様変更が発生して、コードが汚くなることが避けられないことに対する怒り
責任感やプロダクトに対する愛情や思い入れが逆に怒りにつながることがある。その人がどういうところに怒りを覚えるかって言うのを把握しておくのは重要なポイントだと思っている。
あと、どうしても「人に対して」怒りが向かってしまうこともあると思うので、自分の心を整理することも大事。
「優れたプログラマがコードレビューをする」ということについて
別の話になるが、冒頭の資料は「優れたプログラマがコードレビューをする」というところに話が偏っていると少し感じている。もちろん、レベルの低い人を底上げすることでチーム全体のレベルアップを図る、教育的な観点でのコードレビューと言うのもコードレビューの一つの目的だとは思う。
では、全員のレベルが同じであればコードレビューは不要かというともちろんそんなことはなくて、それは他にもメリットはあるからである。それは以下の様なものが上げられる。
- 見る目を増やしてバグの発生率を抑える
- 議論をすることでより良いコードにする
- 開発プロセスが可視化される
- 開発チーム全員がコードベースやプロダクト全体に責任をもつ
- 結果的にチームがフラットになる
1は当たり前過ぎて取り上げてなかったのだと思う。2はディスカッションしましょうと言ったトピックもありそのとおりだと思う。
僕は最近は3番目以降が多少理想的な話にもなるが大事だと思っている。それが結果的に強いチームと良いプロダクトを生み出すことになるはずである。なので、必ずしもレビュアー・レビュイーの間に上下関係は必要ない。レビュアー・レビュイーの上下関係を厳密に決めてしまうと、潜在意識的にもどうしてもヒエラルキーの固定化が起こってしまい、フラットなチームからは遠ざかってしまう。
ベテランにコードレビューを優先的にふるのか、ランダムにするのか、バランスを取るのが難しいですが、そのあたりの試みに関しては、GitHub Kaigiのはてなブログチームの開発フローとGitHubというトークがすごく参考になった。