チームのスキルが低い場合、コードのスキルを下げる必要がありますか？[閉まっている]

たとえば、JSにはデフォルト値を取得するための一般的なスニペットがあります。

function f(x) {
    x = x || 'default_value';
}

この種のスニペットは、私のチームのすべてのメンバーが簡単に理解することはできず、JSレベルは低いです。

このトリックを使用しないほうがいいですか？JS開発者によると、コードはピアでは読みにくくなりますが、次のコードより読みやすくなります。

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

確かに、このトリックを使用して同僚がそれを見ると、彼らは何かを学ぶことができます。しかし、多くの場合、彼らはこれを「賢くしようとしている」と見なしています。

チームメイトのレベルが私より低い場合、コードのレベルを下げる必要がありますか？

さて、ここでこの大きくて複雑なトピックに関する私の見解を示します。

コーディングスタイルを維持するための長所：

• x = x || 10JavaScript開発では慣用的なもの が使用され、コードと使用する外部リソースのコードとの間の一貫性を実現します。
• 多くの場合、コードのレベルが高いほど表現力が豊かになり、何が得られるかがわかり、高度な訓練を受けた専門家の間で読みやすくなります。
• あなたは仕事をもっと楽しむでしょう。個人的には、きれいなコードを作成することを大切にしています。それは私の仕事に多くの満足をもたらすと思います。
• 一般的に、読みやすいスタイルを作成します。言語のイディオムに固執することは非常に貴重なことができます-彼らはしばしば理由のためのイディオムです。

コーディングスタイルを維持するための短所：

• 下位レベルのプログラマーが追いつくのは難しくなります。多くの場合、これらはあなたのコードを保守している人々と、あなたが書いたものを実際に読まなければならない人々です。
• コードのメンテナー、多くの場合JavaScriptコードは他の言語のものです。プログラマーはJavaまたはC＃に精通しているかもしれませんが、JavaScriptがいつどのように正確に異なるかを理解していません。これらの点はしばしば慣用的です- 即時に呼び出される関数式（IIFE）はそのような構造の例です。

私の個人的な意見

コードのスキルを下げるべきではありません。表現力豊かで、明確で簡潔なコードを書くことを目指してください。チームのレベルに疑問がある場合は、教育してください。人々はあなたが思うよりも学ぶことをいとわず、彼らがより良いと確信したとき、新しい構造を適応させようとします。

彼らがあなたが「ただ賢い」と思うなら、あなたの主張を主張してみてください。あなたが時々間違っていることを認めて喜んで、そして、どんなに関係なく、あなたの作業環境全体でスタイルの一貫性を保つようにしてください。そうすることは敵意を避けるのに役立ちます。

最も重要なことは、一貫性を保つことです。

チームのコードは、1人がコーディングしたように作成する必要があります。コーディングガイドラインに絶対に同意する必要があります。これらのガイドラインに従う必要があります。コーディングガイドラインで、オプションパラメータの読み取りを「あまり賢くない」方法で行うように指定されている場合、それがその方法です。

まあコメント

コードのスキルを下げるべきですか？必ずしもそうではありませんが、コメントのスキルを確実に高める必要があります。特により複雑だと思われるセクションの周りには、コードに適切なコメントを含めるようにしてください。コードを理解するのが難しくなるほど多くのコメントを使用しないでください。ただし、各セクションの目的を明確にしてください。

現実には、コメントを少し冗長にすることは、スキルの低いチームメンバーには役立ちますが、特にスキルが多すぎる場合は無視してください。

スタイルの問題？

あなたが提供した例はやや基本的ですが、むしろ文体的です。すべての変数のデフォルトに関するコメントは、維持および読み取りが面倒です。代わりに、スタイルとして、または繰り返されるショートカットまたはコードパターンをおそらく標準として確立する必要があります。そのような形式のパラメータのデフォルト設定をすべての人が理解し、毎回使用する必要があると思われる場合は、これらのアイデアを書き留めてチームリーダーに伝えてください。チームメイトに教えるために必要なことは、提案した基準について話し合う簡単な会議だけです。

別の答えがすでに述べたように、一貫性を保ちます。

男に魚を教える...

チームメイトを教えることは、おそらく関係者全員を助けることができる最良の方法です。コミットログまたはタイムスタンプに自分の名前が記載されたコードについて質問がある場合は、気軽に質問してください。チームにコードレビューがある場合、これは、混乱を招く可能性のある（ヘム）十分にコメントされたコードをチームメイトに説明する絶好の機会です。チームにコードレビューがない場合は、なぜですか？それに着く！

