うまく機能していても、シニアや上司と一緒にプログラムを見直すのは良いことですか？

私の会社では、プロジェクトを実施する前に、上司は先輩に私や他のチームメンバーによって書かれたプログラムをレビューするように依頼します。

知識を得るには良い方法だと思いますが、プログラムがうまく機能していると、レビュー後も同じように機能しない場合があり、プログラムをもう一度調べる必要があります。

彼らは、レビューがプログラムとクエリの実行を最適化するのに役立つと言いますが、プログラムの実際の機能よりも最適化を好むことができますか？

「きちんと働く」ことは確かに素晴らしい指標ですが、あなたが書いたものを解読し、それを維持できるチーム内の唯一の人であれば、コードは中長期的に会社にとってほとんど価値がありません。

良いコードは少なくとも：

• 意図したとおりに動作する
• 人間が読める/クリア
• 簡単にメンテナンス可能
• 将来の変更に簡単に拡張可能
• 安全
• 不要な依存関係なし
• ノミナルでないケースを正しく処理する
• 等

（これらの要件の一部は実際には重複していますが、個別に検討するのに適しています...）

コードレビューは、自動テストを通じて実行できる「作業」部分を超えた目的に役立ちます。

私は、これが何かが引き裂かれて、それを一から作り直さなければならないことを悩ませていることを個人的に知っています。しかし、多くの場合、これはシニア/技術リーダーからの誤解によるものです。したがって、頻繁に書き換える必要があると思われる場合は、次回、1行を書く前に校閲者にアクセスして、彼が期待していることについて可能な限り多くの情報を取得してください。また、コードレビューアのチームが、すべての開発者が参照できる正式なドキュメントに期待を要約することもできます。

より良い面では、セッションは素晴らしいプラクティス/デザインを共有する機会でもあります。

私はあなたの質問を「機能しているコードがレビューでそれがコンパイルされないところまで屠殺できるか？」と解釈しました。。

はい、できます。通常、レビュー中に、コードがどのように機能するかを確認します。コードを渡したいときは、プログラムの特定の部分を終了したと言います。

あなたはそれが機能すると言います。次に、これを検証するためのテストが行​​われます。テストに合格したモジュールは、そのモジュールに再度触れてはならないという意味ではありません。

機能しているように見えるモジュールは、実行時、またはあなたや他の誰かがそれを保守しなければならないときに数ヶ月のうちに、発生するのを待っている災害になる可能性があります。レビューでコードを変更し、何が間違っていたのかを指摘することで、レビュー担当者は（できれば）実際に何かを教えようとしています。

ピアレビューは間違いなく素晴らしい学習方法です。誰かが何か違うものを見るかもしれません。彼らはあなたにとって異なる経験をしており、改善に貢献できるはずです。これは軽parすべきではありません。開発者は誰のコードにもコメントして建設的に批判できると期待しています！

これらの「改善」のいくつかが実際に破壊的な変更を行っているように思えますが、それは（ご想像のとおり）レビューを行う開発者が作成者よりもソフトウェアの経験が少ないためです。

この傾向は自己フィードバックであり、おそらくあなたのコードを追跡したり維持したりするのは難しいでしょうか？あなたのレビューは貴重ですか？絶対に！あなたの同僚が壊れているように見える作業コードを持っていることは、どのようにイライラするかを見ることができます。

問題は、プログラムの機能を保護する方法になり、レビューを完了した後も機能が機能していることがわかります。私の提案は、あなたがまともなユニットテストをカバーすることを確実にすることです。そうすれば、あなた/あなたのレビュアー/あなたの後継者がコードを変更するときはいつでも、彼らが行った変更は安全であると確信することができます。

ETA：あなたのコメントの1つを見つけました。これは言うまでもありませんが、テストチームが手に入れる前にコードレビューを行う必要があります。そうでなければ、彼らは最終製品をテストしていません。