レビューを待つときはどうすればよいですか？

私の質問をする前に、状況を説明しなければなりません。

私は会社でジュニアソフトウェアエンジニアとして働いています。私の開発を終えてコミットしたいとき、先輩の一人はいつも私を止めます。

彼はいつも彼がそれをレビューするのを待って欲しい。通常、彼はいくつかのバグを見つけて、いくつかの最適化を行うため、これは問題ありません。

ただし、期限までにコードをコミットする必要があります。終わったら彼に電話して、終わったと言います。彼は通常遅れる。私のコードも遅れています。

私の質問は、どうすればいいですか？レビューを待つ必要がありますか？

編集：質問への追加。もう1つ問題があります。

コーディングするときは自由になりたいです。開発の自由に対する信頼をどのようにして得ることができますか？

_{いくつかの説明： これについて彼と話しました。しかし、それは助けにはなりませんでした。既に課題追跡を使用していますが、レビューのタスクはありません。開発タスクとテストタスクのみがあります。}

私のコードも遅れています。

いいえ、それはあなたのコードではなく、あなたとシニアのコードです。あなたはチームとして働いており、責任を共有しており、2人が締め切りに間に合わなかった場合、それは両方の責任です。締め切りをする人がそれに気づくようにしてください。その人もそれを問題だと思っているなら、彼はきっとあなたとあなたの両方と一緒に話します。

そしてあなたの編集：

コーディングするときは自由になりたいです。開発の自由に対する信頼を得るにはどうすればよいですか？

コードのレビューは、最も重要な品質セーバーの1つです。20年以上のプログラミング経験がある場合でも、2番目の目なしで優れたコードを記述することは事実上不可能です。したがって、優れたチームでは、全員のコード、つまり先輩のコードとコードを常にレビューする必要があります。これは、あなたに対する不信とは何の関係もありません（少なくとも、そうすべきではありません）。2番目の目がなければ「無料のコーディング」が優れていると信じている限り、あなたはまだジュニアプログラマです。

優れたチームでは、課題トラッカーで開発タスクのキューを割り当てる必要があります。

そうすれば、レビュー担当者を待っている間に、そのキューで待機している次のタスクに取り組むことができます（すべきです）。その方法で作業に慣れると、これにより変更が「バッチ」でレビューされる機会が開かれ、遅延が減少します。

• ^{このような「キュー」がない場合は、マネージャーと、またはさらに良いことにはレビュアーと議論してください。-あなたのチームはそのようなもののために合理的に便利なイシュートラッカーを持っていない場合、あなたはまた、校閲者/でこれを議論するかもしれないが、助けにこれを期待していない（より良いチームを見つけるために、ジョブボードや社内の雇用機会を研究考える不足良い問題トラッカーの問題は、多くの場合、チーム内で何かがひどく壊れているという症状です）。}

コーディングするときは自由になりたいです。開発の自由に対する信頼を得るにはどうすればよいですか？

調べるには、まずコードレビューの目的を理解する必要があります。あなたは信頼について言及しました-それは良い「近似」ですが、完全に正確なものではありません。

• ^{たとえば、最近のプロジェクトの1つでは、私と同僚のミニチームによって開発が行われました。私たちは相互に完全に信頼し、尊敬し合いましたが、それにもかかわらず、コードの100％を確認しました。これにより、いくつかのバグを見つけてすぐに修正できるようになりました。これも非常に重要です。これは、レビューに時間がかからず、作業をブロックしなかったためです。}

ご覧のとおり、特定のリスクを防ぐために費やされた努力の観点からコードレビューを考える方がより正確です。優れたチームでは、これを「適切にバランスさせる」方法についての共通の理解を期待できます。万能な適切なバランスは存在せず、プロジェクトに大きく依存することに注意してください- ミッションクリティカルなソフトウェアのバグのリスクと影響は、非クリティカルなアプリケーションのものとは当然異なります。

この例を使用すると、コードをコミットする前に修正する必要のあるバグや改善点を見つけて、レビュアーによる投資が正当化される限り、「レビューのブロック」を期待できます。

