他の人が非常に複雑なソリューションを構築したときのコードレビューで何を言いますか？
先日、チームの誰かが書いたコードをレビューしました。ソリューションは完全には機能せず、設計は非常に複雑でした。つまり、不要な情報を格納し、不要な機能を構築しました。基本的に、コードには金メッキのような多くの不要な複雑さがあり、存在しない問題を解決しようとしました。
この状況で、「なぜこのように行われたのか」と尋ねます。
答えは、他の人がそのようにしたいと思ったということです。
次に、これらの機能のいずれかがプロジェクト仕様の一部であるか、それともエンドユーザーに役立つか、または追加データのいずれかがエンドユーザーに提示されるかどうかを尋ねます。
答えはいいえだ。
それで、私は彼にすべての不必要な複雑さを削除することを勧めます。私が通常得られる答えは、「まあ、それはもう終わりました」です。
私の見解では、それは行われておらず、バグが多く、ユーザーが望むことを行わず、メンテナンスコストは、私が提案したより簡単な方法で行われた場合よりも高くなります。
同等のシナリオは次のとおりです。
同僚は8時間を費やしてコードを手動でリファクタリングしましたが、これはResharperで10秒で自動的に実行できたはずです。当然、手作業によるリファクタリングは信用できません。これは、疑わしい品質であり、十分にテストされていないためです。
私が得た返答は、「まあ、それはもう終わりました」です。
この態度に対する適切な対応は何ですか？
メンタリティ/態度
- 模範を示す
- 非公開で警告する（コードレビュー以外で1対1）
- チームメンバー間のシンプルな考え方を奨励する
チーム管理
- 作業項目の仕様（アーキテクチャー、アルゴリズムの概要、UIワイヤーフレームなど）により多くの時間を費やす
- 作業項目の範囲についての明確化を求めることをチームメンバーに奨励する
- チームメンバーが作業項目を実装する方法について話し合うことを奨励する
- 開始する前に各作業項目について合理的な見積もりを行い、それらを満たすために最善の努力をします
- チームメンバーの「改善」を監視します。
- 忠告されるか、物事を行うための正しい方法が示された後、チームメンバーが改善するかどうかを確認します。
スキルレベル
- 開発者ツール（リファクタリング、コードレビュー）を最大限に活用するために、ペアプログラミングセッションまたは1対1のトレーニングセッションに時間を割り当てます
プロジェクト（リスク）管理
- コードレビューをより頻繁に、非同期で実行する（注）
- 「非同期」に関する注意
- コードレビューアは、コミットされるとすぐに変更をレビューする通知/招待を受け取る必要があります
- コードレビューアは、開発者とのミーティングの前にコードをレビューする機会を持つ必要があります。
- 開発者からの説明が必要な場合は、否定的な意見を投げかけることなく、IM /メールで非公式に行う
- 「非同期」に関する注意
他の人が過度に複雑なソリューションを構築したときのコードレビューで何を言いますか？
「過度に複雑なソリューションを構築した」と言います。
それで、私は彼にすべての不必要な複雑さを削除することを勧めます。私が通常得る答えは、「まあ、それはもう終わりました」です。
何かを変更するのが遅すぎる場合、なぜコードレビューを行うのですか？
「もうできました」というのは満足のいく答えではありません。完了とは、テスト済みで動作していることを意味します。何も役に立たない余分なコードはすべて、適切な方法で維持する（削除する）必要があります。
彼にこのタスクを再度割り当て、彼のソリューションをリファクタリングして最適化するように依頼します。彼がそれを行わない場合は、ペアプログラマーを割り当て、同僚から何かを学べることを願っています。
それで、私は彼にすべての不必要な複雑さを削除することを勧めます。私が通常得られる答えは、「まあ、それはもう終わりました」です。
それは受け入れられる答えではありません：
本当に変更するには遅すぎる場合、コードレビューは主に時間の無駄であり、経営者はこれを知る必要があります。
それが本当に「変更したくない」という言い方の場合は、コードベースにとって余分な複雑さは問題/後で発生するコストのため、悪いという立場を取る必要があります。そもそもコードレビューを行う本当の理由は、将来の問題の可能性を減らすことです。
そして...
...ソリューションは完全に機能していませんでした...
それはおそらく、不必要な複雑さの直接的な結果です。プログラマが複雑にしてしまい、完全に理解できなくなった、または関数ポイントではなく複雑さを実装するために時間を浪費した。プログラマーに指摘しておくと、複雑さを排除することで、実際にプログラムをより速く実行できるようになる可能性があります。
さて、それはのように聞こえるあなたはこれに「強く押し戻す」力（またはおそらく自信）を持っていません。しかし、それでも、問題のあるコーダーがより良い仕事をすることを期待して、（これをパーソナライズせずに）これについて少し騒ぐ価値があります...次回。
この態度に対する適切な対応は何ですか？
最終的に、それを経営者の注意を引く...自分で修正する力がない限り。 （もちろん、これはあなたを人気にすることはありません。）
あなたは正しかった、彼らは間違っていた：
- 壊れた [〜＃〜] yagni [〜＃〜] 原則
- 壊れた [〜＃〜] kiss [〜＃〜] 原則
- コードは完全にテストされていますか？いいえの場合、それは行われません
この態度に対する適切な対応は何ですか？
適切なコードレビューを行います。彼らが理由なしに提案された変更の実装を拒否した場合は、1回のコードレビューに時間を浪費するのをやめてください。 問題を上司にエスカレーションすることもできます 。
そのような場合に状況を劇的に改善した私たちのチームが取った1つのアクションは、はるかに多くの小さなチェンジセットへの移行でした。
1つのタスクに1日以上取り組んでから（大規模な）コードレビューを行う代わりに、はるかに頻繁に（1日あたり最大10回）チェックインしようとします。もちろん、これにはいくつかの欠点もあります。レビュアーは非常に敏感である必要があり、（頻繁な中断のために）それ自体の出力を減らします。
利点は、間違った方法で大量の作業が行われる前に、問題が検出され、早期に解決できることです。
コードを書いた後、何が機能するかわかりません。
コードが書かれる前に、人々はそれを行うための別の方法について話し合うことができます。鍵はお互いにアイデアを提供することなので、うまくいけば合理的なものが選ばれるでしょう。
請負業者と連携する別のアプローチがあります-固定価格契約。ソリューションが単純なほど、プログラマーはより多くの$$を保持できます。
問題の根本原因に焦点を当てる必要があります。
- プログラマーの教育複雑さの増大に焦点を当てていますプログラマーに与えられます。これを行う能力は学校によってテストされました。したがって、多くのプログラマーは、単純なソリューションを実装した場合、正しく機能しなかったと考えます。
- プログラマーが大学で何百回も行ったのと同じパターンに従っている場合、それはプログラマーが考えている方法です（より複雑であるほど、より困難です）したがって、より優れています。
- したがって、これを修正するには、プログラマの教育で通常必要とされるものと比較して、複雑さに対する企業の要件の相対的な厳密な分離を保つを行う必要があります。適切な計画とは、「最高の複雑度レベルは、スキルを向上させるために設計されたタスクにのみ予約する必要があり、運用コードでは使用しない」というルールです。
- 重要な製品コード環境でクレイジーなデザインを行うことは許可されていないであることは、多くのプログラマにとって驚きになります。プログラマーが実験的な設計を行う時間を確保し、フェンスのその面ですべての複雑さを維持します。
（コードレビューでは、すでに変更するには遅すぎます）
世界を修正することはできません。
プロジェクトのすべてのコードを修正することもできません。おそらく今月は、プロジェクトの開発方法を修正できないでしょう。
悲しいことに、コードレビューで経験していることはすべて一般的です。私はいくつかの組織で働いていましたが、10行で記述できる100行のコードをレビューしていることがよくありました。「すでに記述およびテスト済み」または「私たちが探している」と同じ答えを得ました。バグであり、再設計ではありません。」
あなたの同僚の一部は、あなたのようにプログラムすることができないのは事実です。それらのいくつかはそれでかなり悪いかもしれません。心配しないでください。不完全な実装を持ついくつかのクラスはプロジェクトを停止しません。代わりに、他の人に影響を与える彼らの仕事の部分に焦点を当てます。 （もしあれば）単体テストは適切ですか？インターフェースは使えますか？文書化されていますか？
悪いコードへのインターフェースに問題がなければ、メンテナンスするまで心配しないでください、次に書き換えてください。不満がある場合は、リファクタリングと呼んでください。それでも不満がある場合は、より洗練された組織での役職を探します。
おそらくそれはほとんどの人が後で気分を悪くするので、それが過度に複雑であるということではないでしょう。私はこれが起こったとき、それについて1つの言葉を話すことなく多くのコードがすでに書かれていると思います。 （なぜそうなのか？その人には十分な権限があるので、コードを実際に確認する必要がないのですか？）
それ以外の場合は、コードレビューを正式ではなく頻繁に行うと思います。また、大きなモジュールを作成する前に、どのようなアプローチをとるかをすぐに検討する必要があるかもしれません。
「これは複雑すぎる」と言ってもどこにも行きません。
残念なことですが、コードレビューは、多くの場合、現在よりも未来のためのものです。特に企業/企業環境では、出荷されたコードは出荷されていないコードよりも常に価値があります。
もちろん、これはコードレビューがいつ完了するかに依存します。それが開発プロセスの一部である場合は、今すぐにいくつかの利益を得ることができます。しかし、CRが検死のように扱われる場合は、将来的に何ができるかを指摘することをお勧めします。あなたの場合（他の人が言ったように）、YAGNIとKISS一般的に、そしておそらくこれらの原則が適用される特定の分野のいくつかを指摘してください。
過度に複雑とはどういう意味ですか？あいまいな発言をすると、応答があいまい/満足のいく答えが得られます。ある人にとって過度に複雑なことは、別の人にとっては完璧です。
レビューの目的は、特定の問題やエラーを指摘することであり、それが気に入らないことは言うまでもありません。これは、「過度に複雑」なことを意味します。
問題が発生している（複雑すぎる）場合は、次のような具体的なことを言います。
- パーツXをYに変更すると、コードが簡略化されたり、理解しやすくなったりしませんか？
- パートXでここで何をしているのか理解できません。あなたがやろうとしていたのはこれだと思います。よりクリーンな方法を提示してください。
- これをどのようにテストしましたか？これをテストしましたか？それが過度に複雑である場合、これは通常空白の視線につながります。テストを依頼すると、元のコードをテストする方法がわからなかった場合に、コードを簡単に簡略化できるようになります。
- ここにエラーがあるようです。コードをこれに変更すると問題が解決します。
誰でも問題、特にあいまいな問題を指摘できます。解決策を提示できるはるかに小さなサブセットがあります。レビューのコメントはできるだけ具体的にする必要があります。何かが過度に複雑であると言っても、それほど意味はありません。それは、コードを理解できないために自分が無能だと他の人に思わせるかもしれません。ほとんどの開発者は、良いデザインと悪いデザインの違いを知る手がかりがないことに注意してください。
「アジャイル」の原則のいくつかに焦点を当てることは、グループとして価値がある場合があります。これらは、少しコースから外れているように見えるグループまたは個人を助けることができます。
フォーカシングは、チームの大幅なやり直しを意味する必要はありませんが、全員が座って、チームとして最も重要なプラクティスについて話し合う必要があります。私は少なくともこれら（そしておそらくかなり多くの数）について議論することをお勧めします：
- 機能する可能性のある最も単純なことを行いますか？
- あなたはそれを必要としないでしょう（あなたは仕様に含まれていない問題を解決していますか）
- コーディングの前にテストを記述します（コードの集中に役立ちます）
- 自分を繰り返さないでください
また、機能するもの、機能しないもの、まだ必要なものについて、時々（毎週？）確認することは非常に役立ちます。他に何もない場合は、週に1時間、チームの価値観と実践について話し合ってみませんか？
エスカレーション（技術に詳しいマネージャーがいる場合）。これは壊れる必要がある習慣のように聞こえます。
コードが仕様どおりにビルドされていない場合、定義上、コードレビューに失敗します。 「だれもが要求したことをしなかったので、うまくいかなかったので、だれかが要求したことをする代わりに、そのままにしておきます」という概念がわかりません。
これは、どんな開発者も入り込むのが悪い習慣です。もし彼/彼女が設計仕様に取り組んでいたなら、正当な理由なしにそれを一致させなかったことはノーノーです。
一言：アジャイル
それは確かにすべてを解決するわけではありません。ただし、イテレーション（たとえば1〜2週間）を主導し、進行中の作業を制限し、スプリントの計画/レビューを活用することで、ウォーターフォールのような間違いを回避する必要があります。実際に何が行われているのか、それが行われている間、より優れた可視性が必要です。
通常のプロジェクトベースの開発では、 Scrum アプローチを採用することをお勧めします。継続的な開発/統合環境の場合、特に同じプロジェクトまたは関連するプロジェクトに取り組んでいる開発者が多い場合は、 Kanban の要素を組み込むことを検討してください。別の効果的なアプローチは、 エクストリームプログラミング の定義されたプラクティスである ペアプログラミング を活用することです。
あなたの状況はほとんど独特ではありません。そして、小さなチームであっても、プロセスは現在の状況を回避するのに役立つ長い道のりを歩むことができます。適切な可視性とかなり手入れされたバックログにより、これらのような質問はスプリント計画の決定となり、技術的負債の管理からの節約になります。
プロジェクトには、成果物の品質チェック手順と使用するツールを制御する標準的なポリシーが必要です。
人々は何をすべきか、そしてこのプロジェクトで使用するために受け入れられているツールを知っているべきです。
これをまだ行っていない場合は、考えを整理して実行します。
コードレビューには、標準アイテムのチェックリストが必要です。 「既に完了している」というメッセージが表示され、それが個人的にはされていない場合、私はこの開発者のプロジェクトマネージャーまたは上級開発者としての仕事に責任を負いたくありません。この態度は容認されてはならない。どうすればよいか、すべてのことを行う方法についての議論は理解できますが、いったん解決策が受け入れられると、嘘は容認されるべきではなく、それは明確に述べられるべきです。
ショップは、いくつかの設計手法を実施する必要があります。
- 要件は明確に定義する必要があります。
- 要件をサポートするユースケースを開発する必要があります。
- ユースケースの実装に必要な関数を指定する必要があります。
- 非機能要件（応答時間、可用性など）を指定する必要があります
- RTM（Requiements Tracabilty Matrix））を使用して、各システム関数をユースケースと実際の要件に戻す必要があります。
- 実際の要件をサポートしていない関数を削除します。
- 最後に、コードレビューで、定義された関数を直接実装またはサポートしていないコードにフラグを立てます。