上手くいっていても、先輩や上司と一緒に見直すのはいいですか？
私の会社では、プロジェクトを実施する前に、上司が先輩に私や他のチームメンバーが作成したプログラムのレビューを依頼するか、上司がレビューのために同席することもあります。
これは知識を得るための良い方法だと思いますが、プログラムが正常に機能している場合、レビュー後にそれらが同じように機能しないことがあり、プログラムをもう一度調べる必要があります。
彼らは、レビューはプログラムとクエリの実行を最適化するのに役立つと述べていますが、プログラムの実際の機能よりも最適化を優先できますか？
「正常に機能している」というのは確かに優れた指標ですが、チーム内であなたが書いたものを解読してそれを維持できるのがあなただけである場合、コードは中長期的に会社にとってほとんど価値がありません。
良いコードは少なくとも：
- 意図したとおりに機能している
- 人間が読める/明確
- 簡単にメンテナンス可能
- 将来の変更のために簡単に拡張可能
- 安全
- 不要な依存関係なし
- 名目的でないケースを正しく処理する
- 等
（これらの要件の一部は実際には重複していますが、個別に検討することをお勧めします...）
コードレビューは、自動テストを通じて実行できる「実際の」部分以外の目的にも役立ちます。
私は個人的に、これが機能しているものを引き裂かれ、ゼロから再構築しなければならないことは不愉快であることを知っています。しかし、多くの場合、これはシニア/技術リーダーからの誤解が原因です。したがって、頻繁に書き換える必要があると思われる場合は、次回、1行を書き込む前にレビュー担当者に連絡し、彼が期待している内容について可能な限り多くの詳細を入手してください。また、コードレビューアのチームが、すべての開発者が参照できる正式なドキュメントに期待を要約すると、すばらしいでしょう。
より肯定的な面では、セッションは優れたプラクティス/デザインを共有する機会にもなります。
私はあなたの質問をとして解釈しました「レビューで機能しているコードを、コンパイルできなくなるまでレビューに肉付けできますか？」。
はい、できます。一般に、レビュー中にhowを確認すると、コードはそれを実行します。コードを提出したいときは、プログラムの特定の部分を終了したと言います。
あなたはそれがうまくいくと言います。次に、これを検証するためのテストが行われます。モジュールがテストに合格したからといって、モジュールに再度触れてはならないというわけではありません。
機能しているように見えるモジュールは、実行時またはあなたや他の誰かがそのモジュールのメンテナンスを実行しなければならない場合、実行時または数か月のいずれかで発生するのを待っている災害です。レビューのコードを変更して、何が問題であるかを指摘することにより、レビュアーは（うまくいけば）実際に何かを教えようとしています。
ピアレビューは間違いなく素晴らしい学習方法です。誰かが何か違うものを見るかもしれません、彼らはあなたに異なる経験をしていて、改善に貢献することができるはずです。これは軽蔑すべきものではありません。どんな開発者もコメントして建設的に誰かのコードを批評できると思います！
これらの "改善"のいくつかは実際には重大な変更を行っているように思えます。なぜなら、（ご想像のとおり）レビューする開発者は、作成者よりもソフトウェアの経験が少ないためです。
この傾向は、それが自己フィードバックであり、おそらくコードの追跡や維持が難しいですか？あなたのレビューは価値がありますか？絶対に！私はそれがいかに苛立たしいかを見ることができます。ピアが壊れているように見える作業コードを持っていることは、落胆しないでください-これらの変更からコードを保護するように作業する必要があります。
次に、問題はプログラムの機能を保護する方法となり、レビューの完了後も機能が機能していることを確認できます。私の提案は、適切な単体テストカバレッジを確保することです。そうすれば、あなた/あなたのレビュアー/あなたの後継者がコードを変更するときはいつでも、彼らは彼らが行った変更が安全であると確信することができます。
ETA：私はあなたのコメントの1つを見つけました、これは言うまでもありませんが、コードレビューはテストチームがそれを得る前に行う必要があります。そうでなければ、彼らは最終製品をテストしていません。