最近、職場で、ある人が自分でコードに取り組んでいると、他のチーム メンバーがそれを見て、「あれは醜い、扱いにくい、書き直す必要がある」という問題に遭遇しました。それ"
実際、最近、私自身、(関連する) 機能を追加できるように、前の週に書いたものをリファクタリングする必要がありました。
ペアプログラミングがそのための方法であることはわかっていますが、私たちのチームはバラバラです (メンバーは 3 人です)。現在、私たちのチームはかなりのプレッシャーにさらされているため、ピア レビューを行う時間は本当にありません (ただし、ペア プログラミングを行うことはできますが、タスクの見積もりにそれを見積もることが許可されているためです)。
貧弱なコードが生成されることで、これらの問題を克服する方法を人々がどのように提案するかについて、私はただ興味があります.
一人で作業し、同僚が醜くて管理しにくく、書き直す必要があるコードを作成する場合は、次のようにします。
（a）もう一度見るときに、彼らに同意します。
（b）同意しませんか？
（a）の場合、問題は、自分でコードを記述したときにコードが完全に明確になっていないことです。ペアプログラミングだけがまともなコードを書くようにするので、「奇妙なもの」は、長い間悪いコードを書くことを伴わないタスクで機能することをお勧めします。おそらくテストコードを書くのは、それが少し厄介ではない傾向があるからです。その間、より良いコードを書くスキルの向上に取り組みます。おそらく、数か月前の自分のコードのレビューを行い、何が問題だったかをメモします。
（b）の場合、あなたが抱えている問題は、あなたのアイデアを表現するための互換性のない方法です。コードはあなたの基準では悪くないかもしれませんが、相互に理解できないので、企業の設定ではそれは悪いコードであることを意味します。ペアプログラミングとは、あなたが書いたものが3人に2人が理解できる妥協案であることを意味しますが、それは実際には解決策ではありません。あなたはお互いのコードについて最も難しいと思うことについていくつかの相互合意に達し、それをやめる必要があります。そして、皆さんは緊急に、「私はこのコードが好き」ではなく、「私の2人の同僚がこのコードを好きになる」という観点から「コード品質」について考え始める必要があります。
いずれにせよ、あなたは皆、できるだけ早く仕事を終わらせるためではなく、読むためにコードを書くことに取り組む必要があります。個人的には、当時の自分にとって意味のあることではなく、他の人が表現して理解できるような方法で表現しようと努めてきました。最終的にそれは習慣的になります。私がコードを書くとき、私は一般の聴衆のためにこの投稿を書いているのと同じように、一般の聴衆のためにそれを書きます。さて、私の個人的なプロジェクトでは、それは私のように考える人々の聴衆ですが、職場では私の同僚のように考える聴衆です。しかし、原則は、誰かがそれを読んでいるかのようにコードを書くことです。コンパイラではなく、彼らに自分自身を説明しているのです。
私のコードが世界で最高というわけではありませんが、私の最初の仕事は30人余りのプログラマーがいる会社であったことで恩恵を受けたと思います。そのため、さまざまな考え方を見ることができました。また、「してはいけないこと」のいくつかの例では、あるプログラマーが他の誰も簡単に理解できないことをしたため、間違いなく悪いと言えます。たった3人で、2対1の意見の違いが、1がフリークなのか、それとも合理的な少数派なのかは明らかではありません。私が何かをして、4、5人がそれをちらっと見て、すぐに「ええ、それをしないでください」と言うことができたとき、私はそれがそもそもただのばかげた考えであると本当に信じ始めました。
また、コードレビューの予算を立てることが許可されていない場合は、嘘をついて不正行為をすることをお勧めします。他の人のコードを大幅に書き直している場合は、とにかく時間をかけて効果的にレビューしていることになります。コードレビューの価値のある部分であるフィードバックを提供していないだけです。それで、レーダーの下でレビューをこっそりと入れてください-関数を1つか3つ書いて、それを同僚に見てもらい、それが彼らにとって意味があるかどうかについて即座にフィードバックを与えてください。モニターにコードを表示して、会話が終わったらすぐに会話するのに役立ちますが、「流れ」があるときに人の邪魔をしたり、長い議論に巻き込まれたりしないようにしてください。これはペアプログラミングではなく、正式なコードレビューでもありませんが、自分で何をしているのかを理解するのに役立つかもしれません。
ピアレビューをする時間がないのに、ペアプログラミングをする時間があることに驚いています。後者の方がはるかに大きな時間の浪費ではありませんか?
また、当社だけに 3 人の開発者がいて、驚いたことに、現在、私たちは非常に追い詰められています。私がペアプログラミングを提案したら、上司に笑われるに違いありません。なぜなら、実際にはそれが生み出すべき結果ではないにもかかわらず、タスクの工数が 2 倍になると見なされるからです。私たちのピア レビューは 1 時間以上かかることはありません。これは極端なケースです。平均して、おそらく約 10 分で、開発者ごとに、1 日に 1 つか 2 回しか発生しません。
IMO ピア レビューを試してみてください。問題を起こしている人 (つまり、低品質のコードを書いている人) は、最終的にはもっと努力する必要があることに気づき、時間の経過とともに品質が向上することがよくあります。
3 人の開発者がいて、それぞれが他のコードが良くないと考えている場合は、早急にピア レビューが必要です。
そう：
2つが関連している可能性があると思いますか？答えは、スケジュールを修正することです。
3つすべてを一度にペアリングします。
いくつかのコーディング標準を設定します。
ビルドを壊す開発者には劣等生キャップを使用します。
進捗状況を伝えるために、毎日スタンドアップミーティングを実施します。
また、火曜日と金曜日のように、週に2回ピアレビューを試してください。
ペアプログラミングを効果的にするために、毎日一日中行う必要はありません。毎週1、2時間一緒に仕事をすることで良い結果が得られました。行く方法の1つは、しばらくの間AとBをペアリングし、次にAとCをペアリングし、次にAとBをペアリングすることです...その間に多くの個別の時間があります。
それはまた、チームメンバーの個性と化学的性質にも大きく依存します。3つのうち2つは非常にうまく連携する可能性があり、その恩恵を受けたいと思うでしょう。
まだペアリングする必要があります。週に1日と言うセッションを設定し、ペアをローテーションします。これにより、マネージャーは満足し、コードの品質が向上し、コミュニケーションが向上します。ペアコーディングと単独コーディングで発生する障害の数に関するメトリックを保持する場合は、メリットを確認し、これをマネージャーに表示する必要があります。
例：これにはx工数かかりましたが、欠陥修正で平均y節約できました。さらに、クロードはよりクリーンで、次に触れるときよりも変更にかかる時間が短くなります。
そこからハード統計が得られ、さらにコーディングを開始できます。
基本的にあなたの話は私のものと同じようです。
あなたは腐敗を止める必要があります。
コードレビューを使用しています。さらに、いくつかの単一のタスクがあります: ダイアグラムの変更、いくつかのもののインストール...