レビューを待つときはどうすればいいですか？
質問する前に、状況を説明しなければなりません。
私はジュニアソフトウェアエンジニアとして会社で働いています。私が私の開発を終えてコミットしたいとき、先輩の一人がいつも私を止めます。
彼はいつも私が彼がそれをレビューするのを待つことを望んでいます。通常、彼はいくつかのバグを見つけ、いくつかの最適化を行うため、これは問題ありません。
ただし、期限までにコードをコミットする必要があります。私が終わったら、私は彼に電話してそれが終わったと言います。彼は通常遅れて来る。だから私のコードも遅いです。
私の質問は、どうすればよいですか？私は彼にレビューを待つべきですか？
編集：質問への追加。もう1つ問題があります。
コーディングするときは自由になりたいです。開発の自由への信頼を得るにはどうすればよいですか？
いくつかの説明：これについて彼と話しました。しかし、それは助けにはなりませんでした。私たちはすでに課題追跡を使用していますが、レビューのためのタスクはありません。開発とテストのタスクがあります。
だから私のコードも遅いです。
いいえ、それはyourコードではなく、あなたのコードですand先輩です。あなたはチームとして働いており、責任を共有しています。2人が期限を逃した場合、それはあなたと2人の責任です。だから、締め切りを作る人がそれに気づくようにしてください。その人もそれを問題だと考えるなら、きっとあなたと一緒にあなたと一緒に話します-それはあなたの同僚との単一の話以上に役立つかもしれません。
そしてあなたの編集に：
コーディングするときは自由になりたいです。開発の自由への信頼を得るにはどうすればよいですか？
コードのレビューは、最も重要な品質セーバーの1つです。プログラミングの経験が20年を超えている場合でも、2つ目の目を使わずに優れたコードを書くことは事実上不可能です。したがって、優れたチームでは、全員のコードを常にレビューする必要があります-先輩のコードだけでなくコードも。これは、あなたに対するdistrustとは直接関係ありません（または、少なくともそうすべきではありません）。 2つ目の目がない「無料のコーディング」の方が優れていると信じている限り、あなたはまだジュニアプログラマーです。
優れたチームでは、開発タスクのqueueが issue tracker で割り当てられているはずです。
そうすることで、レビュアーを待っている間に、そのキューで待機している次のタスクに（する必要があります）ことができます。その方法での作業に慣れると、変更を「バッチ」でレビューする機会が開かれ、遅延が減少します。
- そのような「キュー」がない場合は、上司と、またはレビュー担当者とさらによく話し合ってください。あなたのチームがそのようなもののための合理的に便利な課題追跡システムを持っていない場合、より良いチームを見つけるために求人掲示板や会社の内部の仕事の機会を検討することを検討してください（マネージャー/レビュー担当者とこれについて話し合うかもしれませんが、これが役立つことを期待しないでください-- 優れた課題追跡の欠如 は、多くの場合、チーム内で何かがひどく壊れている症状です）。
コーディングするときは自由になりたいです。開発の自由への信頼を得るにはどうすればよいですか？
調べるには、まずコードレビューの目的を理解する必要があります。あなたはtrustについて言及しました-それは良い「近似」ですが、完全に正確なものではありません。
- たとえば、私の最近のプロジェクトの1つで、開発は私と私の同僚のミニチームによって行われました。私たちは完全に相互に信頼し、お互いを尊重しましたが、それにもかかわらず、コードの100％をレビューしました。これにより、いくつかのバグを見つけてすばやく修正できるようになりました。また、レビューに時間がかからず、作業がブロックされなかったため、これも非常に重要です。 。
ご覧のとおり、コードレビューは特定のリスクを回避するために費やされた努力の観点から考える方がより正確です。優れたチームでは、これをどのように「適切にバランスを取る」かについて、ある程度の共通の理解を期待できます。万能の適切なバランスは存在しないことに注意してください。プロジェクトに大きく依存します。バグのリスクと影響 ミッションクリティカルソフトウェア は、当然、非クリティカルアプリケーションとは異なります。
この例を使用すると、レビュアーが費やした作業がjustifiedである限り、コードをコミットする前に修正する必要があるバグと改善点を見つけることにより、「レビューのブロック」を期待できます。
彼らは、練習とレビューで受け取られたガイダンスがあれば、コーディングをより上手くできるようになるため、コミットする前に修正する価値のある問題がますます少なくなることを期待しています。コードが「安全」になり、煩雑さの少ない「リスク防止策」を行えるようになったことを発見するとすぐに、プロセスが、たとえば commit after review のように変更されることを期待できます。
プロジェクトによっては、ある時点で、コードが安全であると見なされてレビューをまったくスキップでき、バグの発見がテスターに任される場合があります（ただし、必ずしもそうなるとは限りません。上記の例を参照してください）。
あなたの問題が何であるかに応じて、ここには複数の可能な答えがあります。
あなたの主な懸念が「締め切りを逃している」である場合、違います。あなた方2人は共同で締め切りを逃しています。 「自信を持って」「私は1時間で完了します。そのときにコードレビューを行うことができます」と言えるでしょうか。それで十分かもしれません。締め切りの前日にコードを完成できますか？それは十分なバッファでなければなりません。 「レビューしてください」と締め切りまでの間に十分な余裕を持ってコードを完成させていますか？後者の場合、それは共同の欠陥でさえないと私は言うでしょう。
コードは常にレビューする必要があります。 （少なくとも）2つ目の目と別の人間が「大丈夫」になっていないと、何もチェックインできません。これは、私が主任プログラマーであるプロジェクトと、通常は貢献しないプロジェクトにも当てはまります（ただし、修正が必要な自分に影響を与えるバグを見つけました）。ただし、レビューの厳格さは信頼に基づいています。コードを送信したい人がコードベースをよく知っていると信頼している場合、私はその人がコードベースをどれだけよく知っているかを知らないほど厳格ではありません。
私の質問は、どうすればよいですか？私は彼にレビューを待つべきですか？
いいえ、ただアイドルするだけではいけません。常に何かすることがあります。 Gnatが示唆したように 、タスクのキューがあるはずです。または、アジャイルな開発方法で、現在の反復で割り当てられたタスクのリスト。アイドル状態の場合は、会社またはチームの組織に問題があります。
もう1つは、上司が実際に行うすべてのコードをチェックしているかどうかです。はいの場合、ペアプログラミングを行うこともできます。
コーディングするときは自由になりたいです。開発の自由への信頼を得るにはどうすればよいですか？
シニアがジュニアの仕事をチェックすることを要求するいくつかの規制があります（私はメディカルiso 62304がこれを要求すると思います）。そうであれば、何もできません。
変更できるのは、文字どおりすべてをチェックしないようにシニアに依頼することです。コードレビューのプロセスを設定し、重要なことを確認できます。
ローカルでgitを使用し、変更をブランチにコミットして、待機している間にタスク2を開始します。その後、彼が完了したら、彼の変更を新しい作業にマージすることができ、次のタスクの先を進んでいます。
これを十分に長く、すぐに実行すると、一度に2つ以上のことを確認できます。競合を最小限に抑えるために、線が重なる可能性が低い場所を選択します。
それ自体で完全な答えではなく、上記の優れた答えに追加しただけです...
チェックインする前に自分のコードをレビューしますか？私はそれが最も楽しいことではないことを知っていますが、私はほとんどの場合自分でそれをやらせようとします。私はプロとして20年間（計34年間）プログラミングを行っていますが、通常、少なくとも1つのバグや、忘れてしまったことが1つあるか、少なくとも改善できる可能性があります。あなたのコードは常に見直されるべきであり、2つ目の目は1つのペアよりも優れているという意見に同意します。しかし、同じペアがコードを2回実行する場合でも、1回よりも優れています。
コードの単体テストを記述していますか？単体テストに加えて、私が個人的に行う最も一般的な間違いを検索する小さなシェルスクリプトもあります。一部は英語の文法とスペルであり、一部はコンパイラーが検出できないコーディングの問題です。大規模な変更をチェックインする前に、ダウンストリームの全員の礼儀として実行します。
私は通常、ユーザーにコードを記述させ、後で不満を言うこともありますが、すべてのチェックインを確認するわけではありません。私はかつて非常にジュニアのプログラマーと一緒に働いていました。そのプログラマーはコードを確認しなければならず、たいていは間違いが多かったため元に戻しました。それだけでは終わりませんでした。あなたは、時間どおりに行うよりも正しく行うことがしばしば重要な職業にいます。あなたが過ちから学ぶなら、あなたは遠くへ行きます。
レビュー担当者がコードに加える必要がある変更の数を最小限に抑えることができれば、常に慎重にレビューする必要のないコードを書いてもらえる可能性を最大限に高めることができます。レビューを行わない場合は、自分の出力の品質について最大限の責任を負ってください。
これらの提案の一部またはすべては、他の誰かがあなたのコードをレビューするのを待っている間に行うことができます。
これに対する1つの解決策は、あなたの仕事にペアプログラミングによって上級開発者をより早く関与させることです。
あなたにとって最も明白な利点は、レビューがプロセスのかなり早い段階で行われるため、上級開発者を待つ必要がなくなることです。
これに加えて、上級開発者がコードを書いているときの思考プロセスとテクニックを見て、これから学ぶことができます。
上級開発者があなたとペアリングしたくないかもしれないという問題があるかもしれません。それは難しいことかもしれませんが、私自身の経験では、シニアとジュニアの両方の開発者がペアプログラミングから多くの経験を積んでいます。
また、2人の開発者が同じ作業を行うことで生産性が半分になるという懸念もしばしばあります。ペアプログラミングでは生産性への影響を測定することは困難です。私が聞いた最も一般的な応答は、ペアを組むチームと組まないチームの生産性はほぼ同じであるというものです。 （誰かがこれについての良い研究を知っているなら、私はそれについて聞きたいです）
手動でコードレビューを行うのは...まあ...ちょっと80年代だと思います。まあ、多分90年代でしょう。
継続的インテグレーションとオンラインコードレビューシステムのこの現代の時代では、「ソースコントロールが壊れる可能性がある」と恐れているからといって、コードコミットを保留したくないのです。
さあ、人々。それがチェンジセット（またはチェンジリスト）の目的です。あなたのプログラマーに、あなたのソース管理システムの空腹の口を与えさせます。次に、継続的インテグレーションサーバーが対象を絞ったビルドのリタニーで起動します（まあ、うまくいけば、毎日のビルドだけですが、私たちの一部は夢中になります）。何かが壊れた場合は、コードモンキートロフィー（通常は誰かがラッキーチャームのシリアルボックスから見つけたプラスチックのおもちゃ）を加害者の机の上に置き、壊れた変更リストをロールバックします。まあ、一部の継続的インテグレーションシステムは、ビルドが壊れていることをチーム/部門/組織の全員に電子メール/ IM /デスクトップ通知で自動的に爆破し、ファイルまたはテストでビルドを正確に破壊した全員を表示する気の利いたハイパーリンクを備えています。コンパイル/単体テスト/統合テスト/その他を壊したものを修正するのは今や不幸なプログラマーの仕事です。
このプロセスが実行されると、コードレビューシステムが起動します（ここでも、チェックインによってトリガーされます）。資格のあるチームメンバーのリストに、ソースリストにコミットされている変更リストが通知され、レビューシステムでレビューが開始され、全員が変更リストの変更に注釈を付け始めます。みんなが「LGTM」と言ってくれるといいのですが。プログラマーが賢いなら、彼は祈ること/賄賂/隠すことを忘れないでしょう。深刻な問題がある場合、レビュー担当者は欠陥を作成するか（バグ追跡システムにフックされる可能性があります）、チェンジリストのバックアウトを要求することもできます。はい、取り消された変更は自我だけでなく心にも害を与えます。拒否された変更リストを再統合することは、ジュニア開発者にとって良い調味料です。
開発環境にCIまたはコードレビューシステムがない場合は、これらを真剣に調査する必要があります。いくつかのリンクが役立ちます。
アトラシアンクルーシブル
JetBrains TeamCity
reitveld
クルーズコントロール
CIサーバーを取得する場合は、単体テストフレームワークについても真剣に検討する必要があります。 C＃開発者の場合、開始するには NUnit のようなものを調べてください。