他の人が非常に複雑なソリューションを構築したとき、コードレビューで何と言いますか？[閉まっている]

先日、チームの誰かが書いたコードをレビューしました。ソリューションは完全には機能せず、デザインは複雑でした-不要な情報の保存、不要な機能の構築を意味し、基本的にコードには金メッキのような不要な複雑さがたくさんあり、存在しない問題を解決しようとしました。

この状況では、「なぜこのようにしたのですか？」

答えは、他の人がそのようにしたいと感じていることです。

次に、これらの機能のいずれかがプロジェクト仕様の一部であるかどうか、エンドユーザーが使用できるかどうか、または追加データがエンドユーザーに提示されるかどうかを尋ねます。

答えはいいえだ。

そこで、不必要な複雑さをすべて削除することをお勧めします。私が通常得る答えは、「それはすでに終わっています」です。

私の見解では、それは行われておらず、バグがあり、ユーザーが望むことを行わず、メンテナンスコストは、私が提案したより簡単な方法で行われた場合よりも高くなります。

同等のシナリオは次のとおりです。
同僚が10秒以内にResharperで自動的に実行できたコードを手作業でリファクタリングするのに8時間かかります。当然のことながら、手作業によるリファクタリングは疑わしい品質であり、十分にテストされていないため、信頼できません。
繰り返しになりますが、私は「既に完了しています」という応答を受け取ります。

この態度に対する適切な対応は何ですか？

メンタリティ/態度

• 例でリード
• プライベートで勧告する（1対1、コードレビュー外）
• チームメンバー間のシンプルなメンタリティを奨励する

チーム管理

• ワークアイテムの仕様（アーキテクチャ、アルゴリズムアウトライン、UIワイヤフレームなど）により多くの時間を費やす
• チームメンバが作業項目の範囲について明確化を求めるように奨励する
• チームメンバにワークアイテムの実装方法について話し合うことを奨励する
• 開始する前に各ワークアイテムの合理的な見積もりを行い、それらを満たすために最善の努力をします
• チームメンバーの「改善」を監視します。
  • 忠告されたり、物事を行う正しい方法が示された後、チームメンバーが改善するかどうかを確認します。

スキルレベル

• 開発者ツール（リファクタリング、コードレビュー）を最大限に活用するために、ペアプログラミングセッションまたは1対1のトレーニングセッションに時間を割り当てます。

プロジェクト（リスク）管理

• 非同期でコードレビューをより頻繁に実施する（注）
  • 「非同期」に関する注意
    • コードレビューアは、コミットされるとすぐに変更をレビューするための通知/招待を受け取る必要があります
    • コードレビューアは、開発者とのミーティングの前にコードをレビューする機会が必要です。
    • 開発者からの説明が必要な場合は、否定的な意見を投げかけることなくIM /電子メールで非公式にそれを行う

他の人が非常に複雑なソリューションを構築したとき、コードレビューで何と言いますか？

あなたは言う：「あなたは非常に複雑なソリューションを構築した」。

そこで、不必要な複雑さをすべて削除することをお勧めします。私がよく受ける答えは、「それはすでに完了している」ということです。

何も変更するのが遅すぎる場合、なぜコードレビューを行っているのですか？

「すでに行われています」は満足のいく答えではありません。完了とは、テスト済みで動作していることを意味します。役に立たない余分なコードはすべて、適切な方法で維持（削除）する必要があります。

彼にこのタスクを再度割り当て、ソリューションをリファクタリングおよび最適化するよう依頼します。彼がそうしなければ、彼にペアプログラマーを割り当て、彼が同僚から何かを学ぶことを願っています。

そこで、不必要な複雑さをすべて削除することをお勧めします。私が通常得る答えは、「それはすでに終わっています」です。

それは受け入れられる答えではありません：

• 変更するのが本当に遅すぎる場合、コードレビューはほとんど時間の無駄であり、管理者はこれを知る必要があります。

• それが本当に「私は変えたくない」と言う方法であるなら、あなたは余分な複雑さがコードベースにとって悪いことであるという立場を取る必要があります。そして、あなたが最初にコードレビューをしている本当の理由で、将来の問題の可能性を減らします。

そして...

...ソリューションは完全に機能していませんでした...

これは、不必要な複雑さの直接的な結果である可能性が非常に高いです。プログラマーは非常に複雑になったため、もはや完全に理解できず、機能ポイントではなく複雑さを実装するために時間を無駄にしました。プログラマーに指摘する価値はありますが、複雑さを排除することで、実際に作業プログラムをより速く実現できるかもしれません。

今、あなたはこれに「一生懸命押し戻す」力（またはおそらく自信）を持っていないように思えます。たとえそうであっても、問題のあるコーダーが次の仕事をすることを期待して、このことについて少し（それをパーソナライズせずに）ノイズを立てる価値があります...次回。

この態度に対する適切な対応は何ですか？

最終的には、管理者の注意を引く必要があります...自分で修正する権限がない限り。（もちろん、これはあなたを人気にするものではありません。）