ただし、注意する必要があります。あなたはいつも人々に教えるためにいつもそばにいるとは限らないかもしれませんし、あなたがコードの与えられたセクションで元々やろうとしていたことを忘れさえするかもしれません。

「賢い」トリック

チームメイトの能力を念頭に置くことは間違いなく重要ですが、保守可能なコードを書くことは、より一般的な解決策があるかもしれない問題への不可解なショートカットを使用しないことを意味することがよくあります。これは、チームメイトが知的であっても重要です。コードを把握するのに時間がかかりすぎたり、見落としがちな微妙ではあるが重要な副作用が発生したりすることは望ましくありません。一般に、適切な代替手段がある場合は、「賢い」トリックを避けるのが最善です。誰がコードを後から保守しなければならないかわからない-多くの場合、私たちの古いバージョンはこれらのトリックの詳細や理由を覚えていないでしょう。

巧妙なトリックを実装する必要があることがわかったら、少なくとも次のアドバイスに従ってください...

キッス

疑わしい場合は、シンプルにしてください。コードがシンプルであるかどうかは、あなたが思うように必ずしもプログラマーのスキルに対応するとは限りません。実際、問題に対する最も素晴らしい解決策のいくつかは最も単純なものであり、より複雑な解決策のいくつかは最終的にTheDailyWTFになります。コードをシンプルかつ簡潔に保つことで、よりインテリジェントであるが直感に反する決定を理解しやすくすることができます。

JSで関数を作成することには大きな嫌悪感があるようです。この嫌悪感により、人々は賢くなり、関数呼び出しのように物を一行に保つためにとんでもないトリックを使用しようとします。もちろん、呼び出しの関数名は追加のドキュメントとしても機能します。トリッキーな表現にコメントを付けることはできません。コメントを付けると意味が失われ、「jsイディオム」と呼ばれ、突然理解できるようになります。

Javascriptは非常にアクセスしやすく、ほとんどの人は私たちのように朝食の仕様を食べません。そのため、彼らはイディオムの隠れた仮定とエッジケースが何であるかを決して理解しません。

x = x || 'default_value';

平均的なジョーは、これを理解していないか、デフォルト値のイディオムであると記憶しています。どちらも有害です。実際、後者はさらに有害です。彼はここで仮定とエッジケースを理解しません。彼は仕様を読み、それを理解することを気にしません。

私はそのコードを見たとき、私はそれがだ場合」を参照してください。nullまたはundefined、このデフォルト値に設定します。それはまた、暗黙的に扱いますが+0、-0、NaN、false、および""適切な値をとしてではない。私は今から3ヶ月時にそのニーズを覚えておく必要があります変更します。おそらく忘れてしまいます。」

暗黙の仮定は将来的にバグを引き起こす可能性が非常に高く、コードベースがこのようなトリックでいっぱいになっている場合、変更がどのような影響を与えるかを考えるときはいつでもそれらをすべて頭の中に保持する可能性はありません。そして、これは「JS pro」のためです。たとえ要件が最初から偽の値を受け入れることであったとしても、平均的なジョーはバグを書いていたでしょう。

新しいスニペットには、より使い慣れた構文がありますが、上記の問題がまだあります。

あなたが行くことができます：

function f(x) {
    x = valueOrDefault(x, "default_value");
}

これで、エッジケースを処理するための非常に複雑なロジックを持つことができ、クライアントコードは依然として美しく見やすくなります。

さて、関数を引数として渡すなどの高度な言語機能と、次のような巧妙なトリックをどのように区別します|| "default"か？

巧妙なトリックは、コードが最初に作成されたときに無視できる隠された仮定の下で常に動作しています。要件が変更されたため、IIFEを別のものに変更する必要はありません。それは常に存在します。たぶん、実際のモジュールを使用できる2020年ですが、そうです。

| 0または、~~numフローリングに使用されるカーゴカルトバージョンは、正の32ビット符号付き整数境界を想定しています。

|| "default" すべての偽の値が引数をまったく渡さないことと同じであると仮定します。

等々。

プログラミングスキルを下げるべきではありませんが、コードの記述方法を調整する必要があるかもしれません。何よりも目標は、コードを読んで保守する必要のある人々にコードを明確にすることです。

