知らない言語でコードをレビューすることは効果的ですか？

私は経験豊富な開発者ですが、多くのコードレビューは行っていません。Pythonで書かれたコードをレビューするように求められていますが、Pythonがわかりません。

私が知らない言語でコードをレビューすることはまったく意味がありますか？

任意の感覚？はい。プログラミング言語のセマンティクスについて何も知らない場合でも、文字を読んで、一貫性のないフォーマット、コメントの欠落、不適切に選択された識別子、明らかな重複などに気付くことができます。

あなたの時間の費用を返済するのに十分な感覚、または十分な感覚？よく分かりません。これは、あなたの立場、チームのワークフローにおけるコードレビューの重要性、および十分に定量化できない他のいくつかの要因に依存します。

Code Review Stack Exchangeの定期的な寄稿者として、言語に依存しない問題に悩まされる多くの質問に遭遇します。たとえば：

• 書式設定、インデント
• 範囲
• ループ
• タイプ操作

そしてリストは続きます。ただし、言語を知る必要はありませんが、それらの問題/ポイントを確認できます。

私たちのトップユーザーの何人かは、積極的に使用していない、または知らない言語でトップアンサーを持っています。私のトップ10のうち2つでも、私のマシンでコンパイルも実行もできない言語です。

誰かの擬似コードをレビューするのと同じだとさえ言うでしょう。理解していることに関連するものを観察し、コメントできる限り、あなたは大丈夫であり、関連性があります。

一般的なアドバイス

私の意見では、これが一番下の行です。

• 機能や一般的なイディオムを理解するのに十分な言語を知らない場合は、おそらくレビューにあまり貢献しないでしょう。
• 言語の機能とイディオムを学びたい場合は、レビューに参加できます。あなたの焦点はイディオムを観察し、あなたにとって意味をなさないパターンと組織について質問することです。これは、問題のある領域を特定するのに役立つ場合がありますが、開発者に自分がしたことを守るように強制するという意味でのみです。知識のギャップに余地を残すような方法で質問してください。これは最終的にレビュー自体の純コストになる可能性がありますが、そのコストは知識への投資であることに注意してください。
• 言語の機能、イディオム、および標準に慣れるまで貢献する能力は制限されます。あなたが実際に言語でかなりの量のコードを書いたまで、これが変わるとは思いません。

Python固有の考慮事項と例

Pythonを知らないという特定の状況については、特に注意が必要です。Pythonには多くのイディオムと標準的な慣行があり、その結果、良いPythonは他の言語で期待されるものとは非常に異なって見えます。（実際、私はPythonが私のコードをした際立た物事が見えると思うより良いでは他の言語ではなく、他の方法で回避。）PEP8超えてあなたは完全にPythonが奨励考え方を逃すかもしれない方法の良い例があります。

簡単な例を見てみましょう。このコードを取ります：

f = open('/home/me/something.txt')
try:
    content = f.read()
finally:
    f.close()

このコードに問題がありますか？Pythonを使用したことがない場合は、おそらく使用しないでしょう。問題は、Pythonでまったく同じことを行う非常に好ましいスタイルがあることです。

with open('/home/me/something.txt') as f:
    content = f.read()

これはコンテキストマネージャーです。彼らが何のために良いのか知っていますか？いつ使用するのが適切かを知っていますか？自分で作成するのが適切な時期を知っていますか？番号？そうすれば、おそらくPythonをレビューする準備ができていないでしょう。

別の例を見てみましょう。

def add_fifty(other_list):
   result = list()
   for i in other_list:
       result.append(i + 50)
   return result

x = range(10)
y = add_fifty(x)

問題が発生しましたか？問題は、この方法が完全に不要であることです。操作がこのように単純な場合、おそらく理解を適切に使用する必要があります。

x = range(10)
y = [i + 50 for i in x]

あなたがそれを見なかったなら、あなたはPythonの機能とイディオムに慣れていません。

あなたはPythonを知らないので、彼らはPythonコードを正確にレビューするようにあなたに頼んだかもしれません。 チームに「愚か者」がいると便利だという経営理論があります。私はあなたに悪い名前を呼んでいるわけではありません:)アイデアは、チームがグループの思考に苦しみ、トンネルビジョンを開発するかもしれないということです。これを打破する1つの方法は、他のチームメンバーが「ばか」と考えるチームの誰か、つまり主題を知らない人を含めることです。あなたは自分自身に知らせるために質問をするでしょう、そして質問は他のチームメンバーがおそらく考えなかった視点から来ます。

あなたはPythonを知らないので、Pythonコーダーにとって普通に見えるかもしれないことは、あなたにとって奇妙に見えるかもしれません。チームが決して考慮しなかった改善を提案するかもしれません。

コードレビューとは、スペルが正しくなく、形式が間違っている変数を検索することではありません。コードレビューを使用してそのようなものを見つける場合は、時間を無駄にせずにツールを使用してください。

コードレビューとは、初心者プログラマーによる設計の改善とよくある間違いの検出です。

私はC ++でプログラミングしているので、Pythonを十分に知らないので、あえてPythonコードをレビューすることはありません。しかし、私はJavaコードのレビューを手伝うことができました。

どの言語でプログラムするかは言わなかったが、プログラムされている言語がわからない場合、コードレビューで何が貢献できるかわからない。

