コードの品質と強力な開発者の性格のバランスをとる方法
仕事でのコードレビューで、コードベースの全体的な品質や保守性を必ずしも向上させるわけではありませんが、「賢い」と考えるコードとパターンを見てきました。私はこれを私のフィードバックで指摘し、反論には納得しません。このコードがレポに入り、後で本番環境に移行するとき、私は少し心配です。
私はまとまりのあるチームを維持したいので、自分の予約について声高すぎて緊張を作りたくありません。私はまた、寛大にならずに、お客様にとって素晴らしい製品を作りたいと思っています。
伝統的に、チェックインされるものとその方法に対して「拒否権」を持つのは誰ですか？
コードはどのように機能しますが、複雑すぎる/巧妙なコードをつま先を踏まずに削除できますか？
私はこの引用が大好きです：
「デバッグは、最初にコードを書くよりも2倍困難です。したがって、コードをできるだけ巧妙に書くと、当然、デバッグするほど賢くありません。」 –ブライアンW.カーニハン
一方で、後でデバッグして拡張するのが困難になるため、巧妙なコードにうんざりします。
一方、機能する賢いコードはすばらしいを学ぶ方法です。おそらくチーム全体にとって。作成者に、コードについての簡単な非公式の話を同僚に勧めることはどうでしょうか。本当に意図したとおりに機能し、プロジェクト全体で意味があることを確認してください。あなたはそれを無意味な競争に変えたくありません！
価値があると思わない場合は、「この部分を読みやすくするために、この部分をリファクタリングするにはどうすればよいでしょうか（テストを適切に配置していますか？）」。不可解なナゲットを作成するための巧妙で読みやすいコードを作成することは困難であることを忘れないでください。
私のアドバイスは、コードレビューを行う時間に、それがどのように機能するかについての手掛かりがないと自由に言うときに、ばかをプレイすることです（エゴがマッサージを必要とする場合、それを理解する時間がなかったと言うことができます） ）、開発者に説明してもらいます。彼が終了したら、将来のメンテナンスのためにコメントとしてすべてを書き留めるように提案できます。そのコードは複雑すぎて「良い」コードとは見なされないという暗黙のヒントがあります。
その良いコードが少し複雑すぎる場合、コードの品質や開発者の専門知識について何も言われていなくても、ほとんどの人がヒントを得るでしょう。
PS。明らかに、このコードのほとんどはとにかく主観的であるため、ある人の信じられないほど巧妙なコードは、別の開発者にとっては合理的で、おそらく業界標準のアルゴリズムである可能性があります。そのため、悪いコードを直接書いたと非難することはできませんバイト配列をstlリストにコピーし、それを暗号化ルーチンに渡してから、バイト配列に再び変換した請負業者のように！）
私の経験則では、強力な開発者の性格を支持してコード品質ガイドラインを曲げることです。十分に深く掘る時間がないときはいつもそれを使用します-ちなみに、そのような掘り起こしは、通常かなりの労力を消費します（以下で詳しく説明します）。
このルールは個人的な経験に基づいています。私は（おそらくあらゆる初心者のように）熱狂的にガイドラインに従い、あらゆる逸脱と徹底的に戦うことから始めました。やがて、私は十分なスキルを習得し、比較的簡単にそのような戦いに勝つために十分なトリックを学びました。これにより、私の「勝利」の全体的な影響を学ぶことにさらに集中することができました。そして、私が知る限りでは、影響はかなりマイナスでした-「戦いに負けた」人々は苦しみ、生産性が低下しました-そして、あなたのコードが品質ガイドラインに200％準拠しているという事実はそれを補いませんでした。
この発見により、私は戦闘のほとんどを中止し、その結果、問題のあるケースを分析するためにより多くの時間を費やすことになりました。そして、私が深く掘るとき、通常は背後に興味深い設計問題があり、単に隠れているだけの微妙な（または微妙ではない）問題があることがわかりました人格の戦いの背後に。
- たとえば、31Kのソースファイルが推奨サイズの上限である30Kを超えていることがわかります。私のオプションは、ファイル所有者に何キロか余分なキロバイトを強制的に圧迫させるために数分/時間の戦いを費やすことですまたは 1日か2日考え、掘り下げて、たとえば、いくつかのライブラリAPIがあることを見つけるために費やすそのファイル内のすべてのコードの代わりに使用できます（そのため、コードを削除できます）。
このような発見は、エンドユーザーの観点からはあまり役に立たない場合がありますが（実際にそれが実際に深い影響を与える可能性があります）、そのようなナットをクラックするときに私が得る楽しさを認めなければならないので、とにかく努力する価値があります...ケーキのガイドラインの偏見への着氷も、戦いなしで消えます。 :)
組織には、開発チームからの入力で定期的に更新されるコーディングのガイドライン/標準のドキュメントが必要です。このドキュメントでは、変数の命名方法、コードのフォーマット方法など、詳細を詳しく説明できます。このドキュメントでは、読みやすさ、保守性、正確性、効率性、標準への準拠などの相対的な重要性を含め、プログラマーがコードの記述に採用することを組織が期待する価値についても説明する必要があります。
コードレビューは、そのコーディング標準文書を使用して実施する必要があります。 2つが矛盾している場合、プログラマーが簡潔さよりも読みやすさを優先するべきであるとコーディング標準で述べられている場合は、「賢い」コードに対して議論する際にある程度のサポートが得られます。標準がそれを言わないで、あなたがそうすべきだと思うなら、誰かの自我が線上にあるときにそれを理解しようとするのではなく、コーディング標準会議でそれについて抽象的に議論することができます。
最終的に、それは時々裁判の呼び出しに帰着し、そのような場合、最終的なWordは、コードや製品の最終的な責任者に行くべきです。これは通常、上級開発者、テクニカルリード、プロジェクトマネージャー、エンジニアリングディレクターなどです。あなたが責任者であり、特定のコードが十分に保守可能ではないと感じた場合、そう言うことを恐れるべきではありません。あなたはそれについて外交的であることができます：
サム、あなたの創意工夫には感心しましたが、ちょっと賢すぎるかもしれません。これを維持するのではなく、今から1年後に新しい開発に取り組む必要があります。それを維持しなければならない人がその素晴らしさを完全に理解していないのではないかと心配しています。私はあなたがそれをするのが嫌いであることを知っていますが、私たちが議論した簡単な実装に戻ってくれれば幸いです。
一方、担当者でない場合は、自分の立場を明確に説明し、チームの他のメンバーを説得することをお勧めします。マネージャーからサポートを受けられない場合は、それがあなたの電話ではないことを受け入れ、次に進みます。
あなたの場所で（そして、私は時々、それらのsmartassesの1人です）私はそれを削除しませんが、機知に富んだ/賢い作者に個人的に尋ねますそれを非常によく文書化するコメント内、および可能であれば、彼が使用できたであろう代替的で単純な記述に関するいくつかの議論を例とともに含める。
私はこれが最善であることを強調しますおそらく彼もおそらく覚えていないのでこれらの行には、2か月の間にすべてのビットとボブがあります。
例として、彼が書くように強いられたらすぐに、彼はおそらく最も単純なものを支持してスマートコードを落とすでしょう。
なぜそれはうまくいくでしょう。
- あなたはあなたを認めました彼が書いたものに注意してください、
- あなたは彼にrespectをaskingで示しました、
- メモリ/焦点の問題を引用することで、コードを変更する必要があり、変更できないシナリオを考案して彼に分類します彼がまだ会社またはチームで働いている間
（最後の言及がなければ、この種の要求はプログラマーを商品化して交換可能他のコードモンキーといつでも）
私の経験では、コードベースからすべての要件を満たす十分なコードを取得することは通常非常に困難です。
ただし、次にコードを保守するときは、古いコードの保守が困難だったため、将来のコスト削減策としてコードの置き換えを容易に主張できます。
拒否権に関する限り、経営陣は明らかにそれを持っています。
コードの品質を担当するチームまたは委員会である場合もあります。その場合、彼らはこの力も持っています。
また、「賢い」パターンの例を示すと役立ちます。多分あなたはただ過剰反応している...
私の本では「賢い」ということは決して悪いことではありませんが、巧妙なものと複雑なものの間に滑りやすい斜面がある可能性があることに同意できます。
私は長年、開発チームの指導と管理に費やしてきました。本質的に、私はコードの点ではOCDであり、非常に白黒です。私は経験を通して、あなたの戦いを選ぶことはチームのリーダーとして学ぶのが最も難しいスキルの1つであることを学びました。はい、基準は重要です。はい、可読性と保守性は非常に重要です。はい、私たちは全員、統一された標準に準拠したコードを書くように努めるべきです。開発者は人間ですが...コード生成ツールではありません。性格や意見があり、飽きて、新しいことを学びたいです。
仕事でのコードレビューで、コードベースの全体的な品質や保守性を必ずしも向上させるわけではないが、「賢い」と考えるコードとパターンを見てきました。
OK ...追加しないので、損ないますか？コーディングスタイルの個人的な好みの問題だけを話しているのか、それともコードが完全に不要であるのか（たとえば、式ツリーとリフレクションを使用するのが楽しいからといって、式ツリーとリフレクションを使用する）前者なら行かせて。開発者であることの楽しさの1つは、問題の創造的な解決策を考え出すことです。たぶん（そして私たちの多くはこれを認めたくない）、私たちは時々私たちが理解していないアプローチに怯え、新しいアプローチを学ぶために質問したくないか、追加のエネルギーを持っていないのです。
さて、創造性が不要なコードと完全に正当化できない複雑さにつながるときは、必ず声に出して主張してください。チームプレーヤーであることは重要ですが、責任を負うこと（そして他の人を保持すること）も重要です。コードレビューは、説明責任と同様に品質保証と学習についてです。あなたはいくつかのつま先を踏むつもりですが、なぜ努力（お金）が作業コードの書き直しに費やされ、その過程でエゴが打たれるべきであり、そして誰かの技術への熱意を押しつぶす危険を冒したいという強い議論があると感じた場合、それからあなたはそれをテーブルの上に置くことをためらうべきではありません。あなたがチームのリーダーなら、これがあなたの仕事です。影響に注意して、実行します。チームリーダーではなく、権限がない場合は、チームに委ねて決定します。
チームに説明責任を浸透させる最良の方法は、他の人にあなたに説明責任を持たせることです。あなたがオープンマインドを保ち、彼らがあなたのコードの改善を提案するときに人々をシャットダウンしないなら、あなたは彼らがあなたの提案をより受け入れやすくなるかもしれません。
個人的な経験から、これが起こったとき、私はボランティアになる許可を求めます敵対的なユニットテスターテストを書いてなじみのない実装を拷問します。
私は、コードがどのように機能するかを真に理解するために非常に一生懸命努力し、また、多くの異なる方法でそれを調査するように努めます。
これは時間のコミットメントであることに注意してください。それは数時間、または数十時間、あるいは週のかなりの部分であるかもしれません。それが正当化されるかどうかは、コードの複雑さが要件の複雑さに釣り合っているかどうかに依存します。
私が勝っていなかった場合、つまりコードが多くのテストに耐えた場合、実装が私よりも本当に賢明であり、メイン製品への組み込みをサポートすることを私は確信します。
ソース管理方法によっては、このテストフェーズを開始する前に、コードをソース管理システム（おそらくブランチ内）に暫定的にコミットする必要がある場合があります。
私の答えは、OpenCVの使用経験によって色分けされています。プログラマーが自分で実装できるアルゴリズムよりも高度なアルゴリズムがあります。博士号さえも-おそらく博士号の上位数パーセント。コードがである良い場合、それを定量化する有効な手段がない場合でも、自分の本能や偏見に反して行動する必要があります。信頼のレベル。
他の多くのプラクティスと同様に、私は答えはそれは場合によりますだと思います。
- それが欠陥であるならば、それは間違いなく修正される必要があります。
- コードが機能する場合は、コードの変更を主張することの価値と、賢いコードの将来のコストとのバランスをとる必要があります。開発作業とメンテナンス作業の比率に関する経験則はありますが、プロジェクトごとに大きく異なります。合理的である。
- コードを簡略化する必要があることをチームメイトに納得させることができない理由を考えてみてください。
- 常にすべてを完璧にする必要はありません。つまり、コードは無限ループでレビューされ、何もチェックインされていないことになります。
- 私の個人的な好みは、コードの作成者が最終的な発言権を持つことです。明らかに非常に貧しい仕事を続けている場合は、他のアクションを実行する必要がありますが、非常にまれな状況である場合、開発者にコードの変更を強制することの負の値は、修正によって得られる利益よりも高くなる可能性があります。 。
私は間違いなくこの質問に関連することができます。現在、私は2つのチームのテクニカルリードを務めています。私が作成するコードを可能な限り読みやすく保守しやすいものにすることは、私の仕事です。同時に、私はいくつかの「賢い」コードを生成することが知られており、私のチームメイトのほとんどはそれに従うのが非常に難しいでしょう。
私が提供できる観察はほとんどありません：
あなたのチームには、意見の相違がある場合に最終的な決定を下す1人のリードが必要です。前回のリリースでは、私はリーダーシップのないチームに所属していましたが、それはひどいものでした。すべてが議論になりました、そしてあなたが強い個性を持つ少数の人々を持っているならば、彼らのどちらもびくともしません。あなたがリードを持っている場合、どの決定が選択されたかに関係なく、チームの全員はリードが言うことが行くことを理解しなければなりません。それが経営陣が彼をリードした理由です。
人々を幸せに保つことは非常に重要です。したがって、チーム全体を自分の視点に向けるのではなく、そこにナッジするだけです。 SOLIDの原則を説明し、小さくてまとまりのあるクラス/メソッド/インターフェースの重要性を説明し、違反が見られるたびに（つまり、コードレビューで）これらのことを繰り返します。同時に、好きではないすべてのものを書き直させます。結局のところ、個人的な表現とグループの標準に従うことのバランスが必要です。個人的な好みがグループの一般的な方向にシフトするにつれて、2つは収束するでしょう。オペレーティング。
「巧妙な」コードを作成することよりも、クリーンで理解しやすいクラスインターフェイスを作成することの方がはるかに重要だと思います。たとえば、3つの異なる方法で検索されるエントリのリストを保持するクラスがあります。現在、小規模で機能するすべてのルックアップに線形検索を使用しているだけですが、このクラスは非常に低いレベルであるため、十分にスケーリングされないことがわかります。 Boost Intrusiveコンテナーを使用する別のクラスに置き換えようとしています。各要素は各インデックスに同時に配置されることをサポートし、すべての検索はO（sqrt（N））で行われます。はい、それは内部でははるかに複雑になり、多くの人々はBoostを好きではありませんが、外部では3つのメソッドのままです：追加、削除、取得。要するに、人々は（理由の範囲内で）好きなコードを書くことができるということですが、インターフェースは賢くしてはいけません。
コードの所有権の概念を維持します。別の人がいくつかのコードを追加/変更する必要があるかもしれないので、達成するのは時々難しいですが。コードが記述されるとき、元の開発者はそのコードの最終的な管理者です。それは他の誰もそれに触れることができないという意味ではありません。他の人が自分のコードを変更した場合は問題ありませんが、結局のところ、元の開発者がコードをレビューし、そこで行われたすべてのことについて責任を負います。そのコードが単純であろうと巧妙であろうと、それは彼の赤ちゃんです。もしあなたが予測しているように、あなたが予測しているように、行われた設計/コーディングの決定のためにバグが山積みになり始めたら、単にそれらのバグが入ってくるときにそれらを修正するのではなく、その開発者に座ってください（誰もがそれらすべてのバグを修正するはずです）それらの決定を振り返って、彼らがどのように異なる方法で行われていたかを確認します。次に、リファクタリングに関する本を彼に渡し、その一部をどのように「無力化」することができるかを見てください。