一貫したコードスタイルの実際の価値は何ですか

私は、顧客向けの新しいソリューションを実装するコンサルタントチームの一員です。クライアント側のコードベース（Reactおよびjavascript）のコードレビューの大部分を担当しています。

一部のチームメンバーが独自のコーディングパターンを使用して、スタイルだけで作者が誰であるかをランダムに選択できるようになっていることに気付きました。

例1（1回限りのインライン関数）

React.createClass({
  render: function () {
    var someFunc = function () {
      ...
      return someValue;
    };
    return <div>{someFunc()}</div>
  }
});

著者は、someFuncに意味のある名前を割り当てることで、コードが読みやすくなると主張しています。関数をインライン化し、代わりにコメントを追加すると、同じ効果が得られると思います。

例2（非バインド関数）

function renderSomePart(props, state) {
    return (
      <div>
        <p>{props.myProp}</p>
        <p>{state.myState}</p>
      </div>
    );
}

React.createClass({
  render: function () {
    return <div>{renderSomePart(this.props, this.state)}</div>;
  }
});

これは通常の方法です（状態と小道具を渡す必要がなくなります）。

React.createClass({
  renderSomePart: function () {
    return (
      <div>
        <p>{this.props.myProp}</p>
        <p>{this.state.myState}</p>
      </div>
    );
  },
  render: function () {
    return <div>{this.renderSomePart()}</div>;
  }
});

これらのコーディングパターンは技術的には正しいものの、コードベースの他の部分や、Facebook（Reactの作者）がチュートリアルや例で示唆しているスタイルやパターンとは一致していません。

時間通りに納品するには速いペースを維持する必要があり、チームに不必要な負担をかけたくありません。同時に、合理的な品質レベルである必要があります。

顧客のメンテナンス開発者がこれらのような矛盾に直面していると自分自身を想像しようとしています（すべてのコンポーネントは同じことをする別の方法を理解する必要があるかもしれません）。

質問：

顧客とその保守開発者が一貫したコードベースを認識し、これらのような不整合を残し、潜在的に拡散することを認める価値は何ですか？

コード転送の利点

Reactあなたの場合、ライブラリが提供するパターンに従うことは、あなたが提供する製品が、Reactに精通している他の開発者によって容易に選択され、保守されることを意味します。

潜在的な後方互換性の問題

一部のライブラリには新しいメジャーバージョンがあり、パターンが大幅に異なると下位互換性が損なわれ、将来のアップグレードが遅くなる/停止する可能性があります。React新しいリリースにどのように対処するかはわかりませんが、これは以前に見たことがあります。

チームの新メンバーが生産性を高めます

著者が提供するものに従うと、フレームワークを使用して才能のある開発者を雇い、新しいパターンを教えるよりも、システムでより早く開始する可能性が高くなります。

潜在的な未発見の問題

将来、あなたのアプローチではまだ発見されていない問題があり、それは著者のアプローチによって解決されるかもしれません。

とはいえ、イノベーションは常にリスクです。あなたのアプローチがより優れていると強く感じ、それがあなたのチームにとって有効であるなら、それを選んでください！

矛盾があると、停止して、なぜ、どこで、どこで考えますか：

• コードの一部を読んで、それがコードの他の部分とは異なるスタイルを使用しているのを見ると、なぜこの特定の部分が違うのか不思議に思うでしょう。特別な理由がありますか？これは危険です。なぜなら、実際にその部分が異なる理由がある場合は、それを認識している必要があるか、またはいくつかの厄介なバグを作成する可能性があるからです。そのコードに触れるようになった元の問題を考えるのではなく、なぜ違うのかを考えるのに時間を浪費し、それを理解することができないので、元の作者に尋ねて時間を浪費し、さらに悪いことに、その過程で、あなたが取り組んでいた問題の精神モデルを失います。

  そのコードに触れたり読んだりする必要があるチーム内の他のすべての開発者と掛け合わせます。

• あなたが複数のスタイルを使用したコードに追加する必要があるときは、停止して決定する必要がありますどのあなたのほかに使用するスタイルを。重要な決定を十分に行う必要があります。重要ではない決定について考える時間を無駄にするのは時間の無駄です。

• スタイルが一貫していると、コードの周りを簡単に移動できます。一貫性があると、どこにあるのかをすばやく見つけることができます。一貫性のないスタイルでは、探しているものがどのスタイルを使用しているかわからないため、greppingでさえ難しくなります。

コードはよく書かれているかもしれませんが、完全に一貫しているわけではないので、気にしないクライアントもいます。物事が悪化し始めたとき、あなたは彼らにあなたに対する別のノックを与えたいですか？複数の開発者プロジェクトに取り組むために会社を雇ったが、彼らがコーディング標準を持っていることを私に示さず、それに従わなかったら、私は懐疑的だろう。

時間通りに納品するには速いペースを維持する必要があり、チームに不必要な負担をかけたくありません。

コーディング標準があまりにも狂っていない限り、誰もが参加するのはそれほど難しくないはずです。入力や書式設定のためではなく、人々がどのコードを書くべきか書かないのかわからないため、プロジェクトは行き詰まります。順守するのに不釣り合いな時間がかかるとき、あなたは遠くまで行ったことを知るでしょう。うまくいけば、これはあなたの最初のロデオではありません。

独自のテストを実施する 必要があるのは、ある開発者から別の開発者に割り当てを切り替えて、他の誰かのファイルを完成させることだけです。彼らは完全に時間をかけてバージョンを再フォーマットしますか？フォローするのは難しいですか？クライアントのメンテナンスチームにとっては悪化します。

私は、自然な英語で書くスタイルを扱うのと同じように、コードスタイルを扱うことができました。日常会話で話す方法を模倣する会話型の英語から、しばしば非常に正確で意味が重く堅苦しいフォーマルな英語まで、さまざまなスタイルがあります。

その意味で、最終製品をどのように見せたいかを検討してください。状況によっては、その時点で最適な構造を使用するのに非常に役立ちます。その他には、一定のリズムと構造が必要です。これは、製品が正式な英語で書かれているかのように最高の場合に特に当てはまります。口語表現はその場合に役立つかもしれませんが、製品の包括的な感覚に涙を流します。

一般に、コーディング標準の一貫性が高いほど、開発者が何か面白いことに注意を向けるのに必要な労力が少なくなります。コーディング標準の多様性をサポートする場合、開発者は、異例のまたはユニークなことをしていることを発表するとき、声を大きくする必要があります。開発者が重要と考えるものを表現しようとするこの試みは、多くの場合、コード自体のダイナミックレンジを覆い隠す可能性があります。これが発生した場合、バグを見逃すのは簡単すぎるため、バグをすり抜けさせるのは簡単です。

その反対に、コーディング標準が緩いほど、開発者は構文を問題に適応させる自由が増えます。プロコーディング標準の議論と皮肉な対照として、標準化が多すぎると、コード構造が堅固になり、バグがすり抜けやすくなります。

あなたが探しているのはあなた自身のチームの幸せな媒体です。

いくつかの他の人が指摘したように、メンテナンス開発者があなたの後ろに行かなければならないとき、異なるスタイルのコードのセクションは彼らを止めさせ、そのセクションの特別なものを見つけようとします。また、一貫性のないスタイルが他のセクションに伝播し、後で混乱するという非常に現実的なリスクがあります。

深く、あなたはすでにこの質問への答えを知っているという印象を受けます。もしこれがなければ、あなたはそれに直面することさえないでしょう。

時間通りに納品するには速いペースを維持する必要があり、チームに不必要な負担をかけたくありません。

これは常に普遍的なトレードオフのようです...それを迅速に行うことと正しく行うこと。顧客の期限の変更に関して、優れたコーディング慣行を犠牲にすることの結果を評価できるのはあなただけです。ただし、JeffOが（おそらく異例の、または直感に反する）コーディングスタイルに従うことでチームの速度が大幅に低下することはなく、期限が大幅に遅れることに気づいたとき、JeffOに同意する必要があります。

この概念については長年知っていますが、最近では「技術的負債。規律あるスタイルに従わない場合、最終的に支払わなければならない技術的負債を考慮する必要があります。

残念ながら、eBusinessが述べたように、顧客が特に技術に精通している場合、または後でコードを自分で保守する場合を除き、一貫したコーディング標準の価値を理解することは困難です。ただし、合理的なビジネスマンであれば、「今すぐ少しの予防保守」（優れたコーディングの形で）「後で大幅な修理コストを回避するのに役立つ」という概念を理解できるはずです（開発者の時間を無駄にした後、混乱）。

ここでのトップ投票の回答は、コードベースのあり方を詳細に説明する、簡単に同意できる理論上のベストプラクティスを繰り返しています。しかし、実際のコードはどういうわけか決してそのようには見えません。その完璧なコードベースを作成しようとすると、ほぼ必然的に失敗します。それは私たちがもっとうまくやろうとするべきではないということではありませんが、現実的に達成可能なものからどれだけ私たちの目標を設定するかには限界があります。

些細なことに集中しすぎると、全体的に最も効率的な方法で仕事を解決する方法など、より重要な問題に集中できなくなるリスクがあります。

最初の例をスタイルとは言いませんが、スタイルは明確な善悪がない選択肢です。この場合、追加の機能はコードの肥大化であり、利点はありません。余分な2行だけで、まだ読みやすく、簡単に修正できるため、この例自体は大きな問題ではありません。

はるかに大きな問題は、複雑なコードの膨張です。ラッパー関数、クラス階層、その他のあらゆる種類の構成要素。周囲のコードが十分に複雑であるため、それらが実際の目的を果たさないことは明らかではありません。コードに明らかな膨張があれば、おそらくもっと多くの非自明の膨張があります。何かをするのははるかに難しく、見つけるのは難しいですが、はるかに大きな問題でもあります。

顧客について

顧客は、ニーズを解決する実用的な製品を入手することに集中する傾向があります。コード品質を心配している数少ない顧客の1人がいたとしても、それは副次的な優先事項になり、コード品質に関する彼らの考えはあなたのものと完全に一致しないかもしれません。顧客企業には独自のプログラマーがいる場合がありますが、それでもあなたが良い仕事をしたかどうかを決定するのは経営陣であり、経営陣はおそらくコード品質の意味すら知らないでしょう。

diffの読みやすさについて非常に重要です。コードスタイルが乱れると、差分はプログラムにとって意味のない変更を隠し、マージを困難または不可能にする可能性があります。