これら 2 つのコードのどちらが優れています... どちらもかなりひどいものですが、対処しましょう
関数は 1 つのことしか実行できません。なぜこれほど読みやすいのでしょうか?スケーラビリティ?再利用性?私の意見では、関数の宣言にはコストがかかりません。関数はメモリ内のスペースを占有するだけです。関数の呼び出しは直接分析する必要がないため、より高速です~
再利用や拡張のためであれば、初めて書くときに事前に最適化を行う必要はないのでしょうか? 将来のニーズは判断できません? 提案された機能が将来的に普遍的であることはどのようにしてわかりますか?この観点から見ると、それは間違いなく当てはまりません。
前進/移行の最適化は諸悪の根源ではないでしょうか? ~
typecho2017-07-05 11:07:16
クラスに関する限り、その変更の理由は 1 つだけです。 JavaScript では、クラスの使用を必要とするシナリオはそれほど多くはありません。単一責任の原則はオブジェクト レベルまたはメソッド レベルで適用されることが多いため、このセクションでの説明は主にオブジェクトとメソッドに基づいています。
単一責任原則 (SRP) における責任は、「変化の原因」として定義されます。メソッドをオーバーライドする動機が 2 つある場合、このメソッドには 2 つの責任があります。それぞれの責任が変化の軸となります。メソッドが負う責任が多すぎると、要件の変化に応じてメソッドを書き直す必要が生じる可能性が高くなります。
現時点では、このメソッドは通常不安定なメソッドであり、コードの変更は常に危険です。特に 2 つの責任が結合されている場合、1 つの責任の変更が他の責任の実装に影響を及ぼし、予期せぬ損害を引き起こす可能性があります。
この結合凝集力が低く、壊れやすいデザインになります。
したがって、SRP 原則は次のように具体化されます: オブジェクト (メソッド) は 1 つのことだけを実行します。
怪我咯2017-07-05 11:07:16
私の個人的な意見を話させてください。プログラムは、関数が複雑になればなるほど、読むコストも高くなります。プログラムを書いたとしても、数か月後にはその意味を理解するのに時間がかかる場合があり、言うまでもなく、他の人があなたのコードを乗っ取る可能性があります。
まずプログラムを理解してから、ランニングパフォーマンスの最適化について話してください
代言2017-07-05 11:07:16
コードを短期間だけ使用する必要があり、後で反復する必要がなく、他の同僚に提供する必要がなく、単体テストも必要ない場合は、気軽にコードを書いて関数を実装してください。
あなたのコードを他の同僚が呼び出す必要がある場合は、反復、拡張、および単体テストを行う必要があります。あとは仕様に従ってください。パフォーマンスはコードの形式によって決まることはありません。
最も簡単な方法は、1 か月後にコードを見て、読み取り、保守、拡張が難しいと感じたら、それをリファクタリングすることです。
滿天的星座2017-07-05 11:07:16
関数は 1 つのことだけを実行する方が良いと思います...これらの陰湿な関数が副作用をあちこちに広めるかどうかは誰にもわかりません...
1 つのことだけを実行し、最終的にそれらを接続して使用する方が良いでしょう。
また、パフォーマンスに大きな違いはないと思います。おそらく、1 つのことだけを実行する関数の方がパフォーマンスが良いでしょう。
2 番目のコードと比較した最初のコードの明らかな特徴の 1 つは、関数ごとの平均行数が少ないのに対し、2 番目のコードの平均行数が多いことです。
短いコードのメンテナンスや記述の精神的負担が比較的少ないため、メンテナンスや記述の効率が高いです
1 つのことだけを行うということは、この関数がこのタスクを完了できれば十分であることを意味し、別のアルゴリズムによって実装されたこの関数のコピーに簡単に直接置き換えることができます。
短く簡潔な小さな関数をたくさん書くため、アセンブリ時の抽象度が高く、思考に適しています。
再利用と拡張のためなら、初めて書くときにこれを行うのは、本当に事前の最適化ではないでしょうか?
再利用と拡張は決して提前优化ではなく、逆にこの2つにもっと注意を払うべきです
習慣沉默2017-07-05 11:07:16
その通りです。それは読みやすさ、拡張性、再利用のためです。最も重要なことは可読性と保守性です。複数のことを行う関数に名前を付けることさえできず、ましてや他の人にそれを理解させることもできません。
時期尚早な最適化とは、「関数がメモリ内のスペースを占有する」ことを指します。