残念ながら、特定のスタイルが「賢い」のか、それとも高度な使用法なのかを判断するのは少し難しいかもしれません。質問のコードはこれの良い例です-あなたの解決策は必ずしも他のものより良いとは限りません。一部の人はそうだと主張し、一部の人は同意しないだろう。両方のソリューションの実行時パフォーマンスは事実上同等であるため（読み取り：ユーザーは違いを知ることはありません）、チーム全体として最も快適なスタイルを選択してください。

場合によっては、より良いコーディング方法を教える必要がありますが、明確にするために妥協する必要がある場合もあります。

これはすでに別の答えで言われているかもしれませんが、私はこの質問に自分の命令に答えたいです。

一般的なガイドライン

チームで作業するとき、あなたはコードの対象読者ではありません。あなたの聴衆はあなたのチームの開発者です。正当な理由がなければ理解できないコードを書かないでください。

1. 特定の欠点がない限り、すべてのコードは、それを保守する開発者が簡単に保守できる特定のパターンまたはガイドラインに従って作成する必要があります。（注意：現在コードベースにあるという理由だけで悪いパターンに従うのはひどい習慣です。）
2. ターゲットオーディエンスが簡単に読み取れない言語固有のイディオムを使用する正当な理由を見つけることができる場合は、コメントを追加します。他のすべての行にコメントを追加する必要がある場合は、コードを書き直して、視聴者が読みやすいようにすることができます。慣用的であるために慣用的であることは価値があるとは思いません。

具体例

コードベースには多数のperlスクリプトがあります。通常、perlは非常に単純な操作にのみ使用され、コードの大部分はJava開発者によって記述されているため、Javaによく似たスタイルになっています。perlスクリプトのセットと「perl guru」によって書かれたフレームワークがあります。このコードには多くのあいまいなperlイディオムが含まれており、私を含め開発者は誰もこのperlコードを長時間の努力なしに読むことはできません。私たちはしばしば彼をののしります。:)

良いコードを書いたとしても、現在または将来の同僚がそれに従うのが難しいと思う場合は、簡単なコメントを追加して説明する必要があります。

そうすれば、個々のインテリジェンスをs辱したり、グループディスカッションで誰かを困惑させたりせずに、何かを教えることができます。

私はあなたの例をトリックとは呼びませんが、ただの慣用句です。あなたがそれを使用すべきかどうかは、チームの現在のレベルにそれほど依存しませんが、チームメイトが（少なくとも一部）チームが新しいイディオムを学ぼうとする場合です。もちろん、あなたは彼らとこのトピックについて話し合うべきであり、彼らにこのスタイルを強制するべきではありません。また、毎日5つの新しいことや「トリック」を学ぶように依頼するべきではありません。しかし、正直なところ、チームメイトだけが新しいことを学ぼうとしない場合は、たとえこのイディオムよりも単純で小さくても、別のチームに変更することを検討する必要があります。

この質問とそれに続く回答と議論を読むと、2つのポイントがあるようです。1つ目：高度な言語機能を使用しても大丈夫ですか？2番目：どうやったら「自慢している」ように見えずにこれを行うことができますか？

最初のケースでは、改善と高度な機能を使用することが理にかなっています。たとえば、C＃では、LinqまたはLambdaの式を使用する必要はありませんが、実際に何をしているのかを理解すれば、コードがより整頓され、理解しやすくなるため、ほとんどの人が使用します。最初は奇妙に見えます。

人々はパターンに慣れ、多くの場合、人々は仕事を成し遂げるためだけに物事を行うための設定された方法を使用します。私は次の男と同じくらい有罪です。締め切りがあります。いくつかの点で、あなたは新しいアイデアや新しい考え方を導入することに罪を犯しています！これは2番目のポイントになります。これはおそらく、最も抵抗に直面する可能性がある場所です。

Webサイトを使用している人にとって、どのスタイルが使用されているかは気にしません。速いですか？したがって、あなたの方法にパフォーマンス上の利点がない場合、あなたが与える例には正しい方法または間違った方法はありません。あなたのやり方でコードを読みやすくしますか？あなたの同僚がそれに慣れたら、それはするかもしれません。

それでは、これらの変更をどのように導入しますか？これらの線に沿って同僚と議論してみてください：この機能がこのように書けることをご存知ですか？コードレビューとペアプログラミングは、アイデアの「相互受粉」を可能にする良い機会です。あなたが働いている環境がわからないので、私は何をすべきかを処方するのが難しいです。一部のプログラマーは、非常に防御的で変化に対して抵抗力があることがわかります。繰り返しますが、私はこれについて有罪です。この種のプログラマーと仕事をするための最良の方法は、彼らがカチカチ音をたてる原因を学び、彼らの背景を学び、そしてあなたのスタイルと経験を彼らと比較することです。それは時間がかかりますが、それはよく費やされた時間です。可能であれば、それらを奨励してください。