あなたは正しかった、彼らは間違っていた：

• 壊れたYAGNI原理
• 壊れたKISSの原則
• コードは完全にテストされていますか？いいえの場合、それは行われません

この態度に対する適切な対応は何ですか？

適切なコードレビューを行います。提案された変更を理由なく実装することを拒否した場合、1つのコードのレビューに時間を浪費するのをやめます。問題を上司にエスカレートすることもできます。

このような場合に状況を劇的に改善した私たちのチームが行ったアクションの1つは、はるかに小さなチェンジセットへの移行でした。

1つのタスクに1日以上取り組んでから（大規模な）コードレビューを行う代わりに、はるかに頻繁にチェックインを試みます（1日に最大10回）。もちろん、これにはいくつかの欠点もあります。たとえば、レビュアーは非常に敏感である必要があり、頻繁に中断するために自身の出力が減少します。

利点は、間違った方法で大量の作業が行われる前に、問題が検出され、早期に解決できることです。

問題の根本原因に注目する必要があります。

1. プログラマーの教育は、プログラマーに与えられる複雑さの増大に焦点を当てています。これを行う能力は、学校によってテストされました。したがって、多くのプログラマーは、単純なソリューションを実装した場合、自分の仕事を正しく行わなかったと考えるでしょう。
2. プログラマーが大学在学中に何百回も同じパターンを実行した場合、それはプログラマーが考えていることです- 複雑さを増すことはより困難であり、したがってより良いです。
3. そのため、これを修正するには、プログラマーの教育で通常必要とされるものと比較して、会社の要件が複雑さに対して相対的に厳密に分離する必要があります。優れた計画とは、「最高の複雑度レベルは、スキルを向上させるために設計されたタスクにのみ予約する必要があり、実稼働コードでは使用しない」というルールです。
4. 多くのプログラマーにとって、重要な実稼働コード環境で最もクレイジーな設計を行うことが許可されていないことは驚きになります。プログラマーが実験的な設計を行うための時間を確保し、フェンスのその辺ですべての複雑さを保ちます。

（コードレビューでは、変更するには遅すぎます）

コードが記述された後に機能するものは何も知りません。

コードを書く前に、人々はそれを行う別の方法を議論することができます。キーはお互いにアイデアを提供することなので、合理的なものが選ばれることを願っています。

請負業者と連携する別のアプローチがあります-固定価格契約。ソリューションが単純であるほど、プログラマーが保持できる$$は多くなります。

世界を修正することはできません。

プロジェクトのすべてのコードを修正することさえできません。少なくとも今月は、プロジェクトの開発方法を修正できないでしょう。

残念ながら、コードレビューで経験していることはあまりにも一般的です。私はいくつかの組織で働いており、10で書かれた可能性のある100行のコードをレビューしていることがよくありました。「答えはすでに書かれ、テストされています」または「探しています」再設計ではなくバグです。」

同僚の何人かはあなたができるほどうまくプログラムできないことは事実です。それらのいくつかはそれでかなり悪いかもしれません。心配しないでください。不完全な実装を備えたいくつかのクラスは、プロジェクトをダウンさせません。代わりに、他の人に影響を与える仕事の部分に焦点を当てます。ユニットテストは適切ですか（もしあれば）？インターフェイスは使用可能ですか？文書化されていますか？

不正なコードへのインターフェースに問題がなければ、それを維持する必要があるまで心配しないで、それを書き直してください。 何か不満がある場合は、リファクタリングと呼んでください。それでも不満がある場合は、より洗練された組織での職を探してください。

プロジェクトには、成果物の品質チェック手順と使用ツールを管理する標準ポリシーが必要です。

人々は、自分がすべきことと、このプロジェクトで使用が認められているツールを知っている必要があります。

まだこれを行っていない場合は、考えを整理して実行してください。

コードレビューには、標準アイテムのチェックリストが必要です。「既に行われている」とわかっても、そうではない場合、個人的には、プロジェクトマネージャーまたは上級開発者としてこの開発者の仕事に責任を負いたくありません。この態度を容認してはなりません。私は何かやすべてのことをする方法について議論していることを理解できますが、解決策が受け入れられたら、嘘は容認されるべきではなく、それは明確に述べられるべきです。

ショップでは、いくつかの設計手法を実施する必要があります。

• 要件を明確に定義する必要があります。
• 要件をサポートするユースケースを開発する必要があります。
• ユースケースの実装に必要な関数を指定する必要があります。
• 機能以外の要件（応答時間、可用性など）を指定する必要があります。
• 各システム機能をユースケースと実際の要件にマッピングするには、RTM（Requiements Tracabilty Matrix）が必要です。
• 実際の要件をサポートしていない機能はすべて削除してください。
• 最後に、コードレビューで、定義された関数を直接実装またはサポートしないコードにフラグを立てます。

おそらく、それが過度に複雑であるということではありません。それは、ほとんどの人がその後気分が悪くなるからです。これが既に起こったとき、それについて一言も話さずに多くのコードが書かれたと思います。（なぜそうなのか？その人は十分な権限を持っているため、コードを実際にレビューする必要がないのですか？）

それ以外の場合は、コードレビューを形式的ではなく、より頻繁にすることをお勧めします。そして、大規模なモジュールを作成する前に、どのアプローチを取るべきかをすぐに議論する必要があります。

「これは複雑すぎる」と言っても、どこにも行き当たりません。

不幸なことですが、コードレビューは多くの場合、現在よりも未来のために行われます。特にエンタープライズ/企業環境では、出荷されたコードは出荷されていないコードよりも常に価値があります。

もちろん、これはコードレビューがいつ完了するかによって異なります。開発プロセスの一部である場合は、すぐにいくつかの利点を得ることができます。ただし、CRがより多くの事後分析として扱われる場合は、今後何が改善できるかを指摘するのが最善です。あなたの場合（他の人が言っているように）、YAGNIとKISS全般、そしておそらくこれらの原則を適用できる特定の領域のいくつかを指摘してください。

overly complexはどういう意味ですか？あいまいなステートメントを作成すると、それに応じてあいまいな/不満足な答えが返されます。ある人にとって過度に複雑なことは、他の人にとって完璧です。

レビューの目的は、特定の問題やエラーを指摘することであり、それが気に入らないということではなく、「過度に複雑な」ステートメントが意味するものです。

問題が（過度に複雑に）表示された場合は、次のようなより具体的なことを言ってください。

• パートXからYに変更すると、コードが単純化されたり、理解しやすくなりませんか？
• ここでパートXで何をしているのかわかりません。あなたがやろうとしていたのはこれだと思います。よりクリーンな方法を提示します。
• これをどのようにテストしましたか？これをテストしましたか？それが過度に複雑な場合、これは通常空白の凝視につながります。テストを依頼すると、元のコードをテストする方法がわからない場合に、コードを自己単純化できるようになることがよくあります。
• ここにエラーがあるようです。これにコードを変更すると問題が解決します。

誰でも問題、特に曖昧な問題を指摘できます。ソリューションを提示できるはるかに小さなサブセットがあります。レビューのコメントはできる限り具体的にする必要があります。何かが過度に複雑であると言うことはあまり意味がなく、コードを理解できないためにあなたが無能であると他人に思わせることさえあります。ほとんどの開発者は、良い設計と悪い設計の違いの手がかりを持たないことに留意してください。

グループとして、「アジャイル」原則のいくつかに焦点を当てる価値がある場合があります。彼らは、コースから少し外れているように見えるグループまたは個人を助けることができます。

フォーカシングとは、チームの大幅なやり直しを意味する必要はありませんが、座って、チームとして最も重要なプラクティスを議論する必要があります。少なくともこれらの（そしておそらくさらにいくつか）について議論することをお勧めします。

• おそらく動作する可能性のある最も単純なことはありますか？
• あなたはそれを必要としません（仕様になかった問題を解決していますか）
• コーディングする前にテストを書く（コードに集中するのに役立ちます）
• 繰り返すな

また、機能するもの、機能しないもの、まだ必要なものの時々の（毎週？）レビューが本当に役立つ場合があります...他に何もなければ、チームの価値と実践を議論するために週に1時間を約束してください。

エスカレーション。技術的なことを考えているマネージャーがいる場合。これは壊れる必要がある習慣のように聞こえます。

コードが仕様どおりに構築されていない場合、定義によりコードレビューに失敗します。「誰も要求していないことをやったのに、それが機能していないので、誰かがその機能を要求したことをするのではなく、そのままにしておく」という概念がわかりません。

これは開発者が入るには悪い習慣です。彼/彼女が設計仕様に取り組んでいた場合、正当な理由なしにそれを一致させないことはノーです。

一言：アジャイル

確かにすべてを解決するわけではありません。ただし、反復（たとえば1〜2週間）を管理し、進行中の作業を制限し、スプリントの計画/レビューを活用することで、このような滝のような間違いを避ける必要があります。実際に行われていることを、より正確に把握する必要があります。

通常のプロジェクトベースの開発では、スクラムアプローチを採用することをお勧めします。継続的な開発/統合環境の場合、特に同じプロジェクトまたは関連するプロジェクトで多くの開発者が作業している場合は、かんばんの要素を組み込むことを検討してください。もう1つの効果的なアプローチは、ペアプログラミング、エクストリームプログラミングの定義済みプラクティスを活用することです。

あなたの状況はほとんどユニークではありません。また、小規模なチームであっても、プロセスは現在の状況を回避するのに役立ちます。適切な可視性と適度に整理されたバックログにより、これらの質問はスプリント計画の決定になり、技術的な負債を管理する必要がなくなります。

過去に私が言ったことは、「このコードは複雑であり、何をしようとしているのか自信がありません。それを単純化するか、より明確に書くことは可能ですか？」です。

コードを削除またはロールバックした後、コーダーに次のように伝えます。

「私の次のレビューは20分です。

"良い一日。"

引数を受け入れないでください！

完了、私見

クリス