自分の書いたコードを人に見せるということ

スキル

» 2012/08/13

■大ソーシャルコーディング時代

　GitHubの台頭により、ソースコードをオンライン上に共有するということが、たいへん簡単な時代になりました。

　TwitterやFacebookなどを見ていると、毎日のようにエンジニアの書いたソースコードへのリンクを目にすることができます。

　わたし自身、自分の書いたソースコードは、可能な限りたくさんの人に見せるべきだと考えています。

　エンジニア同士、コードについてのノウハウを共有することはよりよいプロダクトを作る礎となりますし、なにより自分の成長を劇的に促進してくれるからです。

　今回はこの、「コードを人に見せるということ」について考えてみたいと思います。

■コードレビューが苦手だった

　職業プログラマが、最初に自分の書いたコードを誰かに見せる機会というのは、おそらくコードレビューでしょう。

　わたしが職業プログラマになって最初に書いたコードは、COBOLによるものでした。ソースコードを紙に印刷し、それを設計担当者に渡します。しばらくすると、紙のソースコードにラインマーカや赤ペンで修正箇所や、改善のアドバイスが書かれて戻ってきます。

　これが、わたしの初コードレビュー体験でした。

　次に経験したのは、会議体によるコードレビューです。

　プロジェクタにコードを映し、処理の流れを説明します。途中で、実装の意図に関する質問や改善の指摘などを受け、その場で修正したり、コードにコメントを書いたり、大きな修正は手元のノートにメモをとったり、そうやってレビューは進んでいきます。

　わたしは、この形式のレビューが苦手でした。

　この頃のコードレビューというのは、自分がまだ新人に近いということもあって、レビュワーはすべて自分より職務的に上位に位置する人々です。先輩とか、チームリーダーとか、そういう人たちです。客先常駐をしている場合など、自分にとっては顧客となるメーカーのエンジニアがレビュワーになることもあります。

　こういった形式のレビューは、自分がなにやら糾弾されているようで、とてもリラックスして臨めるような雰囲気ではありませんでした。

　コードレビューを意味あるものにするためには、必要なことがあります。

　それは、レビューの場で指摘する対象はあくまでソースコードであって、それを書いた個人ではないということです。

　コードレビューは、ソースコードに対するプログラマ同士の意見交換の場で、コードや、それを書いた個人を糾弾する場ではありません。いくらその場で書かれたコードにバグがあっても、その結果を、書いた個人の査定評価などに用いるべきではありません。そんなことをすれば、誰もコードレビューなど望まなくなってしまうからです。

　そういう原則を皆わかっているとはいえ、なかなかそれを徹底するのは難しいでしょう。同じ指摘が何度も続けば、人は段々とイライラするものです。あまりに基本的なことができていないコードを目の当たりにすれば、それを書いた個人の能力を疑ってしまう気持ちも生まれてしまうでしょう。そういう気持ちを、会議体のレビューの場で面と向かってぶつけ合うことになれば、場にはどうしても緊張感が生まれてしまいます。レビュワーが自分よりも上位の人ばかりとなれば、なおさらです。

　わたしはこういうレビューが苦手でした。

■社外にコードを公開するということ

　こういった経験から、わたしは「コードを人に見せるのは怖いことである」という感覚を持っていました。

　ブログを書き、GitHubやGistにコードを公開することもありますが、いつも最後の「公開」のボタンをクリックするときは手が震えていました。

　自分のコードをdisられたらどうしよう。「あいつ、偉そうな事いつもブログとかで書いてるけど、大したコード書けないじゃないか」とか思われたらどうしよう。

　コードを公開するときは、何度もためらいながら最後のボタンをクリックしていました。

　それでも、コードを公開することをやめようと思わなかったのはなぜでしょう。

　それは、自分が目標とするエンジニアたちが、コードを公開しているからです。コードを公開することは良いことだと、頭ではわかっているからです。だからわたしは恐怖と戦いつつも、「コードの公開を止める」という選択肢は選びませんでした。

