ピアレビュー、ペアプログラミング、あるいはその両方?[閉まっている]

https://stackoverflow.com/questions/23935

09-06-2019
|

質問

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

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

ピアレビューの慣行は上から押し下げられ、開発者は決してそれに賛同しませんでした。外部の SQA グループが活動から指標を収集していましたが、取り組みが中途半端だったため、数値はほとんど価値がありませんでした。これが「公式」のやり方になってから何年も経ち、開発者たちは規定の手順を集団的に無視するようになりました。

現在では、ライフサイクルにいつバグが介入するかがわかりにくくなっています。そして、ピアレビューを行わないことで、チームの専門化が進み、システムの専門分野以外のコンポーネントの要件やロジックを実際に知っている人は誰もいません。

ピアレビューやペアプログラミングに関するあなたの経験、特に成功事例を知ることは貴重です。

解決

私が若くて愚かだった頃、私の最初の仕事の 1 つは、フォーマットされていないテキストにダンプされた長い PDF ファイルから特定のフィールドを取り出すパーサーを構築することでした。私は何らかの形式の正規表現を使用することについては十分に知っていましたが、正規表現についてはその仕事をうまく行うのに十分ではありませんでした。数日後、私はその仕事を終えましたが、査読の結果、もっとうまくできたはずで、自分が作ったものはゴミだったことを知り、打ちのめされました。私は自分が馬鹿ではないことを証明するために語彙解析の方法を学びましたが、査読プロセスが最悪だったとだけ言っておきましょう。自分の失敗を踊ってくれる先輩は必要ありません。指導者が必要でした。査読を行うたびに、そのことを自分に言い聞かせてきました。

私は、入り口でエゴをチェックするときのピアレビューが好きです。（これには私の時間も含まれています！）この世界には有限な時間があり、あなたが学び、できることは限られています。優れたピアレビューを通じて知識を広げ、より短期間でより多くの成果を得ることができます。問題が発生するのは、分析的な構文チェックが過剰になる場合です。

このため、いくつかのルールがあります。私は自動化できるものについては査読をしません。スペルチェックとコード整形を実行します。FXCop のようなものが利用できる場合は、それを実行して、その指示に従ってください。あるいは、そうしない正当な理由があります。次に、コードがどのようにまとめられているか、コードがどのように機能するか、コードを改善するために何ができるかを検討します。こうすることで、問題の解決方法や、なぜそのように考えるのかについて、異なる視点が得られます。他の方法のほうが優れているわけではない場合もありますが、新しいソリューションが素晴らしく、残りのプログラミング人生で使い続けるものになる場合もあります。レビューが完了したらそれで終わりです。私はそれをあなたに対する例として使っているわけではありません。そこから何を学ぶかはあなた次第です。私は恐怖や脅迫には耐えられません。あなたは賢い人ですから、それを見せてやろうと思います。

他のヒント

私たちは、少なくとも別の目を通さずにコードが本番環境に導入されることのないように努めています。
通常、これはコードレビューを行うことを意味します。私たちは、レビューがコードを書く上で不可欠な部分であるということをチーム全体で習慣づけるように努めています。それを書いてから、誰かに意見を求めます。
また、十分な人材がいるプロジェクト (タスクのサイズが適切な場合) では、ペアプログラミングを試みます。
これには間違いなく利点があったと言わざるを得ません。まず第一に、これはチーム内の若手開発者を指導するのに最適な方法です。彼らのコードをレビューすると、何がより良くできるかを示すことができ、彼らとペアになると、物事を行うより良い方法や、経験豊富な人々のやり方を知ることができます。 IDE をより良く使用する方法についても考えます。
また、コードがどのように見えるかを知る限り、チーム全体の同期を保つことができます。
そしてさらに、それは単に全員の喜びと個人の成長を増加させます。コードについて話したり推論したりできるチームはより良いチームであり、学習と共有を続けるチームです。

注意すべき点:

ペアリングするときは、先輩が後輩にもプログラムできるようにしてください
小さなタスクをペアにさせないでください。通常は時間を無駄にします
ペアが仲良くやっていく様子を観察してください（ペアを強制的に一緒にしないでください）
時々ペアを再シャッフルすることを忘れないでください
レビューをエゴの一致にさせないでください - 人々が他の人を押しつぶさないようにしてください