Royal McBee Computer Corpに出向かないでください。あなたは経験の浅いプログラマーではないと言ってくれる人がいるからです。

確かに、簡潔で短いコードを書くのは素晴らしいことであり、javascript環境で役立つかもしれません（誰かがブラウザにダウンロードするjsコンパイラを作成するまでは、それは別の話です）。

重要なことは、コードを書くのにかかった数分を過ぎてもコードが生き残る能力です。確かに、その迅速かつ簡単な方法で、それをまとめて先に進むことができますが、数年後に戻って来なければならない場合、「どのマペットがこれを書いた」と思い、それがあなただと気づくかもしれません！（私はそれをやった、ほとんどの人もそうだと確信している。.正直に言って、過度に攻撃的な締め切りを非難する）。

これは心に留めておくべき唯一の重要なことですので、私はイエスと言いますが、それが機能していて明確な場合はその特定のオペレーターと一緒に行きますさまざまなWebページのチュートリアルやリファレンスを覚えているので、すべての演算子とトリックを知っている経験の浅い開発者は、小さなトリックをすべて知っていても最悪のコードを記述します...これは偶然ではありません）

とにかく、Melのストーリーを読むことができれば、Melが最初の注文の真のプログラマーであったとしても、トリックはコードに入れるのに最適なものではないことに気付くでしょう。これは、誰かが良いコードを書くことができ、他のすべての人が遅れずについていくためにもっと学ぶ必要があると言っている議論に報酬を与えます。

まあ、私にとって基本的なJSのように見える初心者にとって。

しかし一般的には、「デバッグはプログラミングの2倍困難です。可能な限り賢いコードを書くと、当然デバッグできません」と言い換えると、巧妙なハックを使用すべきではありません。

他の人が理解できないという理由だけでコードを避ける必要があるという意味ではありません。できるだけ明確で一貫した方法でコードを書く必要があります。ただし、クリアの基準は、「誰でも理解できるか」ではなく、「1年以内に最初に読んだときにこれを理解するか」である必要があります。

理解しやすく、他の人にスキルの向上に取り組んでもらうことを明確に書いてください。他の人に仮想のトラブルを救うために自分自身にハンディキャップを与えないでください。

私たちがどのようなコーディング標準を持ちたいのかをチームメートと話し合いたいと思います。これは主に、コードベースに対して何十通りの方法でできることをどのようにすべきかということです。コンセンサスがあれば、それが私の最初の回答の試みになります。

存在しない場合、どのような提案された標準が理にかなっているかを検討し、経営陣とチームの一部でそれをクリアしたら、それを実践し始めます。ここでのアイデアは、このアイデアで経営陣が大丈夫であることを確認することであり、私は自分のことをやめてから他の人にそれを強制するだけではありません。

コードを評価する方法はたくさんあるので、これは単なるスキルレベルではなく、チームがどのような標準や慣行を持っているかという問題に似ています。他の人がどれだけうまく維持できるかは、それらの基準の1つです。

問題は、ソースの読みやすさを望んでいることですが、読みやすさは見る人の目にあります。

この問題を解決するには、より良いツールが必要であることをお勧めします。複雑なことは何もありませんが、50年以上にわたってそれを実行するためのテクノロジーがあります。エディターにパーサーを組み込み、エディターにsexpsの形式でソースを保存させます（はい、lispのように）。次に、ソースが読み込まれ、エディターはユーザーが好みの形式と構文（スペース、タブ、コンマ）に構文解析します。

このように、あなたはタイプして読むことができx = x || 10、他のプログラマーはそれを

if (0 == x) { x = 10;}

emacsには、それを簡単に行うためのすべての要素があります。

コードを馬鹿にせずに、チームの品質を向上させてみませんか？トレーニング、コーチング、教育、改善された雇用慣行は、継続的な改善を確保するために多くのことができます。
誰かが自己改善に取り組みたくないので、統計、コードの腐敗、改善と革新の拒否は、後の方ではなくすぐにトラブルを引き起こすだけです。

もちろん、あなたが示す特定のケースでは、巧妙で意図的に難読化されたコードを記述しようとしているだけです。これは決して良い考えではありません。コードはまず、読みやすく、理解しやすく、可能な限り最小限のステートメントで何かを作成するのがいかに巧妙であるかを示すために書かれてはなりません（特別な場合は例外です。ために）。