22
ありそうもないエッジケースに関するコードレビューの不一致をどのように処理しますか?
私はパスカバレッジチームのロボティクススタートアップで働いており、プルリクエストを送信した後、コードがレビューされます。 私のチームメイトは、チームに1年以上在籍しており、必要と思われるよりもはるかに多くの作業を行うことを示唆するコメントをコードに書きました。いいえ、私は怠け者の開発者ではありません。良いコメント、変数名、インデントを持ち、ケースを適切に処理するエレガントなコードが大好きです。しかし、彼は私が同意しない別のタイプの組織を念頭に置いています。 例を示します。 私は、自分が作成した遷移発見アルゴリズムの変更に関するテストケースを書くのに1日を費やしていました。彼は、私が発生する可能性が極めて低い不明瞭なケースを処理することを提案していました。実際、それが発生する可能性すらわからないのです。私が作成したコードは、元のテストケースのすべてと、私が見つけたいくつかの新しいテストケースで既に機能しています。私が作成したコードは、毎晩実行される300以上のシミュレーションに既に合格しています。ただし、このあいまいなケースを処理するには13時間かかり、ロボットのパフォーマンスを改善するために費やすことができます。明確にするために、これまで使用していた以前のアルゴリズムもこの不明瞭なケースを処理せず、生成された4万件のレポートでは一度も発生しませんでした。私たちは新興企業であり、製品を開発する必要があります。 私は以前にコードレビューをしたことがなく、私が議論しすぎているかどうかはわかりません。私はただ静かになって、彼が言うことをするべきですか?時間を有効に活用することに強く反対しているにもかかわらず、頭を下げて変更を加えることにしました。 私は同僚を尊敬し、彼が知的プログラマーであることを認めています。私はある点で彼に異議を唱えているだけで、コードレビューで不一致を処理する方法がわかりません。 私が選んだ答えは、ジュニア開発者がコードレビューで意見の相違をどのように処理できるかを説明するというこの基準を満たしていると感じています。
188
code-reviews
startup