企業ではコードレビューが行われます。それは日常茶飯事です。実のところ、今日のコードレビューは、絶え間ない、粘り強い探求の長い道のりから生まれました。さまざまな技術、方法、ツールを試しながら、今日に至っているのです。
この旅の途中には、多くの落とし穴や危険があり、初心者が餌に食いつくのを待っています。この投稿はそれらについてです：コードレビューにおける落とし穴と誤解。
コード管理：
多くの企業が、コードを管理する方法としてコードレビューを利用しています。こうした企業の多くは、プレコミット戦略を採用しています。たいていの場合、この戦略は何百人、何千人ものコミッターがいるオープンソースプロジェクトで使われます。しかし、一般企業ではこのようなケースはほとんどありません。誰かを雇うということは、その人がコードベースにコードをコミットすることを許可するほど、その人を信頼しなければならないということです。プログラマーがコードを提出する前に「レビュー」と「承認」をしなければならないような規則を設けている会社もあるのは仕方がないことだとは思いますが、それではコードの品質は保証されません。さらに、プログラマーはすぐにコードレビューを「くだらない」会社の形式的なものとみなすようになり、抵抗するようになります。
裁判室：
コードレビューをスケープゴートや説明責任の道具として使わないでください。たとえば、バグがあったときに、そのコードを「レビュー」した人を見つけて、バグを見つけられなかったことを責めるような場合です。このようなことは、企業の開発業務に深刻な影響を及ぼしかねません。人々は、スケープゴートにされることを恐れて、セミコロンが正しく配置されていない箇所をいちいち指摘するようになります。チームメンバーは自信を失い始め、最終的には相互の信頼を失います。
[]
責任ある仕事：
プログラマーにコードレビューを過度に求めてはいけません。1日1時間もコードレビューを強制すれば、彼らはすぐに嫌いになり、退屈な仕事だと思うでしょう。コードレビューは学習の場であり、賞賛の場であり、フィードバックを得る場であり、とても社交的な活動です。コードレビューは楽しいものであるべきで、つまらないものにしてはいけません。
[]
まとめると、コードレビューを汚すミスはいろいろあります。上の4つは私が経験した、あるいは予想したものなので、くれぐれも注意してください。コードレビューはここにある......」という記事をまた書くことを約束します。コードレビューは「......」にやってくる "を説明する別の記事を書くことを約束します。
[]
コード・レビュー・ツールを試してみたい方は、経験と実践の結晶であるcodebrag.comをご覧ください。
