「この処理を書けたら教えて、レビューするから。」
この言葉を言われると、今でも少しドキドキしてしまいます。
プログラミング初心者の自分にとっては、
書いたコードをボコボコに指摘される！と恐怖していました。
プログラマーの皆さんの中にも、共感いただける方がいると思います。
要は成果物をチェックしてもらうだけなのですが、
プログラマーとそれ以外では意味合いが違うように感じます。
何が違うのかを考えていたところ、
初心者にどうしても伝えたい気付きを得たのでまとめてみました。
コードのレビューとは？
コードを書いたら基本的には上司にレビューしてもらうことになります。
「コードのレビュー」をもう少し細かく説明すると、
「作成したコードを確認してもらって指摘があればここを修正する、
それを指摘が無くなるまで繰り返すこと。」
と言えます。
例えば、電卓機能を作ってと言われたとします。
プログラマーは設計書に書かれた「ここはこうしてほしい」という仕様を確認しながら、
足し算の処理や数値のリセット処理などを作っていくわけです。
そして作成したコードを上司にレビューしてもらい、
「コードが文法的に間違っている！」
「ここの処理が仕様と違う！」
「画面の色や文字の大きさがイマイチ！」
「違う書き方の方が見やすくて処理も早くなるから直して！」
といった指摘をもらうことになります。
上司がOKと言うまで何度も直して、OKが出たらレビュー完了となるのです。
レビューでの指摘をタイプ分け
レビューの中で様々な指摘を受けることになりますが、
その指摘は大きく4つのタイプに分けられると考えます。
①技術的な指摘（低レベル）
例で言うと「コードが文法的に間違っている！」
書いているプログラミング言語の理解が足りていないことや凡ミスなどが原因です。
②資料が読めていないことへの指摘
例で言うと「ここの処理が仕様と違う！」
設計書やコーディング規約といった資料の確認漏れなどが原因です。
③空気が読めていないことへの指摘
例で言うと「画面の色や文字の大きさがイマイチ！」
レビューをお願いしている人との感覚のズレや、
ルール化されていない暗黙のルールが共有されていないことなどが原因です。
④技術的な指摘（高レベル）
例で言うと「違う書き方の方が見やすくて処理も早くなるから直して！」
求められているプログラムの質に対して言語の理解が足りていないことや、
他のプログラマーが読みやすい書き方がされていないことなどが原因です。
①と②の指摘を受けるということは、
最低限の「一応正しく動くコード」作成すらできていないことになります。
怒られたり印象が悪くなったりするので、レビュー前に念入りに確認しましょう。
③と④は多少しょうがない部分があります。
伝えられていない内容を知ることは難しいですし、言語の深い知識もすぐにはつきません。
「一応正しく動くコード」から「読みやすく質の高いコード」にするための指摘であり、
指摘をする側もアドバイス程度の気持ちで怒ってはいないでしょう。
書き方の確認やコミュニケーションを多くとり、
少しでも空気感やルールを聞き出して指摘を減らす努力はしましょう。
これらの違いが初心者の内は切り分けが難しいと思います。
筆者もレビューで沢山の指摘をもらった時に、
「受けた指摘は全て自分のミスが原因」
「指摘が無いようみっちり確認しなければ」
と泡を吹いていました。
適当に作れというわけではありませんが、そこまで気負うことはないと思います。
また、②や③はチーム作業だからこそもらう指摘です。
規約や暗黙のルールなどはそのプロジェクト特有のものですので、
もちろん検索して出てくるようなものではありません。
その点においても確認やコミュニケーションは重要です。
プログラマーにおけるレビューの意味合い
最後にもう１つレビューについて。
初心者にも「一応正しく動くコード」作成は最低限求められます。
プログラマーは技術を売る仕事であり、技術があることが前提であるからです。
当然、技術が無い技術者には誰もお金を出したくなりません。
派遣的にお客さんの元に働きに出向いているプログラマーは尚更です。
そんな前提がある中で「動かないコード」をレビュー依頼するのは、
お金を払う価値のない技術者ですよと自分からアピールすることと同じです。
ただし逆もまた然りで、「質の高いコード」を作成できる優秀な技術者ですよと
アピールをするチャンスとも捉えられます。
プログラマーに限らず、実力主義の職種における成果物の確認依頼は
自身の能力を上司に確認される試験のような意味合いがあると考えています。
過度に気負う必要はありませんが、気合は入れるべきです。
まとめ
初心者の方に求められていることは、
・一応でも資料通りの動作ができるコードを書くこと。
・その上で判断に迷ったら聞くこと。
・最低限動くコードを書くこと。
まずはこれらを徹底することだと筆者は考えます。
それができているなら自信を持ってレビューしてもらいましょう。
そして沢山の指摘をもらって、もらった指摘の分だけ知識を付けていきましょう。