web-dev-qa-db-ja.com

チームのスキルが低い場合、コードのスキルを下げる必要がありますか?

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

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

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

このトリックを使用するべきではないのですか? JS devによると、コードはピアによって読みにくくなりますが、次のコードよりは読みやすくなります。

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

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

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

157

では、この大きくて複雑なトピックについて、私の見解を説明します。


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

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

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

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

私の個人的な意見

コードのスキルを下げるべきではありません。表現力があり、明確で簡潔なコードを書くことを熱望する必要があります。チームのレベルに疑問がある場合は、教育してください。人々はあなたが考えているよりも学ぶことをいとわない以上であり、彼らがより良いと確信するとき、新しい構成を喜んで適応させます。

彼らがあなたが「ただ賢い」と思っているなら、あなたの主張を主張してみてください。あなたが時々間違っていることを認めてください、そして何があっても、あなたの仕事環境全体を通してスタイルを一貫させておくようにしてください。そうすることで敵意を回避するのに役立ちます。

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

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

135

よくコメント

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

現実には、コメントが少々冗長である方が、スキルの低いチームメンバーには役立つ可能性がありますが、特にスキルが最も低く、コメント数が多すぎる場合は、無視しすぎないようにしてください。

スタイルの問題?

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

すでに述べた別の回答として、一貫性を保つ

男に釣りを教える...

チームメイトを教えることは、おそらく関係者全員を助けることができる最良の方法です。 誰かがコミットログまたはタイムスタンプにあなたの名前が書かれたコードについて質問がある場合、それについて気軽に尋ねるべきであることを明確にしてください。チームにコードレビューがある場合、これは、混乱を招く可能性のある(ahem)のコメントが多いコードをチームメイトに説明する絶好の機会です。チームにコードレビューがない場合は、なぜですか?どうぞ!

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

「賢い」トリック

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

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

KISS

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

47
Corion

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

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

x = x || 'default_value';

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

そのコードを見ると、「nullまたはundefinedの場合は、このデフォルト値に設定します。+0-0も暗黙的に処理しますが、 、NaNfalse""は適切な値ではありません。3か月後に変更する必要があることを覚えておく必要があります。おそらく忘れます。」.

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

新しいスニペットにはより馴染みのある構文がありますが、それでも上記の問題があります。

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

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

これで、Edgeケースを処理するための非常に複雑なロジックを持つことができ、クライアントコードは美しく読みやすいように見えます。


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

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

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

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

等々。

34
Esailija

lowerプログラミングスキルは必要ありませんが、コードの記述方法adjustが必要になる場合があります。ほぼ何よりも目標は、コードを読んで維持する必要のある人々にコードを明確にすることです。

残念ながら、特定のスタイルが「賢い」か、それとも単に高度な使用法であるかについては、判断を呼ぶことになるかもしれません。問題のコードはこれの良い例です-あなたの解決策は必ずしも他のものより優れているわけではありません。そうだと主張する人もいれば、反対する人もいます。どちらのソリューションも実質的に同等のランタイムパフォーマンスを持っているため(読み取り:ユーザーは違いを知らないでしょう)、チーム全体が最も快適なスタイルを選択してください。

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

23
Bryan Oakley

これはすでに別の答えで述べられているかもしれませんが、私はこの質問に自分の注文に答えたいと思います。

一般的なガイドライン

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

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

具体例

コードベースには多数のPerlスクリプトがあります。通常、Perlを使用するのは非常に単純な操作であり、コードの大部分はJava開発者によって書かれているため、Javaとよく似たスタイルになっています。Perlスクリプトのセットとフレームワークがあります。私たちの会社を去った 'Perlの達人'によって書かれました。このコードには多くのあいまいなPerlのイディオムが含まれており、私を含め、私たちの開発者は何の努力もせずにこのPerlコードを読むことはできません。 )

7
user606723

優れたコードを書いていて、現在または将来の同僚がそれを理解するのが難しいと思われる場合は、簡単なコメントを追加して説明してください。

そうすれば、グループディスカッションで、個々の知性を侮辱したり、誰かを困らせたりせずに、何かを教えることができます。

5
DavidR

そのときは、Royal McBee Computer Corpで働いてはいけません。誰があなたが経験の浅いプログラマーではないと言っているからです。

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

ただし、重要なのは、コードを書くのに数分かかった後のコードの機能です。確かに、その迅速で簡単な方法で、チャンクして次へ進むことができますが、何年か後に戻って来る必要がある場合は、「マペットがこれを書いた」と思って、それがあなたであることに気づくときです。 (私はそれをやった、ほとんどの人が持っていることを確認してください。私は正直に言って、非常に攻撃的な期限を非難します)。

これは覚えておかなければならない唯一の重要なことなので、私は「はい」と言いますが、それが機能し、明確である場合は、その特定の演算子を使用します。また、「経験の浅い」開発者(ただし、それは彼らを軽蔑していますが)さまざまなWebページのチュートリアルとリファレンスを覚えているので、すべてのオペレーターとトリックを知っている経験の浅い開発者の場合、彼らはすべての小さなトリックを知っていても、最悪のコードを記述します...これは偶然ではありません)

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

3
gbjbaanb

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

3
Doc Brown

この質問とそれに続く回答と議論を読むと、2つのポイントがあるようです。 1つ目:高度な言語機能を使用しても問題ありませんか? 2つ目:見せびらかしていないようにするにはどうすればよいですか。

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

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

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

では、これらの変更をどのように導入しますか?これらの線に沿って同僚と議論してみてください:この関数がこのように記述できることをご存知ですか?コードレビューとペアプログラミングは、アイデアの「受粉」を可能にする良い機会です。作業している環境がわからないため、何をすべきかを指示するのは難しいです。一部のプログラマーは、非常に防御力があり、変更に抵抗力がある場合があります。もう一度私はこれの罪を犯しています。これらの種類のプログラマと連携する最良の方法は、時間を費やして何が彼らを刺激するのかを学び、彼らの背景を学び、そしてあなたのスタイルと経験を彼らと比較して対比することです。時間はかかりますが、十分に費やされた時間です。可能であれば、彼らを励ましてみてください。

3

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

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

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

理解しやすく、スキルを向上させるために他の人に働きかけることができることを明確な方法で書いてください。他の人にいくつかの架空の問題を保存するために自分を不利にしないでください。

2
jmoreno

これは主にコードベースに対して何十もの方法で実行できることをどのように行うべきかに関するものであるため、どのようなコーディング標準を作りたいかをチームメイトと話し合います。私が最初に回答しようとしたコンセンサスがある場合。

ない場合は、どのような提案された規格が理にかなっているのかを検討し、経営陣や一部のチームとクリアした後、それを実践に移します。ここでのアイデアは、このアイデアで管理に問題がないことを確認することであり、私は自分のことをやって、他の人にそれを強制するだけではありません。

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

1
JB King

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

この問題を解決するには、もっと良いツールが必要だと思います。複雑なことは何もありません。50年以上の間、私たちにはそれを行うためのテクノロジーがありました。エディターにパーサーを組み込み、エディターにソースをsexpsの形式で保存します(そうです、LISPと同じです)。次に、ソースが読み取られ、エディターはそれを構文解析およびタイポグラフィ(ご存知のとおり、スペース、タブ、コンマ)に解析し、ユーザーの好みに合わせます。

このように、x = x || 10と入力して読み取ることができ、他のプログラマーはそれを次のように読み取ります

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

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

1