査読はこうあるべきです必須.

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

個人的には、査読は楽しくあるべきだと思います。食事も提供され、楽しい雰囲気が保たれます。これは、開発者/プログラマーが判断する機会ではなく、お互いから学ぶことができる時間として実際に扱われる必要があります (そして、すべてのプログラムが生来判断能力のある遺伝子を持って生まれてくることは誰もが知っています)。私は、オープン時間の 3 分の 1 または 4 分の 1 にレビューを整理することに感謝したり協力したりする傾向がありました。これは、グループが集まり、誰かが、現在のプロジェクトとは関係のない、自分たちが取り組んでいるプロジェクトやレビューしたプロジェクトを発表するときのことです（締め切りがあるので難しいことはわかっていますが、頑張ってください）。

通常、クリエイターはインスピレーションを促進するために、現在夢中になっている絵画、デザイン、アーティストを展示するために集まります。現実的には、レビューで促進したい主要なコンセプトはインスピレーションであるべきです。それに加えて、人々は、これまで気づかなかった他の開発者が行っていることに自然に気づきます。「おお、それをたった 1 行のコードでできたのですね?」いいね。"開発者に、自分が何をしているのか、何に取り組んでいるのか、どのように進むかについてインスピレーションを与え、やる気を起こさせます。順序とランクを確立するためにピアレビューを使用するよりも、配当を支払うことになります。

最後に、実際に「レビュー」の部分が来ますが、これは避けられない事実です。優れた開発者は貧弱なコードを目にするでしょうが、十分なレビューの後、貧弱なプログラマーはステップアップするか、それを忘れるかのどちらかになります。

物事を前向きに整理整頓していれば、それは通常素晴らしい経験になります。

ペアプログラミングについて触れるのをほとんど忘れていました。これはセットアップがより困難です。明らかに、弱いプログラマーを 2 人一緒に働かせることはできません。あるいは、100 万台のタイプライターを備えた 100 万匹の猿を配置するのと同じくらいです。より強い人と弱い人を組み合わせて、両方にプライベートでインセンティブを与えるようにしてください。弱い人は、改善すれば（そのようなインセンティブが必要な場合）報われる可能性があることを知っておくべきであり、強いプログラマーは、真のリーダーは良い指導者としてスタートすることを知っておく必要があります。ただし、弱い開発者が入力していることを確認してください。その逆ではなく、プレゼンテーションになってしまいます。」欠伸「経験によって何も得られない人もいるかもしれない。

私はアジャイルコーチングを数多く行ってきましたが、人々がペアプログラミングの「汚名」を乗り越えられるよう、それを「リアルタイムコード & デザインレビュー」と呼んでいます。このような言葉で表現すると、人々は概念をよりよく理解できるようです。

私がどちらかに直接関係した唯一の経験は、（ずっと前の）ピアデザインレビューです。そして彼らは最悪でした。文献を読めば、彼らが良いレビューのいくつかのルールに違反していることは明らかでした（人々に飛びつく、スペルに焦点を当てる、明確な結果がないなど）。など）しかし、それが私たちが知っているすべてでした。

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

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

作業レビューの利点は、全員がより良いコードを書けるようになり、優秀なプログラマーにも指導が与えられることです (正直に言うと、優秀なプログラマーは実際に読みやすいコードを書いていますか?) 経験の浅いスタッフに「自分たちはそうはいかない」と説得できれば、何かを理解してください - あなたは離れています。ホットショットの中には、ハァハァと息をする人もいますが、実際の最高のショットは、自分が書いたことを考え、実際に変数名やレイアウトを変更し、さらにはコメントを追加することもあります。

4 番目のプロジェクトでは、「ランダムな時間に」レビューするという課せられたスキームを使用していますが、技術的なリーダーはまだ参加していません (チームが崩壊している?)

あなたが説明した 2 つの実践は、正式なアプローチです。これらはすべての個人やグループに対してうまく機能するわけではありません。

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

一度コードに目を向けてしまえば、もう振り返りたくなくなるでしょう

