コード品質と強力な開発者パーソナリティのバランスを取る方法

作業中のコードレビューでは、コードベースの全体的な品質や保守性を必ずしも向上させるわけではありませんが、「賢い」と考えるコードとパターンを見てきました。私はフィードバックでこれを指摘し、反論に納得しません。このコードがレポジトリになり、後にプロダクションに移行するとき、私は少し心配です。

私は団結力のあるチームを維持したいので、自分の留保について口論しすぎて緊張を引き起こしたくありません。私はまた、あまりにも寛大にならずに、お客様に素晴らしい製品を作りたいです。

伝統的に、誰がどのようにチェックインされ、どのように「ベト」パワーを持っていますか？

コードはどのように機能しますが、つま先を踏まずに複雑すぎる/巧妙なコードを削除できますか？

私はこの引用が大好きです：

「デバッグは、最初にコードを書くよりも2倍難しくなります。したがって、コードをできる限り巧みに書くと、定義上、デバッグするのに十分ではありません。」–ブライアンW.カーニハン

一方では、後でデバッグして拡張するのが難しいため、これはあまりにも賢いコードにうんざりさせます。

一方、動作する賢いコードは、学ぶための素晴らしい方法です。おそらくチーム全体のために。コードについて同僚にちょっとした非公式の話をするように作者に勧めるのはどうですか？本当に意図したとおりに機能し、プロジェクト全体で意味があることを確認してください。あなたはそれを無意味な競争に変えたくない！

付加価値があると思わない場合は、「読みやすくするために、この部分をリファクタリングする（テストを実施しているのですか？）」という反論を投げかけます。不可解なナゲットを作成するための巧妙で読みやすいコードを作成するのは難しいことを必ず指摘してください。

私のアドバイスは、コードのレビューを行う時間は、あなたがそれがどのように機能するのか手掛かりを持っていないと気軽に言うときです（あなたのエゴがマッサージを必要とするなら、あなたはそれを理解する時間がなかったと言うことができます） ）そして開発者に説明してもらいます。彼が終わったら、将来の保守のためにコメントとしてそれをすべて書き留めることを提案することができます。

優れたコードが少し複雑すぎる場合、ほとんどの人はヒントを得ます。コードの品質や開発者の専門知識については何も言われていません。

PS。明らかに、このコードの大部分は主観的であるため、ある人の信じられないほど巧妙なコードは、別の開発者にとって合理的であり、業界標準のアルゴリズムである可能性があります。バイト配列をstlリストにコピーし、暗号化ルーチンに渡し、それをバイト配列に変換し直した請負業者のように！）

私の経験則では、強力な開発者の個性を優先してコード品質ガイドラインを曲げることです。十分に深く掘る時間がないときはいつもそれを使用します-ちなみに、そのような掘りは通常かなりの労力を消費します（以下で詳しく説明します）。

このルールは個人的な経験に基づいています。私は（おそらく新人として）ガイドラインに夢中になって、あらゆる逸脱と徹底的に戦うことから始めました。やがて、私は十分なスキルを身につけ、比較的簡単にそのような戦いに勝つために十分なトリックを学びました。それにより、私の「勝利」の全体的な影響を学ぶことに集中することができました。そして、私が知る限り、その影響はかなりマイナスでした-「戦いに負けた」人は苦しみ、生産性が低下しました-そして、あなたのコードが品質ガイドラインに200％準拠しているという事実はそれを補償しませんでした。

この発見により、私はほとんどの戦闘をやめさせ、問題のあるケースを分析する時間を増やすことになりました。そして、私が十分に深く掘り下げると、通常、背後に興味深いデザインの問題、人格の戦いの後ろに隠れている微妙な（またはあまり微妙ではない）問題があることがわかりました。

• たとえば、31Kのソースファイルが推奨サイズの制限である30Kを超えていることがわかります。私のオプションは何とか外には、余分なキロバイトを圧迫する力ファイルの所有者に戦って数分/時間を過ごすためにどちらかであるか、一日か二日の思考を過ごすためにして、それを見つけるために掘り、たとえば、すべての代わりに使用することができ、いくつかのライブラリのAPIがありますそのファイル内のコード（削除することができるように）。

このような発見は、エンドユーザーの観点からはあまり役に立たない場合もありますが（実際には深い影響を与える場合があります）、そのようなナットをクラックすることで得られる楽しみを認めなければなりません...ケーキのガイドラインの逸脱に関するアイシングも、戦いなしで消えます。:)

組織には、開発チームからの入力で定期的に更新されるコーディングガイドライン/標準ドキュメントが必要です。そのドキュメントでは、変数の命名方法、コードのフォーマット方法などの詳細を説明できます。また、このドキュメントでは、読みやすさ、保守性、正確性、効率性、標準の順守などの相対的な重要性など、プログラマーがコードの作成に採用することを組織が期待する値について説明する必要があります。

コードレビューは、そのコーディング標準文書を使用して実施する必要があります。コーディング標準で、プログラマが簡潔さよりも読みやすさを優先すべきだと言っている場合、「賢い」コードに反論する際のサポートが得られます。標準がそれを言わず、そうすべきだと思うなら、誰かの自我が動いているときにそれを理解しようとするのではなく、コーディング標準会議の要約で議論することができます。

最終的に、それは時々判断の呼び出しになります、そして、そのような場合、最終的な言葉はコードや製品に対して最終的に責任がある人に行くべきです。それは通常、シニア開発者、テクニカルリード、プロジェクトマネージャー、またはエンジニアリングディレクターのような人です。あなたが担当者であり、特定のコードが十分に保守可能でないと感じている場合、そう言うことを恐れてはいけません。あなたはそれについて外交することができます：

サム、ここであなたの創意工夫に感銘を受けましたが、ちょっと賢すぎるかもしれません。これを維持するのではなく、今から1年後に新しい開発に取り組む必要があります。それを維持しなければならない人は、そのすばらしさを完全に理解できないかもしれません。私はあなたがそれをするのが嫌いだと知っていますが、私たちが議論した簡単な実装に戻っていただければ幸いです。

一方、あなたが担当者でない場合は、自分の立場を明確に説明し、チームの他のメンバーを納得させることが最善です。マネージャーからサポートを受けていない場合は、それが電話ではないことを受け入れ、先に進みます。

あなたの場所で（そして私は時々それらのスマートなものの1つです）私はそれを削除しませんが、気の利いた/賢い著者に個人的にコメントでそれを非常によく文書化し、可能であれば、代替案と例を使用して、彼が使用することができたより単純な文章。

私はこれが最善であることを強調したいと思います。なぜなら、彼でさえ、2か月後にはそれらの行にあるすべてのビットとボブを覚えていないだろうからです。

例として、彼はおそらくそれを書くことを余儀なくされるとすぐに、最も単純なものを支持してスマートコードを落とすでしょう。

なぜそれが機能するのでしょうか。

• あなたは彼が書いていることに関心があることを認めた、
• あなたは彼が示した尊敬によって求め、
• 記憶/焦点の問題を引用して、あなたが考案し、そのコードを変更する必要があり、彼がまだ会社またはチームで働いている間は変更できないシナリオを彼に分類します

（最後の暗示がなければ、この種の要求は、会社の側で、プログラマーを共有化するための試行として受け取られ、いつでも他のコードモンキーと交換可能になります）

私の経験では、すべての要件を満たすコードをコードベースから取得することは通常非常に困難です。

ただし、次回コードを保守するときは、古いコードの保守が困難だったため、将来のコスト削減策としてコードの置き換えを簡単に主張できます。

拒否権に関する限り、経営陣は明らかにそれを持っています。
コードの品質を担当するチームまたは委員会である場合もありますが、その場合も同様にこの権限があります。

