私は会社の開発を改善する役割を与えられました。私が最初に始めたかったのは、コードレビューでした。

弊社には3人のプログラマーがいます。私はWebプログラマーです。私の既知の言語は主にPHP、ActionScript、JavaScriptです。他の2人の開発者はVB.netで内部アプリケーションを作成します

ここ数週間、コードレビューを行っています。VBコードを理解するのは難しいと思います。だから彼らが何をしているのかを言うとき、ほとんどの部分で私は彼らの言葉を受け入れなければなりません。

間違っているように見えるものを見つけた場合は、自分の意見を説明し、私が知っている言語の1つでどのように対処するかを説明します。

時々 、私の提案は歓迎しているが、「これはそれを行うための最善の方法であるように、多くの時間が、私は物事を聞いています。この」には適用されませんまたは言語「このまたはそのような性質の似たもの言語」。

これは真実かもしれませんが、言語を知らずにこれらの主張を確認または反論する方法がわかりません。

可能な解決策の1つはvbを学習することであるため、より良いコードレビューを行うことができます。私は本当にvbを学ぶことに興味がありません（特に自分のプロジェクトで学ぼうとしている他の技術のリストがあるので）そしてこれを最後の手段として残したいのですが、それはオプションです。

私が思いついた別のアイデアは、彼らは両方ともC＃に興味があり、私もそうです。しかし、それは私たち全員にとって新しいことです。私たち全員がペットC＃.netプロジェクトで協力し、それからお互いのコードをレビューすることの利点について考えました。

コンサルタントを雇ってコードレビューを提供する可能性もあると思います。

この状況で私が何をすすめますか。

他のことを学びたいというあなたの個人的な欲求は、あなたの仕事のために今あなたが実際に必要とするものを学ぶことに後席を取るべきです。VB.netをご覧ください。たくさんの質問をすることで、それが入っている言語を知っているときに理解できないコードを効果的にコーディングできます（通常、それは、その言語を知っていて、何をしていて、なぜ）。ただし、コードを理解していない場合、できることは、彼らにそれを説明してもらい、それを説明する過程でバグを見つけてもらいたいということです。レビューで自分のコードにバグを見つけたわけではありませんが、それはコードレビューの最も効果的な方法ではありません。コードレビューは仕事の一部になり、対処し、効果的に実行するために必要なことを学びます。

あなたが学習している間、彼らがこの言語でそれを行う方法ではないことをよく言ったら、それを使用するのが良いテクニックであると言うソースを見せてください。コードレビューであなたを正当化するのは、その逆ではなく、彼ら次第です。また、これらのリンクが表示されるようになれば、言語が上手になります。

実際、私は上記のすべてに同意しません。JS / PHP / ActiopnScriptを使用すると、プログラミング言語の機能とその機能について基本的に理解できます。実際、VBとJSには多くの類似点があると主張します。しかし、それは私のポイントではありません。あなたが言語に非常に精通していても、他の誰かの思考プロセスを追おうとするとき、何かを見落とすのは簡単です。そのため、レビューで何をすべきかは、プログラマーが何をしたのか、理由を説明する機会を提供することです。

友人はかつてこれを「管理人理論」と呼んでいました。誰か、誰でも、管理人でさえも詳細を説明することで、プログラマーはコードの弱点を自分自身にさらします。これはもちろん、レビューの究極の目標ですプロセス。ただし、コードを徹底的かつ率直に説明する必要があります（開発者が防御的である場合、レビューは機能しません）。

ショートバージョン

1. コードレビューは、レビュー対象者とレビュー担当者の両方が学ぶ機会であることに注意してください。
2. 質問としてのフレーズフィードバック。
3. 知識の不足がフィードバックを提供するのを妨げないようにしてください（＃2を行っている限り）。
4. 「好みのレビュー」を避けるか、少なくとも自分の個人的な好みであり、必ずしも同意する必要がないことを明確にしてください。
5. 「アームチェアコードレビューア」ではなく、パッチを提出してください。

長いバージョン

まず第一に、コードレビューはレビュー対象者が学ぶ機会ではないことを忘れないでください。また、レビュアーが学ぶ機会でもあります。実際、私は、新しいプログラマーがコードのレビューを始めて、コードの雰囲気をつかむことができるようにする組織をいくつか聞いたことがあります。

これを念頭に置いて、コードレビューのアドバイスが1つありますが、これは私が常に一般的に有用であることがわかっていますが、特にあなたの立場に関連しています。声明ではなく質問の形でフィードバックをフレーズします。言い換えると、「このコードはダメだ！」と言う代わりに、「なぜコードを書く代わりにこのように書いたのか...」と言うことができます。これにより、コードレビュープロセスがより快適になり、学習も可能になります。