彼らは、練習とレビューで得られたガイダンスにより、コーディングがより良くなることを期待しているので、コミットする前に修正する価値のある問題がますます少なくなるでしょう。コードが「安全」になり、面倒な「リスク防止対策」が不要になるとすぐに、コミット後のレビューなど、プロセスが変更されることが予想されます。

プロジェクトによっては、ある時点でコードがレビューをまったくスキップするほど安全であると見なされることもあり、バグの発見はテスターに​​任せられます（ただし、必ずしもそうなるとは限りません。上記の例を参照してください）。

問題が何であるかに応じて、ここには複数の可能な答えがあります。

• あなたの主要な懸念が「私は締め切りに間に合わない」場合、いいえ。二人は一緒に締め切りがありません。（自信を持って）「私は1時間で完了します。そのときコードレビューを行うことができます」と言えますか？それで十分かもしれません。締め切りの前日にコードを完成できますか？それは十分なバッファである必要があります。「レビューしてください」と締め切りの間に十分なバッファーを入れて、コードを完成させていますか？後者の場合、それは共同の障害でもない、と私は言います。

• コードは常にレビューする必要があります。私は（少なくとも）2つ目の目のセットと別の人間が「大丈夫」になっていないと、何もチェックインできません。それは、私が主任プログラマーであるプロジェクトや、私が通常は貢献していないプロジェクトにも当てはまります（しかし、私に影響を与えるバグを見つけて、修正したいと思っています）。ただし、レビューの厳格さは信頼に非常に基づいています。コードを送信したい人がコードベースをよく知っていると信じるなら、その人がコードベースをどれだけよく知っているのかわからないほど厳密ではありません。

私の質問は、どうすればいいですか？レビューを待つ必要がありますか？

いいえ、ただ座っているだけではいけません。常に何かすることがあります。Gnatが提案したように、タスクのキューがあるはずです。または、アジャイル開発の方法で、現在の反復で割り当てられたタスクのリスト。怠けていると、会社やチームの組織に何か問題があります。

別のことは、あなたの上司が本当にあなたがするすべてのコードをチェックしているということです。はいの場合、ペアプログラミングもできます。

コーディングするときは自由になりたいです。開発の自由に対する信頼を得るにはどうすればよいですか？

上級者が後輩の仕事をチェックすることを要求するいくつかの規制があります（医療iso 62304がこれを要求すると思います）。その場合、何もできません。

変更できるのは、文字通りすべてをチェックしないようにシニアに依頼することです。コードレビュープロセスを設定し、重要なことを確認できます。

gitをローカルで使用し、変更をブランチにコミットして、待機中にタスク2を開始します。その後、彼が完了したら、彼の変更をあなたの新しい作品にマージすることができ、あなたはすでに次のタスクで先を行っています。

これを十分に長く、すぐに行うと、彼は一度に2つ以上のことを確認できます。競合を最小限に抑えるために、線が重なる可能性が低いものを選択してください。

これに対する解決策の1つは、ペアプログラミングによって作業のずっと早い段階で上級開発者を関与させることです。

ペアプログラミングのウィキペディアページ

最も明白な利点は、レビューがプロセスのかなり早い段階で行われるため、シニア開発者を待つ必要がなくなることです。

これに加えて、コードを書いている上級開発者の思考プロセスと技術を確認し、そこから学ぶことができます。

上級開発者があなたとペアリングしたくないという問題があるかもしれません。それは難しいことかもしれませんが、私自身の経験では、シニア開発者とジュニア開発者の両方がペアプログラミングから多くの経験を得ています。

また、2人の開発者が同じ作業を行うことで生産性が半分になるという懸念もしばしばあります。ペアプログラミングで生産性への影響を測定することは困難です。私が聞いた最も一般的な回答は、ペアを組むチームとそうでないチームの生産性はほぼ同じであるということです。（誰かがこれに関する良い研究を知っているなら、私はそれについて聞きたいです）

完全な答えではなく、上記の優れた答えに加えて...

