JavaScript：コードを明確にするためのパス

作業コードは常に完璧ではありませんが、プログラムテキストを作成するときは、読みやすく、理解しやすく、修正しやすいように努力する必要があります。 コードを明確にするために努力する価値があります。 これを実現するには、エディターを開く前であっても、コードを適切に編成する必要があります。すべてを慎重に計画する必要があります。









何が起こるのかを明確にしたプログラミングは、優れた開発者を通常の開発者から分離するものです。 この記事では、明確なコードに向けて最初の一歩を踏み出すことを可能にするいくつかの基本原則を提供したいと思います。



ここで説明したアイデアはさまざまなプログラミング言語に適用できますが、ほとんどの例はオブジェクト指向のJavaScriptで記述されています。 この言語での開発に対するこのアプローチに慣れていない場合は、 「モジュール」パターンおよびJSのプロトタイプオブジェクト指向プログラミングに関する資料を見ることができます。 これにより、ここで説明する内容をすぐにマスターできます。

単独責任の原則

あなたが家事をしていて、壁にネジをねじ込むためにドリルをしたと想像してください。 仕事をしてツールを下げたとき、ドリルには1つの興味深い機能があることがわかりました。 その主な機能に加えて、ねじ込まれたねじの上に速乾性化合物を噴霧し、ねじを隠し、石膏を模倣します。 これは、ネジがねじ込まれる壁の一部をペイントする場合に非常に便利ですが、これは必ずしも必要ではありません。 さらに、何かに穴を開けるためだけに2回目のドリルを受けたくありません。 ドリルは、1つの機能のみを実行する場合、はるかに便利で信頼性の高いツールになります。 これにより、多くの状況での使用に適した、かなり柔軟なツールになります。



唯一の責任の原則は、コードの一部が1つのことを実行し、適切に実行する必要があることを示しています。 前の例のドリルと同様に、機能を制限すると、実際にコードスニペットの有用性が向上します。 これを念頭に置いてプログラミングすることで、多くの問題が解消されるだけでなく、将来プロジェクトに参加する開発者の作業が楽になります。



責任範囲の観点から関数とメソッドを検討してください。 コードの責任範囲を拡大すると、柔軟性と信頼性が低下し、変更の要求が厳しくなり、エラーが発生しやすくなります。 コードを明確にするために、各関数またはメソッドは単一のタスクを解決する必要があります。



関数が何をすべきかを記述し、同時に「and」を使用すると、この関数はおそらく複雑すぎます。 関数によって解決される問題は、関数の意味のある名前とその引数のリストの助けを借りてのみ説明できるように、十分に単純でなければなりません。その名前も関数によって解決される問題における役割を示します。



最近、電子版のMyers-Briggsテストを作成するタスクが与えられました。 以前はこれをしなければなりませんでした。 数年前、私が最初に同じタスクに出くわしたときに、 processForm



という巨大な関数を作成しました。 彼女は結果を計算し、チャートをプロットし、DOMとデータの視覚化に関連するすべてを管理しました。



問題は、何かを変更しなければならない場合、どこで変更を行うかを正確に理解するためだけに大量のコードを整理する必要があるということでした。 さらに、関数の腸のどこかで問題が発生した場合、エラーを見つけることは非常に困難でした。