■コードを人に見て欲しいと思えるようになった

　わたしは今年の2月に転職をしました。

　今の会社ではペアプロによる開発を行なっています。2名で1組のペアを作り、コードを実際に書く人と、それを後ろから見ながらアドバイスをしたり相談を受ける人、という役割を交互にこなします。

　つまり、コードを人に見られるどころか、自分がコードを書いている様子をリアルタイムで人に見られるわけです。

　入社後、初めてのペアプロはとてつもなく緊張しました。まだ「コードを人に見られるのは怖い」という感覚をこの頃は持っていました。しかし、「コードを人に見せること」はいい事だし、ペアプロは質の高いコードを書くために有効な手段だと思っているから、わたしはこの開発手法を採用している会社に転職したのです。あとは、それを怖気づかずに実行する勇気だけです。

　ペアプロの他に、今の会社では複数の手段でコードレビューをします。会議体によるレビューもしますし、オンラインコードレビューといって、コードレビューを行うためのツール上でコードを公開し、チームメンバーが空き時間に意見や指摘をコメントとしてツール上に記入するというものもあります。

　こういった環境で、常にメンバーに自分のコードを見られ、自分もメンバーのコードを見るという生活を続けるうちに、「コードを人に見られる」という抵抗はなくなりました。

■コードレビューで大切なマインドは「お互いさま」

　いま、わたしは他人にコードを見られることに対して以前ほどの抵抗はありません。それどころか、少し複雑な処理を書いたときなど、本当にこの実装で問題がないかどうか、積極的にチームメンバーに見て欲しいとすら思います。

　軽微な修正など、ペアでなくシングルでコードを書くときもありますが、それでも少し自信がないコードについては、メンバーに自分からコードを見せて意見を求めることもあります。

　ブログでコードを書いて、それに対して少し辛辣な意見がTwitterなどで寄せられたとしても、「うわーdisられた！」ではなく「あー。なるほど。有り難い！」と思えるようになりました。

　このマインドの変化は、どのようにして生まれたのでしょうか。

　最も大きな理由は、「自分のコードを見られる」ということよりも「他人のコードをたくさん見る」という事が大きいと思います。コードレビューが活発な文化では、コードを積極的に見せ合うことになります。
　チームメンバーから、「ここは少し1人では不安なので、一緒に見て欲しい」という依頼を受けてコードを読むこともあります。

　そうすると、あることに気づくのです。

　コードを見られるのが恥ずかしい理由の1つに、「つまらない実装をしていると思われたらどうしよう」というのがあります。でも他人のコードを読むと、それが取り越し苦労であることがわかるのです。

　どんなに優秀でも、人間である以上ミスはします。ペアプロや、頻繁なコードレビューをしていれば、チームメンバーだって、自分がやるようなイージーミスをしてしまうものだと気づきます。でも、だからといって自分はメンバーに対して、「つまらないミスをしやがって」などと思うでしょうか。思いませんよね？

　たとえば、不等号の向きを逆に書いてしまうというようなミスをレビューで指摘されて、確かにそれは少し恥ずかしいことですが、同じようなミスは誰だってします。チームのエースと呼ばれるようなプログラマであっても同様のミスをします。それを見つけ出し、バグになるのを未然に防ぐのがペアプロであり、コードレビューの役割なのです。

　わたしは他人のコードをたくさん見ることで、それに気づくことができました。

　自分のコードを見られることは恥ずかしくない。自分のコードのミスを指摘されることは恥ずかしくない。

　それは、お互いさまなのです。自分がやるミスは、他人もやる可能性のあるミスなのですから。

　可能な限り、メンバーとソースコードの見せ合いっこをしましょう。そして、敬意を払って、それをレビューしましょう。

　自分の書くコードの質は、それだけで劇的に向上するはずです。