コードレビューは本当に真のアジャイルで動作しますか？
それで私は、名前に3文字が含まれる企業の1つである大規模な企業で働き始めました。彼らはアジャイルになりたいと思っていますが、アジャイルだとは思えないプロセスがたくさんあります。
私が最も苦労したのはコードレビューです。私の最後の仕事は、私が今まで見た、今までに参加した、またはこれまでに聞いた中で最もアジャイルな開発チームであると言えるスタートアップの仕事でした。
とにかく、私の議論は、コードレビューは、UX/UIが極端/集中的である反復またはアジャイル開発における時間の浪費であるというものです（Apple/Steve Jobsの完璧さを考えてください）。たぶんここにいる誰かが私を解雇する前に理解するのを手伝ってくれる？
これが私の開発プロセスと最後のスタートアップ時のものです...非常にアジャイルです。
初期の機能作業を行って、開発タスク/タスクをソートします。いくつかのバージョンをモックアップしてユーザー、チーム、マーケティングに提示し、フィードバックを得ます。次に、モックアップを繰り返して、上記の同じ関係者から1つのラウンドを取得します。次に、作業を分割して開始します。達成すべきマイルストーンと日程はありますが、次第に離れていきます。この間、コードレビューはありません。開発の数週間に何度か、ステークホルダーとのセッションを再度開催し、機能/機能/ UX/UIが依然として適切で目標を達成していることに同意するかどうかを確認します。
8週間の反復サイクルの終わりに近づくと、QAがテストを開始し、それからアルファユーザーに、そして最後にベータユーザーに行きます。ただし、アルファ版とベータ版の開発者は、UIを毎日または1時間ごとに繰り返し変更して、UXを改善する新機能と旧機能を検討しています。したがって、このリリースで開発されていた機能は、改良して完成させるために、過去4週間にさらに3回変更されるか、いくつかの小さな機能を追加する可能性があります（たとえば、コンポーネントを少しスマートに、またはスマートにする）。変更が表面的である場合があります。つまり、CRUD操作は変更または変更されず、すべてのUIのみが変更されます。
このタイプの開発プロセスである極端なアジャイルでは、コードレビューは時間の無駄ではないでしょうか？別の開発者または2人にコードのレビューを依頼しても、UI/UXのすべての改善により、コードがドアに出る前にさらに3回変更された場合、最初の3回のレビューに時間を無駄にしていないことを意味します。そのコード/コンポーネント/ UIが廃棄されたときのコード？
このプロセスで多くの品質の問題が発生したことはありませんでした。開発者がすべての知識を残しておけば、それは実現しましたが、賢い開発者がそれを拾い上げて引き継ぐことは常にありました。
そして、はい、3回または4回再テストする必要がある可能性があるため、多くのテスターがいます。また、すべてのUI/UXの理由を尋ねるのに悩まないでください。変更...それがまさにそれがどのように行われるかです...それが、それがアプリがUI/UXのためにたくさんの賞を獲得し、ユーザーがアプリのために殺す理由です。思考プロセスは、私が2％の改善さえできるかどうかです。時間があるので、それを実行します。ユーザーはより幸せになります。つまり、$またはユーザーが増えます。そうです、ユーザーはアプリを継続的に変更しても問題ありません。それを悪いか否定的なものとして見てください
この投稿が大げさにならないことを願っていますが、コードレビューが無駄になっていないかどうかはわかりません。おそらく、レビューされたコードのすべてのコードの2％にバグがあります。リリースごとに、コードレビューで3つのバグを見つける可能性があります。つまり、3〜5個のバグを見つけるには、リリースごとに開発者1人あたり40時間のコードレビュー（4 x 40 = 160時間）になります。いずれにせよ、QAによって3〜5個のバグが検出された可能性は50％です。開発者1人あたり40時間を費やして、新しい機能を追加したり、既存の機能を改善したりするほうがいいのではないでしょうか。
コードレビューでできることはいくつかありますが、できないこともあります。コードレビューのfavorの引数：
- 共同所有
- バグを見つける（QC）
- 一貫したスタイル（QA）を適用する
- メンタリング
多くのアジャイルプロセスは、さまざまな方法でそれらに取り組みます。
- 共同所有権：チームの全員がプロジェクトの責任を負います。つまり、全員の目がいつでもコードに注目することになります。
- 無料のリファクタリング：コードレビューを次のレベルに引き上げ、チームの誰でも必要に応じてリファクタリングを実行できます。
- 単体テスト（QC）：単体テストは、目視検査よりも効率的で、人為的エラーが発生しにくくなります。実際、私はまだより効率的な手段を見つけていません。
- ペアプログラミング（QA）：メンタリングを担当し、コードの記述時に初期のリファクタリングアドバイスを提供します。これも議論の余地のあるトピックですが、新しい開発者を増やすのに役立ちます。また、コーディング標準を適用する良い機会でもあります。
本質的には、通常は査読を行うことで得られる可能性のある利益を処理する他の方法があります。ピアレビューに関する私の個人的な経験は、それらは非常に非効率的なメカニズムであり、バグや大きな設計上の欠陥を見つけるのに効果的ではないということです。ただし、一部のチームではその役割を果たしており、（何らかの理由で）アジャイルが実行できないプロジェクトでは、それらは非常に必要です。
コードレビューはバグを見つけるためのonlyですか？あなたはそれが本当だと思っているようですが、私は違います。
コードレビューは、コードの集合的所有権、知識が複数の頭にあることの確認、および新機能やバグの可能性があるコードを継承する他の人の準備に関するものである可能性があると私は主張します。規則を維持するために何かをどこに書き直すべきかを誰かがいつ知っているのかわからないので、コードレビューを少しチェックしてシステムのバランスをとる方法として気に入っています。
ペアプログラミングはXPコードレビューへの回答です。基本的に、コードのすべての行は記述されたとおりにレビューされます。これは極端なコードレビューです。
多くの場合、コードレビューとテストでは同じ種類のバグが検出されません。コードレビューで検出されたバグは、バグの場所がわかっているため、修正が容易になる可能性があります。
何も記録されていないテストに合格したという理由だけで、コードにバグがないかどうかはわかりません。 「テストは、バグの存在を証明するだけで、不在を証明することはできない」 （ダイクストラ？）
コードレビューは、コードスタイルを同じに保ち、コードが良くないがたまたま今は機能する場所を見つけることができます。メンテナンス費用を削減できます。
また、大企業と新興企業の要求は異なります。スタートアップは通常失敗し、速く動く必要があります。大企業は、できるだけ早くというよりは、正しいことからより多くの価値を得ます。大企業よりも新興企業で働くことを好むかもしれませんが、それが新興企業に適さない場所で新興企業戦略を課そうとする理由ではありません。
あなたのコードレビューは、UI/UXの変更を明らかにするだけですか？これはコードレビューではなく、ユーザビリティテストです。コードレビューは、コードに含まれているため、ユーザー/テスター/ビジネス/何も見えない問題を明らかにすることに関するものです。手がかりは名前のすぐそこにあります。
さて、どこかに線が引かれることに同意します。同じUI変更の4つの反復を確認しますか？それとも、4回の反復を行いますが、それぞれがコードの保守性を低下させる可能性がありますか？両方のアプローチを試して測定し、チームに適切なバランスを見つけますが、コードレビューを完全に放棄しないでください。
コードレビューで問題が発生しない場合でも、問題がなくなるまでほとんど気付かないという利点があります。すべてのコードは2人の開発者によって参照されるため、2人の開発者は変更内容とそれが達成しようとした意図を知っています。 。そのため、1人は翌日病気になり1週間休み、もう1人は彼らが行っていた緊急の作業を引き受けることができます。
集合的なコード所有権とTDDおよびCIとのペアリングは、正式なコードレビューセッションに対するアジャイルの解毒剤であることに同意する傾向があります。
UP/Spiralの下でも、特定のプロセスステップの「コードレビュー」の大ファンではなかったコラボレーションと簡単な自動化。
-通常、少なくともホワイトボードでUMLで表現されるデザインのレビューを共有すると、大規模なデザインの問題やAPIの不適切な使用などが発生し、多くのコードが記述される前に引っ掛かってしまいます。 -FxCop、CheckStyle、FindBugs（または同様のもの）は、自動化された継続的インテグレーションビルドと共に実行され、ネーミング、スタイル、可視性、コードの重複などをキャッチします。
ダウンストリームのコードレビューの習慣が生み出すよりも早く失敗してフィードバックを得ることができました。
たまに座ってコードベースを確認するのは時間の無駄だと言っているわけではありませんが、コードレビューを何かを呼び出すためのゲーティングステップにすると、進行中の多くの作業が作成されるように思えます上流でのより良い検査/コラボレーションにより回避されます。
コードレビューに期待する主な目標の1つは、コードの保守を容易にすることです。コードレビューは、誰もが優れたコーディング標準に合理的に準拠した明確なコードを書くのに役立つはずです。特に大企業では、ほとんどのコードに多くのメンテナンスが必要です。保守可能なコードの回収は、コードがリリースされる前に開始し、その後も継続する必要があります。
コードレビュー自体は、コードの変更をもたらすべきではありません。コードレビューで変更が必要であることが示された場合、変更を実装するとコードが変更されます。
コードの状態はレビューの結果として変わる可能性がありますが、それはあなたが言及する問題とはほとんど関係がないはずです。
コードレビューの結果、複数のコードが変更される場合は、開発プロセスで問題が発生しています。あなたが持っているテスターの数を考えると、壁を越えてそれを投げ、テスターに問題の考え方を見つけさせることができます。
物事は完成した状態でテスターに行く必要があります。テスターが何度も同じものを再テストしないように、できるだけ多くのテストを自動化する必要があります。
UI/UXにはある程度のテスト時間が必要ですが、フロントエンドに設計/開発の専門家がいると、それを減らすことができます。また、画面の前に顔が必要です。ただし、これまでに使用したすべてのアプリケーションで、コードのごく一部でした。
変更（バグ修正を含む）を実装するコストは、一般的に、それが通過するすべての段階で増加します。開発中のバグを見つけることは、テストして見つけた後で修正するよりも一般的に安価です。