• はい、当社はピアコードレビューを使用しています。私たちはこれらを Over-The-Shoulder レビューとして実施し、変更をより深く理解するためにチームのテスターをミーティングに参加するよう招待します。

• いくつかの研究で実証されているように、コードレビューには明らかな利点があります。当社の場合、サポートコールの数が減少し、報告されたバグの数も減少したため、コードの品質が向上したことは明らかでした。注記：ここでの利点の一部は、スクラムを実装し、ウォーターフォールを放棄した結果です。スクラムについては以下で詳しく説明します。

• コードレビューの利点は、構造とコーディング標準に適用されるため、製品がより安定し、コードがより保守しやすくなり、開発者がバグの「対処」やその他の運用上の問題ではなく、新機能に集中できるようになります。コードレビューが「正しく」行われていれば、実際には何の欠点もありません。「正しい方法」については、以下で詳しく説明します。

• コードレビューを実装する際に乗り越えなければならないハードルには、「兄貴」が私を見ているという考えと、完璧なコードがないことは拷問と苦痛を意味するという考えがあります。開発者同士を信頼させるのは、特に「序列」や「汝より神聖」な態度をとったり、自分の努力を顕微鏡下で見たりする場合には、難しい場合があります。これらの問題を解決するには信頼が鍵となります。開発者は、コードの間違いによって同僚や経営陣から罰せられることはないと信頼する必要があります。それは誰にでも起こります。問題をメモし、解決して次に進みます。

スクラムスクラム方法論を使用する利点の 1 つは、開発サイクル (「スプリント」) が短いことです。「スプリント」の期間は、組織にとって何が最適であるかによって決定され、試行錯誤が必要になりますが、実際には 4 週間の反復を超えるべきではありません。利点は、開発者が毎日コミュニケーションを取り、プロジェクトの早い段階で問題を伝える必要があることです。これは当初当社の開発部門で採用されましたが、スクラムのメリットが広範囲に及ぶため、社内のあらゆる領域に広がりました。詳細については、以下を参照してください。 http://en.wikipedia.org/wiki/SCRUM または http://www.scrumaliance.org/ 。開発の繰り返しが少なくなるため、コードレビュープロセスではより小さなコード部分がレビューされるため、数時間または数日間の正式なレビューよりも問題が発見される可能性が高くなります。

"正しい方法"「正しい方法」で行われたコードレビューは完全に主観的なものです。しかし、私は個人的に、それらは非公式で肩を落としたレビューであるべきだと信じています。レビューのすべての参加者は、「なぜあなたはそれをそのようにしたのか」などの声明でレビューされている人を個人的に攻撃することを避けるべきです。または「あなたは何を考えていましたか？」等この種のコメントはピア間の信頼を低下させ、敵意を引き起こし、ソリューションをコーディングするための最善/正しい方法について何時間もの議論が行われるようになります。開発者はまったく同じことを考えたりコーディングしたりするわけではなく、問題に対する解決策は多数あることに留意してください。
肩を落としたレビューについて少し説明します。これらは、リモートデスクトップ共有 (ここでフレーバーを選択) 経由で、または直接行うことができます。ただし、開発者のみに限定すべきではありません。通常、チームごとに 2 人の開発者、テスター、ドキュメント担当者、および製品所有者で構成されるスクラムチーム全体を招待します。開発者以外のすべての人は、行われた変更や新しい機能をより深く理解するために参加しています。質問したり意見を提供したりするのは自由ですが、コーディングに関する決定やコメントを行うことはできません。初期要件がシナリオを逸脱している可能性があるため、プロジェクトの方向性を変える可能性のある特定の質問が尋ねられるため、これは効果的でしたが、それがアジャイルの本質であり、変化です。

提案スクラムとコードのレビューを義務付ける前に、調査することを強くお勧めします。それぞれの基本的なルールを作成し、文化の一部として実装して、より高品質の製品を実現します。それは、品質の低下、納期の遅れ、フラストレーションから、より高品質の製品、フラストレーションの軽減、より納期通りの成果物へのパラダイムシフトであるため、それが自然なプロセスの一部となり、あらゆるレベルで統合されるように、企業文化の一部となる必要があります。。

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

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

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow