レビュー中に他人の不適切に設計されたコードの改善を巧みに提案するにはどうすればよいですか？
私はクリーンなコードとコードのクラフトマンシップを非常に信じていますが、私は現在、これが最優先事項と見なされていない仕事をしています。ピアのコードがriddledであり、機能が問題なく、バグがほとんどないが、将来のメンテナンスの心配がほとんどない状況に陥ることがあります。
変更が必要なことがたくさんあり、期限が迫っている場合、コードレビューの改善を提案するにはどうすればよいですか？改善の提案後締め切りは、新しい機能とバグ修正が行われるときに、優先順位が完全に下がる可能性があることを覚えておいてください。
動機を再確認してください。コードを変更する必要があると思われる場合は、変更する必要があると考える何らかの理由を明確にできる必要があります。そしてその理由は、「私は別の方法でやったであろう」または「醜い」よりも具体的であるべきです。提案された変更から得られる利点を指摘できない場合、変更に時間（つまりお金）を費やす意味はほとんどありません。
プロジェクトのすべてのコード行は、保守する必要がある行です。コードは、その仕事を成し遂げ、簡単に理解できるようにするために必要な長さでなければなりません。明快さを犠牲にすることなくコードを短くできれば、それは良いことです。明快さを増しながらそれができるなら、それはずっと良いことです。
コードは具体的なものです。しばらく座った後で変更するのはより困難です。可能な場合は変更を早期に提案し、変更のコストとリスクの両方を最小限に抑えます。
すべての変更にはお金がかかります。機能し、変更する必要がないと思われるコードを書き直すことは、無駄な労力となる可能性があります。変更の対象となるセクション、またはプロジェクトにとって最も重要なセクションに注意を向けます。
フォームは機能に従い、時にはその逆です。コードが乱雑である場合、バグも含まれている可能性が高くなります。それらのバグを探し、コードの美的魅力ではなく欠陥のある機能を批判します。コードの動作を改善する提案およびにより、コードの動作を簡単に確認できます。
設計と実装を区別します。くだらないインターフェイスを持つ重要なクラスは、癌のようなプロジェクトを通じて広がる可能性があります。これは、プロジェクトの残りの部分の品質を低下させるだけでなく、損傷の修復の難しさを増大させます。一方、適切に設計されたインターフェイスを備えたクラスでも、実装が粗末であることは大した問題ではありません。いつでもクラスを再実装して、パフォーマンスや信頼性を向上させることができます。または、それが正しく機能し、十分に高速である場合、それをそのままにして、その残骸が十分にカプセル化されているという知識で安心できます。
上記のすべてのポイントを要約すると：提案された変更が価値を追加することを確認してください。
リファクタリングを通じて価値を追加するためのスイートスポットがあります。変更は3つのことを達成する必要があります。
- 変更される可能性のあるコードを改善する
- 明快さを増す
- 最小限の労力
考慮事項：
- クリーンなコードは、作成と保守にかかる費用が少なく、作業が楽しいことを知っています。あなたの仕事はあなたの会社の人々にそのアイデアを売ることです。傲慢なうわべではなく（つまり、私ではなく）、セールスマンのように考えてください。
- あなたは勝つことができません、あなたはより少なく失うことができるだけです。
- 美しさだけでなく、真の付加価値に焦点を当てます。私のコードは見栄えが良いのが好きですが、時にはその安価な問題をもっと受け入れる必要があります。
- スイートスポットを見つける良い方法は、ボーイスカウトの原則に従うことです。コードの領域で作業するときは、常に見つけたよりも良い形にしてください。
- 小さな改善は改善なしよりも優れています。
- 自動化されたツールを十分に活用します。たとえば、少しだけフォーマットをクリーンアップするツールは、worldの違いを生む可能性があります。
- 偶然にコードの明快さを改善する他のアイデアを売ります。たとえば、ユニットテストでは、大きなメソッドを小さなメソッドに分解することが推奨されます。
コードが重大なバグなしで機能し、主要な期限（影響P＆Lや企業のPRなど）が差し迫っている場合、大幅な変更を必要とする改善を提案するには遅すぎます。コードの改善でさえ、プロジェクトの展開にリスクをもたらす可能性があります。コードベースの将来の堅牢性に投資する時間があるプロジェクトの早い時期に、改善の時期がありました。
コードレビューには3つの目的があります。
バグをチェックする
コードを改善できる場所を確認する
コードを書いた人のための教育ツール。
デザイン/コード品質の評価は、もちろん＃2と＃3についてです。
＃2まで：
提案された変更と修正にかかるコストのメリットを明確にしてください。あらゆるビジネス上の決定と同様に、これはコスト/利益分析に関するものでなければなりません。
例えば。 「設計へのXのアプローチは、Zの変更時にバグYが発生する可能性を大幅に低減します。また、このコードは2週間ごとにタイプZの変更を受けることを知っています。バグYによる生産停止を処理するコスト+バグを見つける+次の一連の機能を提供しないことによる修正+機会費用の修正と解放は
$A;一方、コードを今すぐクリーンアップするコストと機会コスト（たとえば、配送が遅れたり、機能が少なくなったりするコスト）は$B。さて、評価してください-または、チームリーダー/マネージャーに評価してください$A対$Bと決定します。これは、スマートチームが効果的にこれを管理するのに役立ちます。例えば。彼らは完全な情報を使用して合理的な決定をします
これは（特にこれをうまく言えば）あなたのステータスを上げます-例えばあなたは、優れた設計の利点を理解できるほど賢く、ビジネス上の考慮事項を考慮せずに、それを宗教的に要求しないほど賢い人です。
そして、バグZが発生する可能性が高いイベントでは、次の一連の提案ではるかに多くの力を得ることができます。
＃3まで：
- 「これはベストプラクティスであり、リソースを節約できる場合は修正する必要があります-添付の賛成/反対分析を参照してください」から、「修正する必要がある」バグ/問題を非常に明確に描写します。これらは、コードのオプションの変更をより簡単に維持できるように、コードの堅牢性を向上させるのに役立つと思われる一般的なガイドラインです。言葉遣いに注意してください-それは「私が望むもののようにあなたのコードを作ること」についてではありません-それは「あなたがこれをするなら、あなたは利益a、b、cを得る」です。トーンとアプローチが重要です。
私のコメントは常に「そうする」から始めます。これは、私のものが単に多くの見解の1つであることを示しています。
私はいつも理由も含めます。
"私はこのブロックをメソッドに抽出理由読みやすさ。"
私はすべてについてコメントします。大小。時々私は変更について百以上のコメントをします。その場合、私はペアプログラミングもお勧めし、自分を翼男として提供します。
私は理由のために共通言語を確立しようとしています。可読性、DRY、SRPなど.
また、クリーンコードとリファクタリングに関するプレゼンテーションを作成しました。理由を説明し、その方法を同僚に説明しました。私はこれまでに3回開催しましたが、私たちが使用しているコンサルタントから、彼らのためにもう一度開催するように依頼されました。
しかし、一部の人々はとにかく耳を傾けません。それから私は階級を引っ張っています。私がデザインのリーダーです。コードの品質は私の責任です。この変更は、現在の状態では時計に反映されません。
私が行ったコメントについては、喜んで控えさせていただきます。技術的な理由、締め切り、プロトタイプなどのために。コーディングについても学ぶことがまだたくさんあり、常に理由に耳を傾けます。
おお、そして私は最近anyコメントのない重要でない変更を提出した私のチームの最初の人に昼食を買うことを申し出ました。 （ねえ、あなたも楽しんでいる必要があります。:-)
戦闘を選択してください。期限が近づいている場合は、何もしないでください。次回、他の誰かがコードをレビューまたは保守していて、問題が解決しない場合は、チームとしてコードをレビューするときはコードの品質にもっと焦点を当て、後でそれほど問題が発生しないようにする必要があると考えてアプローチします。
追加の作業を行う前に、値を確認する必要があります。
[この回答は、コードレビューに関する他の多くの質問へのリダイレクトであるため、最初に提起された質問よりも少し広いです。]
ここに私が役立つと思ういくつかの原則があります：
個人的に批判し、公に賞賛します。コードのバグについて1対1で誰かに知らせます。彼らが素晴らしいことをしたり、誰も望んでいないタスクを実行したりした場合は、グループミーティングで、またはチームにCCされた電子メールで彼らを称賛します。
自分の間違いを共有します。私の悲惨な最初のコードレビュー（受け取った）の話を学生やジュニアの同僚と共有します。私は自分の前にバグを見つけたので、バグをすぐに発見したことも生徒に知らせました。コードレビューでは、これは次のようになるかもしれません：「ここでインデックス変数が間違っていると思います。インデックスを間違ってデータセンターをダウンさせたので、常に確認します。」 [はい、これは本当の話です。]
肯定的なコメントをすることを忘れないでください。簡単な「いいね！」または「きちんとしたトリック！」ジュニアまたは安全でないプログラマの日を作ることができます。
相手が賢いが、時には不注意であると仮定します。言わないでください：「そうでない場合、呼び出し元が戻り値を取得するにはどうすればよいですか？実際にそれを返しますか？！」スクリプト：「返品のステートメントを忘れたようです。」初期の頃にひどいコードを書いたことを思い出してください。誰かがかつて言ったように、「あなたが1年前のコードを恥じていなければ、あなたは学んでいない」
職場にいない友人のために皮肉/嘲笑を保存します。コードがひどい場合は、他の場所で冗談を言ってください。 （他のプログラマーと結婚するのは便利だと思います。）たとえば、次の漫画（または これ ）を同僚と共有することはありません。
あなたの質問は「悪いデザインのコードをコードレビューする方法？」です：
IMOの答えは簡単です。コードのデザインと、設計の欠陥または要件を満たしていない方法について話します。欠陥のある設計を指摘したり、「要件を満たしていない」場合、開発者は必要なことを行わないため、コードの変更を余儀なくされました。
コードが「機能的に十分」および/または「仕様を満たす」および/または「要件を満たす」場合：
あなたがこの開発者の仲間である場合、変更を「彼に教える」ことができる直接的な力はありません。
いくつかのオプションが残っています：
- 自分自身の「影響力」（間接的な「力」の形）および/または「説得力」を発揮する能力を使用する必要があります
- 組織の「コードプロセス」グループに参加して、「コードメンテナンス」を優先度の高いものにします。
- 箇条書きをかじって、くだらないコードを素早く/より流暢に読む方法を学び、くだらないコードでハングアップしないようにしてください（くだらないコードに遭遇したときにハングアップしたりスローダウンしたりしているようです）。
- これはまたあなたをより強力なプログラマーにするでしょう。
- そして、それはあなたが安っぽいコードに取り組んでいるときにあなたが安っぽいコードを修正することを可能にします。
- そして、これはまた、多くのプロジェクトが機能しているくだらないコードを持っているので、より多くのプロジェクトに取り組むことを可能にします...しかし多くのくだらないコードです。
- 模範を示す。コードを改善してください...しかし、完璧主義者になろうとしないでください。
- それはあなたが「締め切りに間に合わず、常に批判し、彼が他の誰よりも優れていると考えている遅い人」になるからです。
特効薬はありません。あなたは3つすべてを使用する必要があり、3つすべての使用において創造的でなければなりません。
ピアのコードが乱雑な設計に悩まされ、将来のメンテナンスの心配がほとんどない状況に陥ることがありますが、機能的であり、バグはほとんどないかまったくありません。
このコードは完了です。ある時点で、再設計はコストがかかりすぎて正当化できなくなります。コードがすでに機能していてバグがほとんどない場合、これは不可能です。これを将来クリーンアップして次に進むためのいくつかの方法を提案します。コードが将来壊れる場合は、再設計の価値を再評価してください。壊れることはありません。どちらにしても、コストは今も後でも同じになるので、それが壊れないことを賭けるのが理にかなっている段階にあります。引き抜かれた、ひどい再設計です。
将来行う必要があるのは、より厳密な開発反復です。バグを修正するすべての作業に投資する前にこのコードを確認できたなら、再設計を提案することは理にかなっているでしょう。終わりに向かって、コードが根本的に維持不可能な方法で書かれていて、リリース後すぐにコードを変更する必要があることが確実にわかっている場合を除いて、大きなリファクタリングを行うことは決して意味がありません。
2つのオプション（リファクタリングまたはリファクタリングなし）から選択できる場合は、どちらが賢い販売のように聞こえるかを考えます。
こんにちは。予定通り、すべてが機能していましたが、今後は機能Xを追加できるように、多くのものを再構築します。
または
ちょっとボス、私たちは解放する準備ができています。機能Xを追加する必要がある場合は、さらに数日かかることがあります。
あなたがどちらか一方を言った場合、あなたの上司はおそらく言うでしょう：
誰が機能Xについて何か言いましたか？
結論としては、特定の欠陥を安くして（初期のイテレーション）修正できなかった場合、多少の技術的負債が意味をなす場合があります。 完成した機能と期限に近づくにつれ、高品質のコード設計を行うと、利益が減少します。
スプーン一杯の砂糖が薬の効き目を和らげるのに役立ち、何が悪いのかを簡潔に表現できる場合-20の間違いはありません-私は利害関係がないこと、自分が欲しいものに投資する自我がないことを示唆する形で導きます聞こえる。通常は次のようなものです。
それが良いのだろうか...
または
それは何か意味がありますか...
理由がかなり明白である場合、私はそれらを述べません。これにより、次のように、他の人々が提案の知的所有権を引き受ける機会が与えられます。
「はい、それは良い考えです。なぜなら、<ここでの明らかな理由>だからです。」
改善がかなり明白であるが、私がそれを考えないために馬鹿に見えるほどではなく、それを行う理由がリスナーと共有された値を反映している場合、代わりにそれを提案することさえありません：
方法はあるのでしょうか... <ここに共有価値ステートメント>
これは非常に微妙な人々に対処するためだけのものです-私の仲間のほとんどと一緒に、私はそれを手に入れさせます！
コードレビューは常に改善を目的としているわけではありません。
ここにあるように見えるプロジェクトの終わり近くのレビューは、バグが発生したときにどこから始めればよいかを誰もが知っているようにするためです（またはより優れた設計のプロジェクトについては、後で再利用できるかもしれません）。レビューの結果が何であれ、何も変更する時間はありません。
実際に変更を加えるには、プロジェクトのかなり前の段階でコードについて話し合い、設計する必要があります。コードは、可能なアプローチについて話すだけで存在する場合に変更する方がはるかに簡単です。
質問には2つの注目すべき問題があります。tactfullyの部分とdeadline up upの部分です。これらは明確な問題です。1つ目はコミュニケーションとチームダイナミクスの問題、2つ目は計画と優先順位付けの問題です。
巧みに。私はあなたがブラッシュエゴとレビューに対する否定的な反発を避けたいと思います。いくつかの提案：
- コーディング標準と設計原則について共通の理解を持っています。
- 開発者を批評したりレビューしたりせず、コードのみを批評してください。 「あなた」や「あなたのコード」という言葉は避け、レビュー中のコードについて話し、開発者から切り離してください。
- completedコードの品質に誇りを込めて、最終結果の改善に役立つレビューコメントが高く評価されるようにします。
- 需要ではなく提案改善。同意しない場合は、常に対話を行ってください。反対する場合は、別の視点を理解するようにしてください。
- レビューを両方向に進めます。つまり次に、レビューした人にコードをレビューしてもらいます。 「一方向」のレビューはありません。
2番目の部分は優先順位付けです。改善のための多くの提案がありますが、締め切りが近づいているため、いくつかを適用する時間があります。
さて、まず最初にこれを避けたいのですが！これを行うには、継続的な増分レビューを実行します。機能の開発に何週間も費やし、最後にすべてをレビューさせないでください。次に、コードレビューとレビューの提案を実装する時間は、すべてのタスクの定期的な計画と見積もりの一部である必要があります。適切にレビューするための十分な時間がなければ、何か計画が間違っています。
しかし、プロセスで何かがうまくいかなかったとしましょう。今、あなたは多くのレビューコメントに直面しており、それらすべてを実装する時間がありません。優先する必要があります。次に、変更を延期した場合、後で変更するのが最も困難でリスクが高い変更を行います。
ソースコードでの識別子の名前付けは、可読性と保守性にとって非常に重要です。butまた、将来変更することも非常に簡単でリスクが低くなります。コードのフォーマットと同じです。だから、そのことに集中しないでください。一方、公開されたインターフェースの健全性は、将来変更するのが非常に難しいため、最優先されるべきです。永続的なデータを変更するのは困難です。一貫性のないデータや不完全なデータをデータベースに初めて格納し始めた場合、将来修正するのは本当に困難です。
単体テストの対象となる領域は、リスクが低くなります。後でいつでも修正できます。ないがユニットテストできる領域は、できない領域ユニットテストされます。
単体テストがなく、外部サービスへのハードコードされた依存関係を含むあらゆる種類のコード品質の問題がある、大きなコードの塊があるとします。代わりに、この依存関係を挿入することにより、コードチャンクをテスト可能にします。これは、将来的にテストを追加し、、次に残りの問題の修正に取り組むことができることを意味します。ハードコードされた依存関係では、テストを追加することもできません。最初にこの修正を行ってください。
ただし、このシナリオにそもそも終わらないようにしてください。
致命的に悪い設計の場合、焦点はencapsulationを最大化することです。そうすることで、個々のクラス/ファイル/サブルーチンを、より適切に設計されたクラスに置き換えることが容易になります。
コンポーネントのパブリックインターフェイスが適切に設計されていること、および内部の仕組みが慎重に隠されていることを確認することに焦点を当てます。また、データストレージラッパーも不可欠です。 （保存されている大量のデータを変更するのは非常に困難な場合があるため、システムの他の領域に「実装ブリード」が発生すると、問題が発生します）。
コンポーネント間の障壁を取り除いたら、大きな問題を引き起こす可能性が最も高いコンポーネントに焦点を当てます。
締め切りまで、またはシステムが「完全」になるまで繰り返します。
誰かのコードに対する直接の直接の批判の代わりに、コードレビュー中のコメントで共謀することが常に望ましいです。
私が従う1つの方法は
- このようにすると最適です。
- このように記述すると、実行が速くなります。
- 「this」「this」「this」を実行すると、コードがより読みやすくなります
このようなコメントは、締め切りが迫っていても真剣に受け止められます。そして、おそらく次の開発サイクルで実装されます。
コードレビューの品質を向上させます。
レビュー対象のコードの品質とは別に、コードレビュー自体の品質などがあります。
- 提案された変更は本当に改善以上のものですか？
- それとも意見の問題ですか？
- 非常に明白なものでない限り、レビュアーは適切に説明していますかなぜ？
- どれくらいかかりましたか？ （私はレビューが数か月続くのを見てきましたが、多数のマージの競合をすべて解決するために開発者がレビューを担当しています）。
- トーン？
疑わしいエゴグルーミングよりも、良質のコードレビューを受け入れる方がはるかに簡単です。
コードレビューを機能させるには、文化と開発サイクルを統合する必要があります。機能Xの開発の最後に大規模なコードレビューのスケジュールを設定してもうまくいくとは思えません。まず第一に、変更を行うことは難しくなり、誰かが恥ずかしいと感じる可能性が高く、活動への抵抗が生じます。
コミットレベルでのレビューと相まって、早期かつ頻繁なコミットが必要です。コード分析ツールを使用すると、ほとんどのレビューが迅速になります。 FindBugs や [〜＃〜] pmd [〜＃〜] などの自動化されたコード分析/レビューツールは、ドアから大きなクラスの設計エラーを取得するのに役立ちます。ただし、これらはアーキテクチャレベルの問題を解決するのに役立ちません。そのため、適切な設計を行い、その設計に対してシステム全体を判断する必要があります。