qa - ピアレビューまたはペアプログラミング、またはその両方?

Question

• コード ピア レビューに参加するか、ペア プログラミングを実践しますか、あるいはその両方ですか?
• これらのプラクティスを使用して、ソフトウェア品質の向上を実証できましたか?
• 実践の過程でどのような利点と欠点が見られましたか?
• 実装に向けてどのようなハードルに直面しましたか?

私の場合、開発チームはさまざまなソフトウェア アーティファクト (要件分析、テスト計画、コードなど) のピア レビューを行いました。ピアプログラミングはオプションとさえ考えられていませんでした。

ピア レビューの慣行は上から押し下げられ、開発者はそれを受け入れることはありませんでした。アクティビティからメトリックを収集する外部の SQA グループがありましたが、努力が中途半端だったため、数値はほとんど価値がありませんでした。これが何年にもわたって「公式」の方法であった後、開発者は所定の手順を集合的に無視するようになりました。

現在、バグがライフサイクルに割り込んでいる時期が見えにくくなっています。また、ピア レビューを行わないことで、チームの専門性が高まり、システムの専門分野以外のコンポーネントの要件/ロジックを誰も本当に知らないという状況に陥っています。

ピア レビューやペア プログラミングの経験、特にサクセス ストーリーを知ることは価値があります。

Answer 1

私が若くて愚かだった頃、私の最初の仕事の 1 つは、フォーマットされていないテキストにダンプされた長い PDF ファイル内の特定のフィールドを抽出するパーサーを構築することでした。私は何らかの形式の正規表現を使用するのに十分な知識を持っていましたが、正規表現についてうまく機能させるには十分ではありませんでした。数日後、私はタスクを完了しましたが、ピア レビューで、もっとうまくできたはずであり、私が作成したものはゴミであることがわかり、打ちのめされました。私は馬鹿ではないことを証明するためだけに字句解析を行う方法を学びましたが、査読プロセスが最悪だったとだけ言っておきましょう。自分の失敗に踊ってくれる上級者は必要ありませんでした。メンターが必要でした。ピアレビューを行うたびに、そのことを思い出しました。

ドアのエゴをチェックするときのピアレビューが好きです。(これには私のも含まれます!) この世界には有限の時間があります。優れた査読を通じて、知識を広げ、より短い時間枠でより多くのことを成し遂げることができます。問題は、物事が過度の構文チェックに劣化したときに発生します。

このため、いくつかのルールがあります。自動化できるものは査読しません。スペル チェックを実行し、美化ツールをコーディングします。FXCop のようなものを利用できる場合は、それを実行するか、それが示すとおりに実行するか、実行しない正当な理由があります。次に、コードがどのようにまとめられているか、どのように機能するか、およびコードを改善するためにできることを確認できます。このようにして、問題を解決する方法と、誰かがそのように考える理由について、異なる視点を得ることができます。他の方法が実際には良くない場合もあれば、新しいソリューションが素晴らしく、残りのプログラミング ライフで使用するものである場合もあります。レビューが完了したら、それだけです。私はそれをあなたに対する例として使用していません. そこから何を学ぶかはあなた次第です。私は恐れや脅迫に屈するつもりはありません。あなたは賢い人であり、それを見せてあげましょう。

Answer 2

私たちは、少なくとももう1組の目を通さずに、コードが本番環境に移行しないように努めています。
通常、それは私たちがレビューをコード化することを意味します。私たちは、レビューがコード作成の本質的な部分であるということをチームの周りの習慣にしようとしています。あなたはそれを書き、そして誰かに意見を求めます。
また、十分な人数がいるプロジェクト（タスクが適切なサイズの場合）では、プログラミングをペアリングしようとします。
私たちはこれに間違いなく利点を見たと言わなければなりません。まず第一に、それはチームのジュニア開発者を指導するための素晴らしい方法です-彼らのコードをレビューするとき、あなたは彼らに何がより良くできるかを示すことができ、彼らとペアリングするとき、彼らは物事を行うより良い方法、どのように経験豊富な人々を見ることができますIDEをよりよく使用する方法を考えてください。
また、コードがどのように見えるかを知っている限り、チーム全体の同期を維持します。
さらに、それは単にすべての人の喜びと自己啓発を高めます-コードについて話し、推論することができるチームは、より良いチームであり、学習と共有を続けるチームです。

注意すべき点：

• ペアリングするときは、シニアもジュニアもプログラムできるようにしてください
• 小さなタスクで人々をペアにさせないでください。通常は時間を無駄にします
• ペアがどのようにうまくいくかを見てください（ペアを強制しないでください）
• 時々ペアを再シャッフルすることを忘れないでください
• レビューをエゴマッチにさせないでください-人々に他人を押しつぶさせないでください