そのため、今回同じ問題に直面したとき、すべてのロジックを関数に分割し、それぞれが独自の問題を解決しました。 これらの関数をモジュールオブジェクトにラップしました。 その結果、フォームの送信時に呼び出された関数は次のようになりました。

 return {   processForm: function() {       getScores();       calculatePercentages();       createCharts();       showResults();   } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、完全なアプリケーションコードを見ることができます。



このようなコードは、読み取り、理解、および修正が非常に簡単です。 プログラミングにはほど遠い人でも、ここで何が起こっているかを理解できます。 そして、これらの関数のそれぞれ（確かに、あなたはすでにそれについて推測しました！）1つの問題だけを解決します。 これが行動における唯一の義務の原則です。



たとえば、フォームデータを検証する必要がある場合、巨大な関数を編集する（および場合によってはその作業を中断する）代わりに、新しいメソッドをプロジェクトに追加するだけです。 さらに、このアプローチにより、関連する変数と関数をグループ化できるため、名前の競合の数が減り、コードの信頼性が向上し、必要に応じて他の目的での関数の再利用が大幅に簡素化されます。



覚えておいてください：1つの機能-1つのタスク。 大きな関数はクラスに処理する必要があります。 関数が互いに強く関連し、同じデータを使用する多くの問題を解決する場合、フォームを処理するために大きな関数で行ったように、それを作り直してメソッドでオブジェクトに変えるのが理にかなっています。

コマンドとリクエストの分離

おそらく、私がこれまで読んだ中で最も面白い通信は、David Thorneが彼女の行方不明のMissy猫を検索するためのポスターの作成についてShannon Walkleyに語ったものです。 シャノンがデイビッドにポスターを作るように頼むたびに、デイビッドは彼女がしたことをしたが、彼女自身から何かを追加した結果、シャノンは彼女が期待したものとは異なる何かを受け取った。 この通信は読むのがとても楽しいですが、あなたのコードが同じことをすれば、もはや面白くありません。



コマンドとリクエストの分離は、不要な副作用からコードを保護するための基礎となり、関数を呼び出すときの不快な驚きを防ぎます。 機能は2つのカテゴリに分類されます。 1つはコマンドを実行する関数を含み、2つ目はクエリを実行する関数を含みます。 前者はいくつかのアクションを実行し、後者は質問に答えます。 それらを混合することは推奨されません。 次の機能を検討してください。

 function getFirstName() {   var firstName = document.querySelector("#firstName").value;   firstName = firstName.toLowerCase();   setCookie("firstName", firstName);   if (firstName === null) {       return "";   }   return firstName; } var activeFirstName = getFirstName();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは単純化された例であり、関数の操作中に発生する予期しない副作用を簡単に確認できます。 実際には、ほとんどの副作用を見つけるのははるかに困難です。



関数の名前getFirstName



は、関数が名前（名）を返す必要があることを示しています。 ただし、彼女が最初に行うことは、ドキュメントから取得した名前を小文字に変換することです。 関数の名前は、どこかから何かを取得する（要求を実行する）必要があることを示していますが、関数はデータの状態も変更します（つまり、特定のコマンドを実行します）。 これは、関数の名前から推測することが不可能な副作用です。



さらに悪い。 この関数は、リクエストされた名前をcookieに書き込みますが、それについては何も通知しません。 これは、彼女が私たち自身がクッキーで書いたものを書き直し、私たちが期待していることを書き換えるという事実につながる可能性があります。 要求を実行する関数がデータを上書きすることはありません。



覚えておくと便利なルールは、関数が質問に答えた場合、データの状態を変更するのではなく、値を返す必要があるということです。 逆に、関数が何かをする場合、データを変更し、何も返さないようにする必要があります。 コードを最大限に明確にするために、同じ関数が特定の値を返してデータを変更することはありません。



同じコードの改善されたバージョンは次のようになります。

 function getFirstName() {   var firstName = document.querySelector("#firstName").value;   if (firstName === null) {       return "";   }   return firstName; } setCookie("firstName", getFirstName().toLowerCase());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは簡単な例ですが、願わくは、アクションを実行するコードと結果を返すコードにコードを分割することでプログラマの意図を明確にし、ミスを避けることができるため、明確に表示されることを願っています。 関数のサイズとコードベースが大きくなると、そのような分離はより重要になります。関数を使用するときはいつでも関数の定義を検索するだけで、この関数が正確に何をするのかを知ることは、誰かの効果的な使用とは言えませんいずれかの時間。

弱い結合

パズルとレゴキューブの違いを考えてみましょう。 パズルの場合、その各ピースは他と一方向にしか接続できず、パズルのすべてのピースから1つの画像しか収集できません。 LEGOについて話す場合、キューブは好きなように相互に接続して、同じブロックから必要なものをすべて収集できます。 何かを作成するためにこれらのタイプのビルディングブロックのいずれかを選択する必要があった場合、作成するものを知る前に、何を選択しますか？



リンクは、プログラムの1つのブロックが他のブロックにどれだけ依存しているかを示す指標です。 依存が多すぎる（または結合が多すぎる）と、プログラムの柔軟性が低下します。 これがパズルの仕組みであり、避けるべきです。 コードの柔軟性に努めており、レゴブロックのプロパティを持たせたいと考えています。 そして、これはすでに弱いバインディングと呼ばれ、そのようなコードの編成は通常、より明確になります。



コードは、使用するための多くのオプションをオーバーライドできるように、十分に柔軟でなければならないことに注意してください。 コードスニペットをコピーして貼り付け、小さな変更を加えたり、何かがどこかで変更されたために何かを書き換えたりすることに気付いた場合-知っている-これらは強力なバインディングの結果です。 プログラムコンポーネントの強いつながりのもう1つの兆候は、関数内のハードコーディングされたID、関数のパラメーターが多すぎる、非常に類似した関数が多く、唯一の義務の原則に違反する大きな関数の存在です。 たとえば、前の例のgetFirstName



関数を再利用に適したものにするために、コード内のハードコードされたfirstName



を、パラメーターとして渡されたユニバーサルID



置き換えることができます。



強力なバインディングは、多くの場合、関数と変数のグループに現れますが、実際にはクラスとして作成するとよいでしょう。 ただし、これは、クラスが他のクラスのメソッドまたはプロパティに依存している場合にも発生する可能性があります。 関数の相互依存性に関連する問題が発生した場合は、これらの関数とは別のクラスを作成することを検討してください。



インタラクティブダイヤルのセットのコードを扱ったときに、似たようなものに出会いました。 ダイヤルには、サイズ、矢印のサイズ、回転軸のパラメーターなどを決定する変数を含む多くの変数がありました。 このため、開発者は厄介な数の関数パラメーターを使用するか、ハードコーディングされた変数を使用して各関数のコピーをいくつか作成する必要がありました。 さらに、ダイヤルが異なると動作が少し異なります。 これにより、各ダイヤルに1つずつ、ほぼ同一の機能の3つのセットが出現しました。 一言で言えば、バインドはハードコードされた変数とオブジェクトの動作の特性のためにのみ強化されました。その結果、パズルの場合のように、これをすべて収集して機能させる方法は1つだけでした。 コードは不当に複雑であることが判明しました。



再利用に適したクラスに関数と変数を配置することにより、この問題を解決しました。そのインスタンスは3つのダイヤルのそれぞれに対して作成されました。 クラスを設定して、インスタンス化したときに、その動作に影響する関数を渡すことができるようにします。 その結果、異なるダイヤルのインスタンスを作成するときに同じクラスを使用することができました。 その結果、関数の数が少なくなり、変数が1か所に保存されたため、プロジェクトコードのサポートが簡素化されました。



相互に作用するクラスも強力なバインディングの犯人になる可能性があります。 別のクラスのオブジェクトを作成するクラスがあるとしますCollegeCourse



クラスで表される大学の学習コースのようなもので、 Student



クラスで表される学生を作成できます。 したがって、 CollegeCourse



クラスCollegeCourse



正常に機能しています。 しかし、 Student



クラスのコンストラクターにパラメーターを追加する必要があるときがきました。 ここからが楽しみです。 これを行うには、 CollegeCourse



クラスを変更し、 Student



クラスの変更に対応するように変更する必要があります。

 var CollegeCourse = (function() {   function createStudent_WRONG(firstName, lastName, studentID) {       /*          Student ,     ,    !       */   }   function createStudent_RIGHT(optionsObject) {       /*               Student   .      ,         .       */   } }());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別のクラスの変更により、クラスを変更する必要はありません。 これは、強力なバインディングの教科書の例です。 コンストラクターのパラメーターはオブジェクトとして渡すことができ、デフォルト値の存在を想定することができます。これにより、接続が弱くなり、新しいパラメーターを追加するときにコードが引き続き機能するようになります。



その結果、パズルのピースではなく、レゴキューブに似たブロックからプログラムを構築することが推奨されていると言えます。 上記のような問題に遭遇した場合、コード要素の強力なリンクが原因である可能性が非常に高くなります。

高レベルの接続性

子供がクローゼットにすべてを捨てて部屋を掃除するのを見たことがありますか？ もちろん、キャビネットのドアを閉めた状態では、外見はまともなように見えますが、そのような「クリーニング」の後は何も見つからず、互いに共通点のないものが同じ場所に収まることがよくあります。 コードを書くときに高レベルの接続性を追求しないと、コードでも同じことが起こります。



接続性は、プログラムのさまざまなコンポーネントがどのように適合するかを示す尺度です。 高レベルの接続性は優れており、コードスニペットがより明確になります。 接続性が低いと混乱が生じます。 コードブロック内の関数とメソッドは、それらが実行するアクションの意味で接続されている必要があります。つまり、高レベルの接続性が必要です。



高レベルの接続性とは、共通のアイデアによって結合された構造を1か所に集めることを意味します。 たとえば、データベースを操作するための関数、またはアプリケーションによって解決されるタスクのあらゆる側面に関連する関数を1つのコードブロックまたはモジュールで収集します。 このようなアプローチは、これらのエンティティがどのように編成され、どこにあるかを理解するのに役立つだけでなく、名前の競合を防ぐのにも役立ちます。 30個の関数がある場合、名前が競合する可能性は、論理的に4つのクラスに分割されている30個のメソッドがある場合よりもはるかに高くなります。



2つまたは3つの関数が同じ変数を使用する場合は、何らかの方法でグループ化する必要があります。 実際、これはそれらをオブジェクトに結合する良い機会です。 スライダーなどのページ要素を制御するために使用される関数と変数のセットがある場合、これらすべてからオブジェクトを作成し、アプリケーション内のコード接続のレベルを上げることができます。



クラスのおかげで、強い凝集力が回避されたときのダイヤルの例を覚えていますか？ これは、高レベルの接続性がエンティティの強力な接続性と戦うのにどのように役立つかの良い例です。 この場合、高レベルの接続性と強力な接続性は「明瞭さのスケール」の異なる端にあるため、接続性を強化することにより、接続性を弱め、コードを改善します。



重複コードは、低レベルの接続性の信頼できる兆候です。 同様のコード行を関数に配置し、同様の関数を処理してクラスを形成する必要があります。 同じコード行を2回繰り返してはならないという規則に従うと便利です。 実際には、これは常に可能というわけではありませんが、コードを明確にするために、同じコードフラグメントの繰り返し回数を減らす方法を常に考える必要があります。



同様に、同じデータを複数の変数に保存しないでください。 プログラム内の異なる場所で同じデータを使用して変数を定義する場合、間違いなくクラスが必要です。 または、複数の関数で同じHTML要素へのリンクを転送していることがわかった場合、おそらくこのリンクを特定のクラスのインスタンスの一部にする必要があります。



接続性をさらに高めるために、オブジェクトを他のオブジェクト内に配置することもできます。 たとえば、AJAX関数を1つのモジュールに配置できます。これには、フォームの送信、一部の情報のダウンロード、およびシステムへのログインに使用されるユーザー資格情報の検証のためのオブジェクトが含まれます。 同様の構造での作業は、たとえば次のようになります。

 Ajax.Form.submitForm(); Ajax.Content.getContent(7); Ajax.Login.validateUser(username, password);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、逆の場合も、互いに関係のない1つのクラスエンティティに収集する価値はありません。 私が働いていた代理店には、 Common



オブジェクトを含む内部APIがありました。 さまざまなメソッドと変数の全体が集められ、共通点はありません。 クラスは巨大であることが判明しました。作成中に接続性について誰も考えなかったという理由だけで、クラスで作業するのは不便でした。



クラスのいくつかのメソッドでプロパティが使用されていない場合、これは低レベルの接続性の兆候である可能性があります。 同様に、いくつかの異なる状況でメソッドを使用できない場合、またはメソッドがまったく使用されていない場合、これも接続性の低下の兆候です。



高レベルの接続性は、強力なバインディングの効果をスムーズにするのに役立ちます。強力なコードバインディングは、プロジェクトがより高いレベルの接続性を必要とする兆候です。 原則として、高レベルの接続性は開発者に低接続性よりも多くの利点をもたらしますが、通常は両方を同時に実現できます。

まとめ

コードが理想からほど遠い場合、問題が発生します。 コードの明瞭さを達成することは、正しいインデントを使用することよりもはるかに重要です。プロジェクトの最初から慎重に計画することが重要です。 明確なコードを書くことで最高峰に到達するのは簡単ではありませんが、単一の義務、コマンドとリクエストの分離、弱い接続性、高レベルの接続性の原則を順守すれば、独自のコードの明瞭さを大幅に改善できます。 これは、深刻なソフトウェアプロジェクトで作業する場合に考慮する必要があります。



親愛なる読者！ , , ? ?