# 目次
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び，
そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
本書の内容は，オープンソースモデルに従い，
ほぼ無制限で利用が可能です．
クリエイティブ・コモンズ表示3.0の条件下で，
自由に使用することができるのです．
つまり，どのエッセイも，
著者の名前を明記すれば，自由に転載，改変が可能であるということです．
ーー"はじめに"から抜粋 pXII
もし，他のエッセイを読みたい場合には，
記事末のリンクを辿るか，
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．
Twitter Account: 97 Things Bot
また，元の英文によるエッセイを読みたい方は，
こちらを参照して下さい．
Contributions Appearing in the Book - Programmer 97-things
14. コードレビュー マルティアス・カールソン (Mattias Karlsson)：『プログラマが知るべき97のこと』
コードレビューは一般的に「実施すべきもの」とされています．
なぜでしょうか．
コードの質を上げ，欠陥を減らすため
でしょう．
しかし，目的はそれだけとは限りません．
プログラマの中には，
コードレビューを毛嫌いする人が多くいます．
おそらく過去に，
コードレビューで何か嫌な経験をしたことがあるのでしょう．
全コードが会社規定のレビューを通過しない限り，
リリースを行わないという企業もあるようです．
こういうレビューを担当するのは，
大体，アーキテクト*1やリードディベロッパです．
「アーキテクトがすべてをレビューする」という慣習です．
そうすることが
企業の「ソフトウェア開発工程マニュアル」などで規定されていれば，
プログラマはその規定に従う他ありません．
そのような厳しく堅苦しいレビューが必要な企業も中にはあります．
しかし，大半の企業はそうではありません．
どうしても非生産的になってしまうからです．
この手のレビューを実施すると，
レビューを受けている側は，
まるで自分が軍法会議にでもかけられているように感じます．
またレビュー担当者はコードを読むための時間を確保しなくてはならず，
しかも対象システムの知識を細部に至るまで
最新の状態に保つことを強いられます．
レビューが工程の中でボトルネックになってしまい，
やがてプロセスそのものが瓦解してしまうことにもなりかねません．
コードレビューの目的は，
ただコードの誤りを修正するだけではありません．
重要なのは，
チーム全員に同じ知識を共有させること，
また，コーディングにおいて全員が守るべきガイドラインを確立することです．
自分が書いたコードを他のプログラマと共有することで，
「コードの共同所有(collective code ownership)」
が可能になります．
レビュー実施にあたっては，
担当者をチームのメンバから無作為に選び，
他のメンバの協力も得て，
順にコードを確認していく，
という方法を採るといいでしょう．
レビュー担当者は単に誤りを探すのではなく，
個々のコードについて学び，
理解することを心がけましょう．
レビューにおいては，皆友好的な態度をとるべきです．
コードについて何か意見を述べる時は，
建設的であるように心がけ，
辛辣な批判は絶対に避けましょう．
また組織内での上下関係がレビュー結果に影響することがないよう，
個々のレビュー担当者の役割，権限は予め明確に決めておきます．
例えば，ドキュメント担当，例外担当，機能担当といった具合に
担当範囲を分けるのがいいでしょう．
これは一人あたりの負担を減らすことにもつながります．
コードレビューは曜日を決めて実施するといいと思います．
その曜日には二時間ほどレビューミーティングをするのですが，
レビューの対象者となる人はミーティング毎に順に変えていきます．
一巡したらまた最初から，ということにすればいいでしょう．
レビュー担当者の役割もミーティング毎に毎回変えるべきです．
チームの中に新人がいる時には，
その人も是非，レビューに参加してもらいます．
新人には経験がありませんが，
大学を卒業して日が浅い分，
まだ学んだことがかなり記憶に残っているでしょう．
その知識のお陰で違った始点が得られる場合もあります．
もちろん，経験と知識が豊富な人に
レビューに加わってもらうべきなのは言うまでもありません．
彼らは，誤りの混入しやすいコードをいち早く，
しかも正確に見つけることができます．
さらに，コードレビューの進行をスムーズにするためには，
コーディングが常に一定のルールに従って行われる
体制作りも大切でしょう．
ルールが守られているかどうかは，
コーディング中にツールで自動的にチェックされるようにしておきます．
その体制ができていれば，
コードレビューでフォーマットについて議論する必要がなくなります．
おそらくコードレビューを成功させるために最も有効な方法は，
レビューを楽しいものにする
ことです．
レビューで最も大事なのは人です．
もしレビューが辛く退屈なものだったとしたら，
誰も進んでレビューに参加する気にはならないはずです．
できるだけくだけた雰囲気になるように心がけ，
主目的をメンバにー内で知識を共有することに
置くようにするといいでしょう．
厳しい言葉の飛びかうレビューより，
昼食やお菓子を食べながらのレビューの方がいいと思います．
■著者データ
[マルティアス・カールソン (Mattias Karlsson)]
金融分野のソフトウェア開発を主業務としているが，
スウェーデン，ストックホルムのJavaユーザグループのリーダとしても活躍している．
オブジェクト指向ソフトウェア開発に取り組み始めたのは1993年から．
それ以来，現在までの間に，
開発者，アーキテクト，チームリーダ，コーチ，マネージャ，講師など，
様々な仕事を通じて経験を積んできた．
特に，共に仕事をした人たちと刺激し合えたこと，
自分の仕事ぶりについて他人から意見を多く聞けたことが，
成長につながっているという．
Javaユーザグループでは，
年に6書いから8回ミーティングを開催しているが，
毎回200名を越える参加者で大盛況になっている．
その他，年に一回開催されるストックホルムで最大のJava専門カンファレンス，
Jfokusの運営にも関わっている．
リンク：Jfokus
休日には子供達と遊ぶか，バイクに乗ることが多い．
また恵まれない人たちの住宅取得を支援する団体，
「Habitat for humanity」
の活動に参加したり，
個人間の小規模融資のためのサイトKivaを支援したりもしている．
Kivaについてはサイトも参照のこと．
リンク：Kiva - Kiva Lending Team: Java users around the world
関連記事
1．分別のある行動 Seb Rose：『プログラマが知るべき97のこと』 - MY ENIGMA
2．関数プログラミングを学ぶことの重要性 Edward Garson：『プログラマが知るべき97のこと』 - MY ENIGMA
3．ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne：『プログラマが知るべき97のこと』 - MY ENIGMA
4．コーディング規約を自動化する Filip van Laenen：『プログラマが知るべき97のこと』 - MY ENIGMA
5．美はシンプルさに宿る Jorn Olmheim：『プログラマが知るべき97のこと』 - MY ENIGMA
6．リファクタリングの際に注意すべきこと Rajith Attapattu：『プログラマが知るべき97のこと』 - MY ENIGMA
7．共有は慎重に Udi Dahan：『プログラマが知るべき97のこと』 - MY ENIGMA
8. ボーイスカウト・ルール Robert C. Martin：『プログラマが知るべき97のこと』 - MY ENIGMA
9. 他人よりまず自分を疑う Allan Kelly：『プログラマが知るべき97のこと』 - MY ENIGMA
10. ツールの選択は慎重に Giovanni Asproni：『プログラマが知るべき97のこと』 - MY ENIGMA
11. ドメインの言葉を使ったコード Dan North：『プログラマが知るべき97のこと』 - MY ENIGMA
12. コードは設計である Ryan Brush：『プログラマが知るべき97のこと』 - MY ENIGMA
13. コードレイアウトの重要性 Steve Freeman：『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
*1:プロジェクト管理やソフトウェア開発の上流行程などを行う役割の人 ITエンジニアとしての道を究めるには（5）