Answer 3

査読は必須です。

さまざまな規模のチームでこれにアプローチするためのさまざまな方法について議論している記事や本を数多く読んで見つけることができますが、経験について尋ねているようです。

個人的には、査読は楽しくするべきだと思います。食事を提供し、陽気な雰囲気を保ちます。開発者/プログラマーが判断する機会ではなく、お互いから学ぶことができる時期として実際に扱われるべきです (そして、すべてのプログラムが生来の判断力のある遺伝子を持って生まれているように見えることは誰もが知っています)。私は、オープンの 1/3 または 1/4 の時間でレビューを整理することを高く評価したり、支援したりする傾向がありました。つまり、グループが集まって、1 人が現在のプロジェクトとは関係のない作業中またはレビューさえしているプロジェクトを提示することを意味します (締め切りがあると難しいことはわかっていますが、試してみてください)。

クリエイティブは通常、インスピレーションを促進するために、現在夢中になっている絵画、デザイン、アーティストを展示するために集まります。現実的には、インスピレーションは、レビューで促進したい主要なコンセプトであるべきです。それに加えて、人々は、以前は気付かなかった仲間の開発者が行っていることに自然に気づきます。「うわー、1 行のコードでそれを行うことができたのですか? 涼しい。" 開発者が何をしているか、何に取り組んでいるか、どのように取り組んでいるのかについて開発者に刺激を与え、やる気を起こさせることは、ピアレビューを使用して序列とランクを確立するよりも多くの見返りをもたらします。

最後に、実際の「レビュー」の部分ですが、これは避けられない事実です。より優れた開発者は貧弱なコードを見て、十分なレビューの後、貧弱なコーダーがステップアップするか、それを忘れる時が来ました.

物事を前向きに整理しておくと、通常は素晴らしい経験になります。

ペアプログラミングに触れるのをほとんど忘れていました。これはセットアップがより困難です。明らかに、弱いプログラマーを 2 人一緒に作業させることはできません。または、100 万匹のサルと 100 万匹のタイプライターを配置することもできます。強い人に弱い人をつけて、個人的に両方にインセンティブを提供するようにしてください。より弱い人は、改善が報われる可能性があることを知っている必要があり (そのようなインセンティブが必要な場合)、より強いプログラマーは、真のリーダーは優れた指導者としてスタートすることを知っておく必要があります。ただし、弱い開発者が入力していることを確認してください。その逆ではないか、プレゼンテーションになって「あくび」をする人は、その経験から何も得られないかもしれません。

Answer 4

私は多くのアジャイル コーチングを行ってきましたが、人々がペア プログラミングの「スティグマ」を克服するのを助けるために、それを「リアルタイム コード & デザイン レビュー」と呼んでいます。人々は、あなたがそれらの用語で言えば、コンセプトをよりよく理解しているようです。

Answer 5

私が持っている直接関連する唯一の経験は、ピア デザイン レビューです (かなり前のことです)。そして彼らは吸った。文献を読めば、良いレビューのいくつかのルール (人に飛びつく、スペルに焦点を当てる、明確な結果がないなど) を破っていることは明らかでしたが、私たちが知っていたのはそれだけでした.

しかし、それ以来、私は多くのオフライン コード レビューに携わってきました。

プロジェクトに応じて、「ライブ」ブランチにチェックインする前、またはその後のランダムな時点で義務付けられています。4 つのプロジェクトのうち 3 つでは、最初は必要悪として受け入れられましたが、後に貴重な情報として受け入れられました。

作業レビューの利点は、誰もがより良いコードを書けるようになり、最高のコーダーでさえも指導できるようになることです (正直なところ、あなたの優秀なプログラマーは実際に読み取り可能なコードを書いていますか?)。何かを理解してください - あなたは離れています。いくつかのホット ショットはハフ アンド パフしますが、実際の最高のものは、自分が書いたものについて考え、実際に変数名やレイアウトを変更し、コメントを追加することさえあります。

4 番目のプロジェクトでは、「ランダムな時間に」レビューする課せられたスキームが使用されており、テクニカル リーダーはまだそれに取り込んでいません (壊れたチーム ?)

---

あなたが説明する2つのプラクティスは、正式なアプローチです。すべてのパーソナリティやグループでうまく機能するわけではありません。

チームが実際にできると思うことを試して、改善できるかどうかを確認してください。

コードに余分な目を向けると、振り返りたくないでしょう

Answer 6

Answer 7

ペアプログラミングからgithubでのPRレビューに移行してからの比較分析。

私たちのチームが PR レビュー プロセスで現在行っていることを段階的にリストアップすることに重点が置かれています。

「コード レビュー vs ペア プログラミング」https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926