私があなたに持っているもう一つのアドバイスは、あなたの知識の不足があなたを落胆させないことです。自分が間違っていると感じたものを見て、レビュー対象者から手を振るような回答を受け取った場合は、（少なくとも知識不足のために）引き下げないでください。ある言語で優れたコードを作成することは、他の言語で優れたコードを作成することとほとんど異なることはありません。はい、特定の言語には、良いコードを書くのに役立つさまざまなイディオムがあります。しかし、これらのイディオムは、それ自体が目的ではなくツールであることを認識することが重要です。

次に、「選好レビュー」を行わないようにしてください。これは私（および他の多くの人）が非常に意識的な努力をしなければならないものです。言い換えれば、「あなたはxをしましたが、私はyを好みます」という行に沿ったレビューをしないようにしてください。今、好みを述べることに何も問題はありませんが、それらに明確にラベルを付け、相手が自由に意見を異にすることができることを書き留めてください。これは重要です。言語ごとに異なるもののほとんどがこのカテゴリに分類されるためです。

最後に、分散バージョン管理システムを使用していますか？役立つ可能性のあることの1つは、コードの何が問題なのかを単に書き留めるのではなく、コードの書き方を書き直し、テストし、そのパッチを提出できる場合です。これにより、「アームチェアコードレビュアー」になるだけでなく、コードの改善に本当に関心があることを示し、言語をよりよく学ぶ機会が得られます。加えて、「これを行うべきだと思う」に同意するのは、通常、「これは私がどのようにしたか、あなたが同意する場合はパッチです」よりも簡単です。これには必ずしもDVCSが必要というわけではありませんが、確かに役立ちます。

問題への集中を失い、貧弱なソリューションを思いついた。開発を改善するタスクが与えられました。あなたの解決策は、言語を理解していないコードレビュー担当者（自分）を配置することです。コードをレビューしているのは誰ですか？なぜあなたは言語を学ぶまでお互いをレビューできないのですか？

より迅速に改善するために選択できた可能性のある他の問題領域がなければなりません。この方法では、彼らはあなたに煙を吹きかけるだけで、何も改善されません。

誰もが理解できない言語（C＃）に新たな開発を向けることは、特に皆さんが悪い習慣を持っている場合、成果を上げるのに長い時間がかかります。

設計に焦点を当てます（言及されています）。現在のコードの維持が困難な場合は、VBのリファクタリングツールを調べてください。基本的なプラクティスの多くは同じです。

本当に分からないことを「校正」することはできますが、十分にレビューすることはできません。私はCで非常に有能であり、C ++をかなりよく知っていますが、C＃でレビューすることを夢見ていません。

一部の企業は、大量のテストを使用してコードを実行し、何が問題なのかを伝えることを専門としているため、コンサルタントを連れて行く必要はないと思います。

それでも、結果を解釈する言語を知っているのは個々の開発者次第です。たとえば、コードレビュアーがの戻り値を使用しないことで私にうんざりした場合、私printf()はそれらを奇妙に見て、彼らの冷静さを疑問視し、「OK助けてくれますか？」

あなたが考慮したいと思うのは、部門やチームリーダーを設定することについて上司に話しかけることです。そうすれば、あなたのドメインで効果的になり、他の誰かがそのドメインで効果的になります。

それでも、監査にサードパーティを使用できる可能性があると思います。彼らの塩に値するほとんどのプログラマーは、たとえ私の例のように半分を偽物として却下したとしても、正当な懸念に注意を払いprintf()ます。

あなたが理解していないことについてのガイダンスを提供することは、あなたがよく知っているように盲人を導く盲人に似ています。

1つのアプローチは、コードベースの静的解析フロントに対処するFxCopやStyleCopなどのlintツールを使用することです。これは、ツールから生成されるレポートを議論するための出発点を提供します。

別のアプローチは、コードレビューをデザインレビューに変えることです。デザインレビューは、コードが書かれる前に問題を発見しないことが多いです。プログラマーがデザインを持っている場合、彼らは一般的にアプローチがはるかに効率的であり、これによりバグが減少します。デザインが存在しない場合、そのアプローチはアドホックになり、バグの数が増えてコードが損なわれます。コードレビューで問題が表面化する前に、各ユーザーが実装する具体的な設計を持っていることを確認して、問題をキャッチします。UMLはここであなたの友人であり、umletなどのツールは高速で使いやすいです。