また、「巧妙な」パターンの例を挙げると便利です。たぶん、あなたはただ過剰反応している...

私の本では「賢い」というのは決して悪いことではありませんが、賢いと複雑なものの間には滑りやすい斜面があることに同意することができます。

他の多くの慣行と同様に、答えはそれに依存すると思います。

• それが欠陥であれば、間違いなく修正する必要があります。
• コードが機能する場合、コードを変更することを主張する価値と、賢いコードの将来のコストのバランスを取る必要があります。開発作業と保守作業の比率に関する経験則がありますが、プロジェクトごとに大きく異なります。合理的であること。
• コードを簡素化する必要があることをチームメイトに納得させることができないのはなぜですか？
• 常にすべてを完璧にする必要はありません。それは無限ループでのコードレビューを意味し、何も完璧ではないのでチェックインされません。
• 私の個人的な好みは、コードの作者が最終決定権を持つことです。明らかに彼らが非常に貧しい仕事を続けている場合、他のアクションをとる必要がありますが、あなたが言うように、開発者にコードを変更させることの負の値は、これが非常にまれな状況である場合、それを修正することによって得られるゲインよりも高い場合があります。

私は間違いなくこの質問に関係することができます。現在、私は2つのチームのテクニカルリードを務めており、生成するコードができるだけ読みやすく、保守しやすいようにすることが私の仕事です。同時に、「巧妙な」コードを生成することも知られており、ほとんどのチームメイトがそれに従うのに苦労することを知っています。

私が提供できる観察はほとんどありません：

1. あなたのチームには、意見の相違がある場合に最終決定を下すリードが1人必要です。前回のリリースでは、私はリーダーシップのないチームに所属していましたが、それは極悪でした。すべてが議論になりました。強い個性を持つ人がほとんどいない場合、どちらも動きません。あなたがリードを持っている場合、どの決定が選択されたかに関係なく、チームの全員がリードが言うことを理解する必要があります。それが経営陣が彼をリードした理由です。

2. 人を幸せにすることはとても重要です。したがって、チーム全体をあなたの視点に向けるのではなく、ただそこに微調整してください。固い原則を説明し、小さくてまとまりのあるクラス/メソッド/インターフェースの重要性を説明し、それらが違反されているのを見るたびに（つまりコードレビューで）これらのことを繰り返します。同時に、好きではないものをすべて書き直さないでください。一日の終わりには、個人的な表現とグループの標準に従うことのバランスが必要です。個人的な好みがグループ全体の運営方法にシフトするにつれて、この2つが収束することを願っています。

3. 私は、「賢い」コードを持たないことよりも、クリーンでわかりやすいクラスインターフェースを持つことがはるかに重要だと思います。たとえば、3つの異なる方法で検索されるエントリのリストを保持するクラスがあります。現在、すべてのルックアップに小規模なスケールで機能する線形検索を使用していますが、このクラスは非常に低レベルであるため、あまりうまくスケールしていません。Boost Intrusiveコンテナを使用する別のクラスに置き換えようとしています。各要素は、各インデックスへの同時配置をサポートし、すべてのルックアップはO（sqrt（N））で実行されます。はい、それは内部でははるかに複雑になり、多くの人はBoostを嫌いますが、外部ではAdd、Remove、Getの3つのメソッドが残ります。一番下の行は、人々が（理由の範囲内で）好きなコードを書くことができるということです、

4. コード所有権の考え方を維持します。別の人がいくつかのコードを追加/変更する必要があるかもしれないので、それを達成することは時々困難ですが。コードが記述されると、元の開発者がそのコードの究極の管理者になります。それは他の誰もそれに触れることができないという意味ではありません。他の人がコードを変更する場合、それは問題ありませんが、結局のところ、元の開発者はそれをレビューし、そこにあるものについて責任を負います。そのコードがシンプルであろうと巧妙であろうと、それは彼の赤ちゃんです。あなたが予測しているように、設計/コーディングの決定のためにバグが山積みし始めた場合、それらのバグを単に修正するのではなく、その開発者と一緒に座ってください（誰がそれらのバグをすべて修正すべきか）そして、それらの決定を熟考して、それらがどのように異なる方法で作成されたのかを確認します。

