私たちのチームでは、コードレビューをするのが好きですが、コードレビューはいつでも実行できるため、プログラミングの「ゾーン」にいるときには気にならず、レビューを実行するためにタップします。あなたはレビューをしていますが、これはすばらしいですが、「ゾーン」に再び入る前に10分かかります。予約コードの確認？
私は、コードレビューの必要性をどのように処理するのが最善かを議論していましたが、生産への影響を最小限に抑えました。だから私はある種のスケジュールを持っているという考えを楽しんでいました。プログラマがペアを組んでその日のコードについて話し合う時間ですが、それを行うためのレビュー時間まで待たなければならないということです。だからまだ分かりません。
したがって、中断を減らしながらコードレビューをどのように最適に管理できますか？
ありがとう！
私はその考えが、人々を早くかつ頻繁に巻き込むことだと思います。コードレビューは、最終的にコードのデザインと品質を向上させるコラボレーションのチャンスとみなされるべきです。コードレビューがリストをチェックする単なる項目である場合、または進行の中断と見なされる場合、レビューの精神は欠けていると思います。
最高のコードレビューは、コードを書く人が実際にそれらを探し出すときに起こります。つまり、私たちは、レビューされるまでコードがチェックインされないという規則を持つ傾向があります。そのようにして、それは予定されたレビューのようなものです。ただし、最後まで待っていれば、デザインに影響を与えるコードレビューの利点はありません。
あなた自身も問題を解決し、いくつかのペアプログラミングを行うことができます。あなたがトラブルいくつかのコードを理解することを持っている場合にのみ使用する必要があります私は即興レビューのこの種を数える）
あなたはチェックリストのようなことをして、開発者に自分のベストタイムを選択させることができます。しかし実際の結果との最終的な締め切りがなければ、それは終わらないでしょう。また、「レビュー金曜日」や、その特定の日にレビューを実行するよう促すものなど、「レビュー日」として1日を作ることもできます。
プログラマーが機能の単位を追加し終わったら、その機能の時間見積もりが1日未満であれば、これを実行することをお勧めします。
さらに良いことに、実際に連続したコードレビューを提供するプログラミングプログラミングのことをしても、正式なコードレビューはまだ少ないです。
やあ、
を、あなたは、生産性を得ると同時に、すべてを確認します。
コードレビューを最大限に活用するには、レビュー対象のコードを一人一人見てもらうために事前にスケジュールを設定する必要があります。
著者が正しい側にいるときにレビューアが間違ったエラーをどの程度簡単に話すことができるかは驚くべきことです。少し時間があれば、ほとんどのレビューアはコード内でエラーを検出する可能性が高くなります。
一言で言えば、レビューを事前にスケジュールしておき、レビュー担当者が自分の時間にコードを移動するのに十分な時間があることを確認してください。
HTH
歓声、
トレードオフの人々にレビューのために準備する時間を与え、混乱を最小限に抑えるとの間には厳しいものです。もう一方のトレードオフは、コードがまだ「新鮮」である間にレビューを完了させることで、より複雑になります。
私はグループの束が、最高の意図で道を歩み始め、練習を萎縮させて死ぬことを見ました。ネット上では、それは破壊的すぎるからです。
流れの中断を最小限に抑えて新鮮なレビューを得るために見たベストなことは、時間を左にずらして、コードを書いているときに、ペアプログラミングでと別の形式のレビューとしてテストを書く。 （テストでは、レビュー担当者は「これはまったく機能しますか？」と心配する必要はありません）コードに書かれている余分な目は、レビューで多くの人が時間を要するものを捕まえるのに最適な方法です。それは知識をより速く広げます。
あなたはクリティカルなコードのグループレビューを選択することができますが、レビューが少なくなると、特別なものの準備ができてしまう可能性があります。
これはすべての人にはあてはまらない練習ですが、私がこれまでに作業しているチームではTDDが行われており、ペアプログラミングでは欠陥数の少ないよりクリーンなコードが得られる傾向があります。
開示：私はWebベースのコードレビューアプリケーションであるCrucibleを販売するAtlassianに勤務しています。
私は、ペアプログラミングは貴重な実践であり、それがコードレビューの利点のいくつかを提供することに同意（と見直しコードに関係しない、もちろん他の利点の！）
あなたは混乱を減らすことができます校閲に生じましたコードレビューツールを使用して、各レビューアがそれらに都合のよい時間にレビューを実行するようにします。これはまた、著者がコードを受け入れるように批評家に話すという問題を取り除く。
「チェックインをレビューする」ことは、あなたが調べる方法の1つです。言い換えれば、毎日、誰かがすべてのチェックインをレビューし、何か嫌なことがあれば、すぐに話して、そして/または関係する開発者に電子メールを送ります。
すぐにフィードバックがあり、コードが変更され、開発者の心に新鮮なので、品質が向上します。
私はそれが非常にうまく動作することがわかりました。しかし、このアプローチで解決できないことの1つは、開発者がコード全体をチェックインする場合です。このアプローチでは、一度に複数のファイル全体をレビューすることは困難です。それにはもう一つのアプローチが必要です。効率的なバージョンですが、私はまだそれを探しています。
あなたが言っていることは100％信じています。質問は、コードを見直すのに膨大な時間を費やしていることが分かったときに何をすべきかと思います。あなたのチームが4人または5人のとき、あなたはそれに気付きます。コードの特定の部分を他の部分よりも見直す必要がある人もいます。負荷のバランスをとってメンバー間でレビューを共有しようとしても、誰もがコードベースのあらゆる部分について知っているわけではありません。 – djcouchycouch