悪いニュースは、コードレビューに効果的に参加するために、VBを学ぶ必要があることです。また、何らかのプロジェクトでVBを使用することも役立ちます（必ずしも本番用ではありません）。

幸いなことに、これを行った後、C＃に移行するときに学んだことの一部はまだ有用です。

ピアレビューを行うときは常に維持するべきだという考えは次のとおりです。

「私はこのコードを維持する次の人です！」

レビューの準備の一環としてそれを十分に理解する必要があり、あなたの仕事は、コードを維持するのに十分なほどコードを理解するのが必要以上に面倒な欠陥を元のプログラマに認識させることです。

VBでプログラミングできない場合、コードを維持できず、ピアレビューアになる資格がありません。

理解できないコードをレビューするべきではありません。それは、自分が行った奇妙な見た目をすべて説明しなければならない開発者を悩ますだけです。

コーディングガイドラインを選択/定義し、これらのガイドラインに照らしてコードをチェックしてください。何かがガイドラインに準拠していない場合、開発者に説明を求めることができます。

私は既存のガイドラインを選択することから始めます（VB.netコーディング標準は知りませんが、googleは私に与えてくれました：

• VB .Netコーディングガイドライン
• サブメイン
• すべて1つのコードフレームワークで

VB .netのスタイルコップのようなツールを使用する

NDependを使用してソースを分析します（循環的な複雑さ、長さ、深さなどに関するルールがあります）

コードが選択された標準に準拠していると言えば、機能が正しいことや適切なOOP原則を使用しているコードについては何も言っていません。しかし、少なくともそれは何かです。

優れたコードレビューは、言語、API、ライブラリ、スタイル、変数名などの適切な使用-言語を理解する必要があること、およびコードが問題を解決する方法-良いコメント、適切なアーキテクチャ、関連する設計についてです。パターン、すべてのエラーケースなどを考慮します。コードレビューを初めて開始するときは、前者に集中する傾向があります。見やすく、選びやすいです。（たとえば、変数名が好きではありません。XXXXスタイルの名前を使用する必要があります。）

コードのレビューは、コードが問題をどの程度うまく解決できるかに焦点を当てるほど価値があります。最初の領域ではそれほど価値を提供できないため、問題の解決方法ではなく、問題の解決策について質問し、アドバイスを提供することに集中してください。

もちろん、2つの間に重複があります。VB.NETを知っていると、たとえば特定の状況で特定のデザインパターンが適切な選択ではない理由についてアドバイスを提供できます。

何よりも、この段階で謙虚になってください。変更プロセスは困難です。あなたがVB.NETの第一人者であったとしても、その変更は容易ではないでしょう。コードレビューを使用していない人は、最初はそれを気に入らないでしょう。他の人にコードを見てもらうのは大変な経験です。価値を見出すのに時間がかかり、すべての忍耐が必要です。バイインを取得するのは素晴らしいプロセスですが、時間がかかります。

コードを直接見るのではなく、テストに焦点を当てることができますか？コードレビューを放棄するつもりはありませんが、最初は、内部アプリに、発生していることの一部をデコードするのに役立つ十分なテストを用意する方が賢明かもしれません。ここでのアイデアは、テストによって、機能の一部をもう少し理解するのに役立つ可能性があるということです。私はこれを別のルートと考えています。ここでのアイデアは、レビューが後で戻ってくることであり、概要/事前セッションを行い、その後少し休憩する価値があるため、いくつかの部分で行うことができます。それは翌日か2日まで続くので、質問や議論をする前にコードなどを考えて夜眠りたい人にとって十分な時間があります。

もちろん、すでにテストを行っている場合、残念ながらそれほど意味はありません。他の考えは、彼らがVB.Netでこれが特定の方法で行われていると主張している例を提供することです。これは、小さなコード標準からある意味でのVB.Netの構築の中心。

VBの基本を学んだとしても、言語のすべての機能を知らずにコードレビューを実行しても、その言語の安全でない機能の使用を検出することはできません。

非文字列の入力型を解析しやすくするために、Python 2のinput（）関数が実際に入力を評価してからそれを返すことを知らなかったと仮定します。その場合、コードは任意のコード実行に対して脆弱になり、ユーザー__import__('os').execl('/bin/sh', '/bin/sh')はLinuxシステムのようなものを入力してPythonプロセスをシェルに変えることができます。代わりに、未処理の入力データを取得するにはraw_input（）を使用する必要があります。

言語のすべての機能を認識していない状態でコードレビューを実行しようとすると、言語で特定の手順を実行するためのより良い方法を実現できなくなるだけではありません。また、有害なセキュリティ欠陥につながる可能性があります。