コードレビューは本当にアジャイルで機能しますか？

そのため、名前に3文字が含まれる大企業で働き始めました。彼らはアジャイルになろうとしていますが、プロセスがたくさんありますが、アジャイルだとは感じません。

私が一番苦労しているのはコードレビューです。私の最後の仕事は、私が見た、今まで聞いた、そして/または聞いたことがある中で最もアジャイルな開発チームだと言うスタートアップの仕事でした。

とにかく、私の意見では、コードレビューは、UX / UIが極端/強烈な反復開発またはアジャイル開発では時間の無駄であるということです（Apple / Steve Jobsの完璧さを考えてください）。たぶん、ここの誰かが私を解雇する前に理解するのを助けることができますか？

これが私の開発プロセスであり、最後のスタートアップのプロセスです...非常にアジャイルです。

開発作業/仕事を分類するために、初期の機能作業を行います。フィードバックを得るために、いくつかのバージョンをモックアップし、ユーザー、チーム、マーケティングに提示します。次に、上記と同じ利害関係者から1つのラウンドを取得するために、別のモックアップの反復を行います。次に、作業を分割して開始します。達成すべきマイルストーンと日付はありますが、プラグインは続けます。この間、コードレビューはありません。開発の数週間に何度か、利害関係者とのセッションを開催し、機能/機能/ UX / UIがまだ適切で目標に合っているかどうかを確認します。

8週間の反復サイクルの終わりに近づくと、QAがテストを開始し、アルファユーザー、そして最終的にベータユーザーに進みます。しかし、アルファ版およびベータ版の開発者は、UXを改善するために、UIを毎日または1時間ごとに繰り返し変更して、新しい機能と古い機能を検討しています。したがって、このリリースで開発されていた機能は、最後の4週間でさらに3回変更されて、改善および完成されるか、いくつかの小さな機能が追加されます（たとえば、コンポーネントを少しスマートまたはスマートにします）。時々、変更は表面的なものであり、CRUD操作は変更または変更されず、すべてのUIが変更されるだけです。

このタイプの開発プロセス、極端なアジャイルでは、コードレビューは時間の無駄ではないでしょうか？別の開発者または2人がコードをレビューしたが、そのコードがさらに3回変更されると、UI / UXのすべての改善により、最初の3回のレビューに時間を無駄にしないという意味です。そのコード/コンポーネント/ UIが廃棄されたコード

このプロセスで品質の問題はあまりありませんでした。開発者がすべての知識を手放した場合、そうです。

はい、テスターは3〜4回再テストする必要があるため、多くのテスターがいます。また、すべてのUI / UXが変更される理由を尋ねるのに夢中にならないでください...それがまさにその方法です...それが、アプリがUI / UXに対して多数の賞を受賞し、ユーザーがアプリ。思考プロセスは、1時間余分に時間をとってから何かを2％改善できるかどうかです。ユーザーはより幸せになり、より多くの$またはユーザーを意味します。はい、私たちのユーザーは、アプリが絶えず変化していることで大丈夫です。なぜなら、それが初日から行われている方法であり、悪いまたはネガティブとは思わないからです。

この投稿が華々しいものにならないことを願っていますが、コードレビューが無駄にならないことはわかりません。おそらく、レビューしたコードのすべてのコードの2％にバグがあります。各リリースでは、コードレビューで3つのバグが見つかる可能性があります。それで、リリースごとに開発者ごとに40時間のコードレビュー（4 x 40 = 160時間）になって3〜5個のバグを見つけることになりますか？とにかく3〜5個のバグがQAによって検出される可能性が50％です。開発者が新しい機能を追加したり、既存の機能を改善したりするのに、開発者ごとに40時間を費やす方が良いと思いませんか？

コードレビューでできることとできないことがいくつかあります。コードレビューを支持する議論：

• 集団所有権
• バグを見つける（QC）
• 一貫したスタイルを強制する（QA）
• メンタリング

多くのアジャイルプロセスがさまざまな方法でそれらに取り組んでいます。

• 集団所有権：チームの全員がプロジェクトの責任を負います。つまり、誰もがいつでもコードに目を向けることになります。
• リファクタリングが無料：これにより、コードレビューが次のレベルに進み、チームの誰でも必要に応じてリファクタリングを実行できます。
• 単体テスト（QC）：単体テストは、目視検査よりも効率的であり、ヒューマンエラーが発生しにくいです。実際、私はまだより効率的な手段を見つけていません。
• ペアプログラミング（QA）：メンタリングの面倒をみて、コードが記述されると、早期のリファクタリングのアドバイスを提供します。これも議論の余地のあるトピックですが、新しい開発者を増やす際に役立つと思います。また、コーディング標準を実施する良い機会です。

本質的には、通常ピアレビューを行うことで得られる可能性のある利益を処理する他の手段があります。ピアレビューの私の個人的な経験では、それらは非常に非効率的なメカニズムであり、バグや大きな設計上の欠陥を見つけるのに効果的ではありません。しかし、彼らはいくつかのチームに居場所を持ち、アジャイルが（何らかの理由で）実行可能でないプロジェクトでは、彼らは非常に必要です。