コードレビュー（実際に欠陥を探すことに加えて）は、追加または変更されるコードについて、あるチームメンバーから他のチームメンバーへの良い紹介です。あなたが経験豊富な開発者であれば、何が起こっているのかをほとんど理解するのに十分に読み通せるはずです。

チームリーダーの観点からコードレビューを見てください。アプリケーションが何をすべきかを理解している人（ビジネスロジック）、コードが実行していることを理解している人（実装ロジック）、そしておそらく他の数人がいます。そのすべてがどのように適合するかを知る必要がある人。

あなたは間違いなく唯一のレビュアーではありませんが、あなたがレビュアーの一人になる理由はたくさんあります。言語を知らないことは、コードレビューで回答する必要がある多くの質問にとって大きな障害ではありません。例として、私はこのサイトのC＃タグのトップ20回答者の 1人であり、C＃でコンパイルされたhello worldほど多くはありません。

言語を知らなくても共有できる専門知識：

• 領域知識。
• 一般的なオブジェクト指向設計。
• 一般的なプログラミング慣行：命名、明快さなど。

また、新製品の速さを知る良い方法でもあります。私は新しいチームに参加しました。そこでは、言語がよく使われていることは知っていますが、ドメインはわかりません。コードレビューに参加することで、ドメインの側面をよりよく学ぶことができましたが、まだそれらの行に沿って貢献することはできませんでした。

あなたの場合、他のレビュアーが残すコメントを見ると、新しい言語のイディオムを学ぶ良い方法になります。インタープリターはコードがpythonicであるかどうかを気にしないので、これらは他の方法で学ぶのが非常に難しい種類のものです。

これは双方にとって好都合な状況である可能性があります。あなたは、知識の呪いによって汚染されていないPythonの処女なので、あなたは特に価値のあるレビュアーになることができると言っています。

このように考えてください。Pythonの初心者でも理解できるほど十分にコードが明確である場合、それは適切なコードでなければなりません。あなたが理解するのに苦労している部分は、手直しまたはより良いコメントの候補かもしれません。

明らかに、新しい言語を習得するので、あなたにとっても有益です。（うまくいけば、与えられたコードは学ぶための良い例です。）この配置は、「実行可能な擬似コード」であるという評判のあるPythonで特にうまく機能するはずです。経験豊富な開発者であれば、Pythonプログラムの要点を理解するのにそれほど困難はないはずです。

警告は、言語固有の落とし穴から生じるバグを見つけることは期待できないということです。しかし、バグの発見がコードレビューの唯一の目的ではありません。それ以外の場合は、同僚のコードでどのようなことが行われているのかを認識するだけで、知識移転に参加できます。

私はかつて、下請業者が請け負っていて、深刻なパフォーマンスの問題があると思われるプロジェクトを監査するように頼まれました。私はかなり重要な要素が単一のPerlモジュールであることをすぐに確立しました。私は以前にPerlに出会ったことがなく、それを知っている組織に誰もいなかったので、自分でそれを理解しようと試みました。詳細を理解することはできませんでしたが、使用しているアルゴリズムのデータサイズが2次であり、これがすべての問題の原因であることが非常に明確でした。そのため、完全に理解していない言語でコードを読むことは間違いなく生産的です。ボーナスは、あなたがそれについている間に新しいトリックを学ぶことです。

いくつかの観察：

1）経験豊富な開発者であれば、Pythonを使用するだけで（または少なくとも必要なだけ）Pythonを習得できます。「やることで学ぶ」というケースになります。最初は難しいですが、言語を習得するにつれて簡単になります。これを別の言語を学ぶ機会と考えてください（多くの場合、人々は「没入」を通じて「外国語」を学びます）。

2）SEサイトには、「技術的ではない」が、文法、コミュニケーション、ロジックに精通している多くの貴重な人々がいます。そのような人々は「新鮮な目」を被験者にもたらし、他の人が見逃すような「ブレインレス」な修正を数多く行います。おそらく、ロジックや全体的なプログラミングに精通しているなど、「技術的」ではない（Python以外の）スキルについて相談されています。

また、多くのコードレビューを行っていない場合、ほとんどすべてのコードレビューの経験が開発者として役立ちます。これは、あなたのスキルとニーズとチームのものとの間の良い一致のように見えます。

これは、レビューの目的によって異なります。すなわち、あなたが効果的に意味するもの。

それでも、いくつかの問題を検出できる可能性があります。あなたがすべてをレビューする必要があり、彼らがあなたがそれを見ればあなたがそれを助けて、おそらく何かをキャッチすることを望んでいるなら、確かです。構造の多くの概念は、言語間で似ています。特に1つは、コメントをレビューできることです。その特定の言語ではないプログラマーが、何が起こっているのかをよく理解できるように、十分にコメントする必要があります。そうでない場合...あなたは彼らのコメントが欠けている場所を伝えることができます。それがよくコメントされている場合...その後、実際に何が起こっているかのコードを読むのではなく、何が起こっているのかの注釈を通して、その構造のかなりの部分をレビューできるはずです。

しかし、他の多くの問題を検出する可能性は低いでしょう。ですから、もしあなたのレビューが、これがよくできた/実行可能なプログラムであるかどうかの徹底的な決定であると彼らが意図するなら、彼らは失望します。

その結果があなたの時間の価値があるかどうかは、主にプロジェクトに依存します。