チェックインする前に独自のコードを確認しますか？私はそれが最も楽しいものではないことを知っていますが、私は自分自身にほとんどの時間をやらせようとします。私はプロとして20年（合計34年）プログラミングを行ってきましたが、通常、少なくとも1つのバグや、忘れていたもの、または少なくとも改善できるものを見つけました。私はあなたのコードは常に見直されるべきであり、2番目の目は1ペアよりも優れているという感情に同意します。しかし、同じペアがコードを2回通過しても、1回よりも優れています。

コードの単体テストを作成しますか？単体テストに加えて、私が個人的に犯す最も一般的な間違いを検索する小さなシェルスクリプトもあります。その一部は英語の文法とスペリングであり、一部はコンパイラがキャッチしないコーディングの問題です。大規模な変更をチェックインする前に、下流の全員に礼儀として実行します。

私は通常、人々にコードを記述させ、後でそれについて不平を言うこともありますが、すべてのチェックインをレビューするわけではありません。私はかつて非常に若いプログラマーと仕事をしていたが、そのプログラマーは非常に多くの間違いを犯したため、コードをレビューし、通常は元に戻す必要があった。それはうまく終わりませんでした。あなたは、時間どおりに行うよりも正しく行うことが重要であることが多い職業にいます。あなたが自分の過ちから学ぶなら、あなたは遠くに行くでしょう。

レビュアーがコードに対して行う必要のある変更の数を最小限に抑えることができる場合、常に慎重にレビューする必要のないコードを書くことを信頼する可能性を最大限に高めることができます。レビューから自由になりたい場合は、あなた自身の出力の品質に対して最大限の責任を負います。

これらの提案の一部またはすべては、他の誰かがコードをレビューするのを待っている間に行うことができます。

手動のコードレビューを実行するのは...まあ...ちょっと80年代だと思います。まあ、おそらく90年代。

継続的インテグレーションとオンラインコードレビューシステムのこの現代では、「ソース管理を破る」ことを恐れているからといって、コードのコミットを控えたくないのです。

さあ、人々。それが変更セット（または変更リスト）の目的です。プログラマーにソース管理システムの空腹の餌を与えます。その後、継続的インテグレーションサーバーは、多くのターゲットビルドを開始します（まあ、できれば毎日のビルドだけですが、私たちの一部は夢中になります）。何かが壊れた場合は、加害者の机の上にコードモンキートロフィー（通常は誰かがラッキーチャームのシリアルボックスから見つけたプラスチックのおもちゃ）を置き、破壊変更リストをロールバックします。さて、いくつかの継続的統合システムは、ビルドが壊れているチーム/部門/組織の全員に電子メール/ IM /デスクトップ通知を自動的に吹き飛ばし、ファイルまたはテストでビルドを正確に壊した全員を表示する気の利いたハイパーリンクを備えています。今では不幸なプログラマーです」

このプロセスが実行されると、コードレビューシステムが起動します（再び、チェックインによってトリガーされます）。資格のあるチームメンバーのリストには、変更リストがソース管理にコミットされたことが通知され、レビューシステムでレビューが開始され、全員が変更リストの変更に注釈を付け始めます。みんなが「LGTM」と言うことを願っています。プログラマーが賢い場合、彼は祈る/賄bri /隠すことを忘れないでしょう。重大な問題がある場合、レビュアーは欠陥を作成することができ（バグ追跡システムにフックすることができます）、あるいはチェンジリストをバックアウトする必要さえあります。はい、バックアウトされた変更はエゴだけでなく心も傷つけます。それは本当です。拒否された変更リストを再統合することは、ジュニア開発者にとって良い調味料です。

開発環境にCIまたはコードレビューシステムがない場合、これらを真剣に調査する必要があります。いくつかのリンクが役立つ場合があります。

Atlassian Crucible
JetBrains TeamCityがクルーズコントロールを再
評価

CIサーバーを取得する場合は、単体テストフレームワークについても真剣に検討する必要があります。C＃開発者の場合は、NUnitなどを調べて始めてください。

コードの準備が整った時点ではなく、コードの準備が整った時点を事前に伝えます。あなたは約を決定することができるはずです。1週間先。そうすることで、彼はレビューを準備して計画する時間を与え、あなたの両方の計画に適合するようにします。