私は長年にわたって開発チームを率い、管理してきました。本質的に、私はコードと非常に白黒の点で少しOCDです。経験から、あなたの戦いを選ぶことは、チームリーダーとして学ぶのが最も難しいスキルの1つであることを学びました。はい、標準は重要です。はい、読みやすさと保守性は非常に重要です。はい、私たちは皆、統一された標準に準拠したコードを書くよう努力すべきです。ただし、開発者は人間です...コード生成ツールではありません。私たちには個性や意見があり、退屈していて、新しいことを学びたいと思っています。

作業中のコードレビューでは、コードベースの全体的な品質や保守性を必ずしも向上させるわけではありませんが、「賢い」と考えるコードとパターンを見てきました。

OK ...彼らは追加しませんが、彼らは損ねますか？私たちはコーディングスタイルの個人的な好みの問題だけを話しているのですか、それともコードは完全に不必要に書かれているのですか（例えば、式ツリーとリフレクションを使用するのが楽しいからといって式ツリーとリフレクションを使用する）？前者の場合は、手放します。開発者であることの楽しみの一部は、問題に対する創造的な解決策を考え出すことです。たぶん（そして私たちのほとんどはこれを認めたくない）、私たちは理解していないアプローチに怖がって感じることがあり、尋ねたくないか、新しいアプローチを学ぶための追加のエネルギーを持っていません。

今、創造性が不必要なコードと完全に不当な複雑さをもたらすとき、すべての手段で声を出して主張します。チームプレーヤーになることは重要ですが、その責任（および他者を保持すること）も重要です。コードレビューは、品質保証と学習と同様に説明責任についてのものです。あなたはつま先を踏むつもりですが、なぜ努力（お金）が作業コードの書き換えに費やされるべきであり、プロセスで自我が傷つけられるべきであり、あなたが彼らの技術に対する誰かの熱意をつぶす危険性があるという強い議論があると感じる場合、テーブルの上に置くことを恥ずかしがらないでください。あなたがチームリーダーなら、これがあなたの仕事です。影響に注意し、実行してください。あなたがチームリーダーではなく、権限を持っていない場合は、チームに任せて決定してください。

チームに説明責任を浸透させるための最良の方法は、他の人に説明責任を持たせることです。心を開いたままにして、コードの改善を提案したときに人々を締め出さないでください。彼らはあなたの提案を受け入れてくれるかもしれません。

個人的な経験から、これが起こったら、慣れない実装を苦しめるためにテストを書くボランティアの敵対的なユニットテスターになる許可を求めます。

コードがどのように機能するかを真に理解するために一生懸命努力し、また多くの異なる方法でコードをプローブしようとします。

これは時間的なコミットメントであることに注意してください。それは数時間、あるいは数十時間、あるいは一週間の大部分です。正当化されるかどうかは、コードの複雑さが要件の複雑さに見合っているかどうかによって決まります。

私が勝てなかった場合、つまりコードが多くのテストに耐えた場合、実装は私よりも本当に啓発されていると確信し、メイン製品への組み込みをサポートします。

ソース管理の方法によっては、このテストフェーズを開始する前に、ソース管理システムにコードを暫定的に（おそらくブランチで）コミットする必要がある場合があります。

私の答えは、OpenCVの使用経験によって色付けされています。プログラマーが自分で実装できるよりもはるかに洗練されたアルゴリズムがあります。博士号でもない-おそらく博士号の上位数パーセント。コードがこれほど優れている場合、その信頼レベルを定量化する効果的な手段がなくても、自分の本能と偏見に反して行動することを信頼する必要があります。