コードレビューはバグを見つけるためだけのものですか？あなたはそれが本当だと思うようですが、私はそうではありません。

コードレビューは、コードの集合的な所有権に関するものであり、知識が複数の頭の中にあることを保証し、新機能やバグの可能性があるコードを継承するために他の人を準備することを主張します。慣習を維持するためにどこで何かを書き直すことができるのか誰かがいつ知るかわからないので、システムのチェックとバランスをとる方法としてコードレビューが好きです。

ペアプログラミングは、コードレビューに対するXPの回答です。基本的に、コードのすべての行は、作成時にレビューされます。それは極端に取られたコードレビューです。

コードレビューとテストは同じ種類のバグをキャッチしないことが多く、バグの場所がわかっているため、コードレビューでキャッチされたバグは修正しやすい可能性があります。

コードが記録されていない状態でテストに合格したからといって、コードにバグがないかどうかを知ることはできません。「テストでは、バグの存在のみを証明でき、不在は証明できません。」（ダイクストラ？）

コードレビューでもコードスタイルは同じに保たれ、コードは良くないが今のところうまくいく場所を見つけることができます。将来の保守コストを節約します。

また、大企業とスタートアップの需要は異なります。スタートアップは通常失敗し、高速で移動する必要があります。大企業は、できるだけ早くというよりも、物事を正しく行うことでより多くの価値を獲得します。大企業よりもスタートアップで働くことを好むかもしれませんが、それは彼らが合わないスタートアップ戦略を課そうとする理由ではありません。

コードレビューはUI / UXの変更のみを行っていますか？私はそれがコードレビューではなく、ユーザビリティテストだと主張します。コードレビューは、ユーザー/テスター/ビジネス/見たことのない問題を解決するためのものです。なぜなら、彼らはコードの中にいるからです。その手がかりは名前の中にあります。

ここで、どこかに線を引くことに同意します。同じUIの変更を4回繰り返しますか？または、それを4回繰り返して、それぞれがコードの保守性を低下させる可能性がありますか？両方のアプローチを試して測定し、チームに適切なバランスを見つけようとしますが、コードレビューを完全に放棄しないでください。

コードレビューで問題が発生しなくても、そこに出会うまでめったに気付かないという利点があります。すべてのコードは2人の開発者によって確認されるため、2人の開発者は変更が何であり、何を達成することを意図しているかを知っています。そのうちの1人は翌日に病気になり、1週間休みます。もう1人は、彼らが行っていた緊急の仕事を取り戻すことができます。

集合的なコードの所有権とTDDおよびCIとの組み合わせは、正式なコードレビューセッションに対するアジャイルの解毒剤であることに同意する傾向があります。

UP / Spiralの下でも、特定のプロセスステップが「コードレビュー」であることの大ファンではありませんでした。なぜなら、同じエネルギーが代わりにいくつかの先行投資に投じられた場合よりも後で発見される可能性のある問題の種類が見つかったようですコラボレーションといくつかの簡単な自動化。

-設計の共有レビュー（通常は少なくともホワイトボードでUMLで表現される）が、大規模な設計の問題やAPIの不適切な使用などを意味し、多くのコードが書かれる前にキャッチされると感じました。-FxCop、CheckStyle、FindBugs（または同様のもの）を、自動化された継続的統合ビルドとともに実行して、命名、スタイル、可視性、コードの複製などをキャッチします。

ダウンストリームコードレビューの習慣が生み出すよりも早く失敗し、フィードバックを迅速に得ることができました。

時々座ってコードベースを見るのは時間の無駄だとは言っていませんが、コードレビューを何かを呼び出すためのゲーティングステップにすることは、進行中の多くの作業を作成するようですアップストリームでの検査/コラボレーションの改善により回避されます。

コードレビューから期待する主な目標の1つは、コードのメンテナンスを簡単にすることです。コードレビューは、すべての人が優れたコーディング標準に合理的に準拠した明確なコードを書くのに役立つはずです。ほとんどのコードは、特に大企業で多くのメンテナンスを取得します。保守可能なコードの回収は、コードがリリースされる前に開始し、その後継続する必要があります。

コードレビュー自体は、決してコードの変更をもたらさないはずです。コードレビューで変更が必要であることが示されている場合、変更を実装するとコードが変更されます。

コードの状態はレビューの結果として変更される可能性がありますが、それはあなたが言及した問題とはほとんど関係がないはずです。

コードレビューの結果、複数のコードが変更された場合、開発プロセスで何かが壊れています。あなたが持っているテスターの数を考えると、壁を越えて投げて、テスターに​​問題のメンタリティを見つけさせることができます。

物事は完了状態のテスターに​​送られるべきです。テスターが何度も同じものを再テストしないように、できるだけ多くのテストを自動化する必要があります。

UI / UXにはある程度のテスト時間が必要ですが、フロントエンドに設計/開発の専門家がいることで、それを減らすことができます。また、画面の前に顔が必要です。ただし、使用したすべてのアプリケーションで、コードの比較的小さな部分でした。

変更（バグ修正を含む）を実装するためのコストは通常​​、通過するすべての段階で増加します。一般に、開発中のバグを見つけることは、テストでバグを見つけてから修正するよりも安価です。