背景

過去数年にわたって、私は多数のインタビューに参加してきました。 それらのそれぞれで、私は応募者に唯一の責任の原則（以下SRP）について尋ねました。 そして、ほとんどの人は原則について何も知りません。 そして、定義を読むことができた人でさえ、彼らが仕事でこの原則をどのように使っているかを言うことはほとんどできませんでした。 彼らは、SRPが自分が書いたコードや同僚のコードレビューにどのように影響するかを言うことができませんでした。 また、SOLID全体と同様に、SRPはオブジェクト指向プログラミングにのみ関連しているという誤解もありました。 また、よく知られているフレームワークで推奨されているスタイルでコードが記述されたという理由だけで、多くの場合、人々はこの原則に違反する明らかなケースを特定できませんでした。

Reduxは、ガイドラインがSRPに違反しているフレームワークの代表的な例です。

SRPの問題

私は、この原則の価値、それがもたらす利点から始めたいと思います。 また、この原則はOOPだけでなく、手続き型プログラミング、関数型、さらに宣言型にも適用されることに注意してください。 後者の代表としてのHTMLは、特にReactやAngularなどのUIフレームワークによって制御されている場合は特に、分解することができます。 さらに、この原則は他のエンジニアリング分野にも適用されます。 そして、工学だけでなく、軍事分野でもそのような表現がありました。「分割して征服する」ことです。これは、概して同じ原則の具体化です。 複雑さは殺し、それを部分に分割し、あなたは勝ちます。

他のエンジニアリング分野に関しては、ここハブで、開発された航空機がどのようにエンジンを故障させ、パイロットのコマンドでリバースに切り替えなかったかについての興味深い記事がありました。 問題は、シャーシの状態を誤って解釈していたことです。 エンジンコントローラーは、シャーシを制御するシステムに依存する代わりに、シャーシにあるセンサー、リミットスイッチなどを直接読み取ります。 また、エンジンがプロトタイプの航空機に搭載される前に、エンジンが長い認証を受ける必要があることも記事で言及されました。 また、この場合のSRP違反は、シャーシの設計を変更するときに、エンジンコントローラーのコードを変更して再認証する必要があるという事実に明らかにつながりました。 さらに悪いことに、この原則に違反することは飛行機とパイロットの人生にほとんど価値がありました。 幸いなことに、私たちの日常のプログラミングはそのような結果を脅かすものではありませんが、良いコードを書くという原則を無視するべきではありません。 理由は次のとおりです。

1. コードの分解により、コードの複雑さが軽減されます。 たとえば、問題の解決策として循環的複雑度4のコードを記述する必要がある場合、そのような2つの問題を同時に解決する方法には複雑度16のコードが必要になります。仕事に対する金額になりますが、とにかく傾向はほぼ同じになります。
2. 分解されたコードの単体テストは簡素化され、より効率的になります。
3. 分解されたコードは、変更に対する抵抗が少なくなります。 変更を行うとき、ミスをする可能性は低くなります。
4. コードの構造が改善されています。 ファイルやフォルダーに配置されたコード内の何かを検索することは、1つの大きなフットクロスよりもはるかに簡単です。
5. 定型コードをビジネスロジックから分離すると、コード生成をプロジェクトに適用できるようになります。

そして、これらのすべての兆候は一緒になり、これらは同じコードの兆候です。 たとえば、十分にテストされたコードと十分に構造化されたコードを選択する必要はありません。

既存の定義は機能しません

定義の1つは、「コード（クラスまたは関数）を変更する理由は1つだけであるべきです」です。 この定義の問題は、SOLIDの2番目の原則グループであるOpen-Close原則と競合することです。 その定義：「コードは拡張のために開かれ、変更のために閉じられなければなりません。」 変更の理由の1つと、変更の完全な禁止。 ここで何を意味するのかをより詳細に明らかにすると、原則間に矛盾はないことがわかりますが、ファジー定義の間には間違いなく矛盾があります。



2番目の、より直接的な定義は、「コードには1つの責任のみが必要です」です。 この定義の問題は、すべてを一般化することは人間の本性であるということです。



たとえば、鶏を飼育している農場があり、その時点で農場の責任は1つだけです。 そのため、アヒルも繁殖させることが決定されました。 本能的には、2つの責任があることを認めるのではなく、養鶏場と呼びます。 そこに羊を追加すると、これがペットファームになります。 次に、そこでトマトまたはキノコを栽培し、さらに一般化された次の名前を考えます。 同じことが、変更の「1つの理由」にも当てはまります。 この理由は、想像力で十分に一般化できます。



別の例は、宇宙ステーション管理者クラスです。 彼は他に何もしません、彼は宇宙ステーションを管理するだけです。 このクラスを1つの責任でどのように気に入っていますか？

また、求職者がこの技術に精通しているときにReduxについて言及したので、質問もします。典型的なSRPリデューサーは違反しますか？



リデューサーにはswitchステートメントが含まれており、場合によっては数十または数百のケースにまで拡大することがあります。 レデューサーの唯一の責任は、アプリケーションの状態遷移を管理することです。 つまり、文字通り、一部の応募者が答えました。 また、この意見を裏付けるヒントはありません。



全体として、ある種のコードがSRPの原則を満たしているように見えるが、同時に不快なにおいがする場合-なぜこれが起こるのかを知ってください。 「コードには1つの責任が必要」という定義が機能しないためです。

より適切な定義

試行錯誤から、より良い定義ができました：

コードの責任は大きすぎてはいけません



はい。クラスまたは関数の責任を「測定」する必要があります。 そして、それが大きすぎる場合、この大きな責任をいくつかの小さな責任に分割する必要があります。 農場の例に戻ると、鶏を飼育する責任さえも大きすぎる可能性があり、たとえばブロイラーを層から何らかの方法で分離することは理にかなっています。



しかし、それを測定する方法、このコードの責任が大きすぎると判断する方法は？



残念ながら、私は数学的に正確な方法はなく、経験的な方法しかありません。 そして、これらのすべては経験に基づいています。初心者の開発者はコードを分解することはできません。より高度な開発者はコードを所有するのに優れています。

1. メトリック循環的複雑度。 残念ながら、このメトリックをマスクする方法がありますが、収集すると、アプリケーション内で最も脆弱な場所が表示される可能性があります。
2. 関数とクラスのサイズ。 800行の関数は、何か問題があることを理解するために読む必要はありません。
3. たくさんの輸入。 隣のチームのプロジェクトでファイルを開くと、インポートの画面全体が表示され、ページを下に押すと、画面にはインポートのみが表示されていました。 2回目のプレスの後、コードの始まりを見ました。 すべての最新のIDEはプラス記号の下でインポートを非表示にできると言うことができますが、良いコードは「匂い」を非表示にする必要はないと言います。 さらに、小さなコードを再利用する必要があったため、このファイルから別のコードに削除し、インポートの4分の1または3分の1がこの部分の後ろに移動しました。 このコードは明らかにそこに属していませんでした。
4. 単体テスト。 それでも責任の量を判断するのが困難な場合は、テストを書くように強制してください。 境界線のケースなどをカウントせずに、関数の主な目的で20個のテストを記述する必要がある場合は、分解が必要です。
5. 同じことは、テストの開始時の準備段階が多すぎて、終了時のチェックにも当てはまります。 ちなみに、インターネット上では、いわゆる テストでアサートするのは一般に1つだけです。 しかし、私は、arbitrarily意的に良いアイデアが絶対的なものに上げられると、ばかげて非現実的になると信じています。
6. ビジネスロジックは、外部ツールに直接依存しないでください。 OracleドライバーのExpressルートでは、これらすべてをビジネスロジックから分離したり、インターフェースの背後に隠したりすることが望ましいです。

いくつかのポイント：



もちろん、すでに述べたように、コインには裏返しがあり、1行の800メソッドは800行の1メソッドよりも良くないかもしれません。すべてのバランスが取れているはずです。



第二-私は、このコードをその責任に従ってどこに置くべきかという問題をカバーしていません。 たとえば、開発者がDALレイヤーに多くのロジックを取り込むのが難しい場合もあります。



第三に、「関数あたり50行以下」などの特定のハード制限を提案しません。 このアプローチには、開発者、そしておそらくチームの開発の方向性のみが含まれます。 彼は私のために働いています、彼は他の人のためにお金を稼がなければなりません。



そして最後に、TDDを使用する場合、これだけで、それぞれ20個のアサーションを含む20個のテストを作成するはるか前に、コードを確実に分解できます。

定型コードからビジネスロジックを分離する

良いコードのルールについて言えば、例がなければできません。 最初の例は、定型コードの分離に関するものです。







この例は、バックエンドコードの通常の記述方法を示しています。 人々は通常、URL、リクエストメソッドなどのWebサーバーExpressへのパラメータを示すコードを使用してロジックを密接に記述します。



ビジネスロジックを緑色のマーカーとしてマークし、赤色の散在コードがクエリパラメーターと相互作用します（赤色）。



私はこの2つの責任を常にこのように共有しています。







この例では、Expressとのすべての対話は別のファイルにあります。



一見したところ、2番目の例では改善が見られなかったように見えるかもしれません。1つではなく2つのファイルがあり、以前は存在していなかった追加行が表示されました。 そして、このコードの分離は何をもたらしますか？ まず、「アプリケーションエントリポイント」はExpressではなくなりました。 これは通常のTypescript関数です。 または、C＃かどうかに関係なくWebAPIを作成するJavaScript関数。



これにより、最初の例では使用できないさまざまなアクションを実行できます。 たとえば、Expressを発生させることなく、テスト内でhttp要求を使用せずに、動作テストを作成できます。 そして、どんな種類の濡れをする必要もないとしても、Routerオブジェクトを「テスト」オブジェクトに置き換えれば、アプリケーションコードをテストから直接呼び出すことができます。



この分解によって提供される別の興味深い機能は、userApiServiceを解析し、このサービスをExpressに接続するベースでコードを生成するコードジェネレーターを作成できることです。 今後の出版物では、次のことを示す予定です。コード生成では、コードを記述するプロセスの時間を節約できません。 コードジェネレーターのコストは、この定型文をコピーする必要がなくなったという事実によって報われません。 コード生成は、それが生成するコードがサポートを必要としないという事実によって報われます。これは時間を節約し、最も重要なこととして、長期的には開発者の神経を節約します。

分割して征服する

コードを記述するこの方法は長い間存在しており、私は自分で発明しませんでした。 ビジネスロジックを記述するときに非常に便利であるという結論に達しました。 このために、別の架空の例を思いつきました。すぐに簡単にコードを記述し、すぐに適切に分解され、命名方法によって自己文書化されるコードを作成する方法を示しました。



ビジネスアナリストからタスクを取得して、従業員レポートを保険会社に送信するメソッドを作成するとします。 これを行うには：

1. データベースからデータを取得する必要があります
2. 目的の形式に変換する
3. 結果のレポートを送信

このような要件は、常に明示的に記述されているわけではなく、アナリストとの会話からこのようなシーケンスが暗示されたり明確にされる場合もあります。 このメソッドを実装するプロセスでは、データベースまたはネットワークへの接続を急いで開くのではなく、この単純なアルゴリズムを「そのまま」コードに変換してみてください。 このようなもの：

async function sendEmployeeReportToProvider(reportId){ const data = await dal.getEmployeeReportData(reportId);​ const formatted = reportDataService.prepareEmployeeReport(data);​ await networkService.sendReport(formatted);​ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチを使用すると、かなりシンプルで読みやすいコードを取得できますが、このコードは簡単で、テストの必要はないと思います。 また、レポートを送信しないのはこのメソッドの責任であり、その責任はこの複雑なタスクを3つのサブタスクに分割することでした。



次に、要件に戻り、レポートが給与セクションと労働時間のセクションで構成されている必要があることを確認します。

 function prepareEmployeeReport(reportData){ const salarySection = prepareSalarySection(reportData);​ const workHoursSection = prepareWorkHoursSection(reportData);​ return { salarySection, workHoursSection };​ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その他、些細に近い小さなメソッドの実装が残るまで、タスクを分割し続けます。

オープンクローズ原則との相互作用

記事の冒頭で、SRPとOpen-Closeの原則の定義は互いに矛盾していると述べました。 前者は変更の理由が1つあるに違いないと述べ、後者は変更のためにコードを閉じる必要があると述べています。 そして、原則自体は、互いに矛盾しないだけでなく、反対に、相互に相乗効果を発揮します。 5つのSOLID原則はすべて、1つの良い目的を目指しています-どのコードが「悪い」か、どのように変更して「良い」コードになるかを開発者に伝えることです。 皮肉なことに、私は5つの責任をもう1つの責任に置き換えました。

したがって、レポートを保険会社に送信する前の例に加えて、ビジネスアナリストが来て、今度はプロジェクトに2つ目の機能を追加する必要があると言っていることを想像してください。 同じレポートを印刷する必要があります。

SRPは「分解に関するものではない」と考えている開発者がいると想像してください。

したがって、この原則は彼に分解の必要性を示しておらず、彼は1つの機能で最初のタスク全体を実現しました。 タスクが彼に来た後、彼は2つの責任を1つにまとめます。 それらの間には多くの共通点があり、その名前は一般化しています。 現在、この責任は「サービスレポート」と呼ばれています。 この実装は次のようになります。

 async function serveEmployeeReportToProvider(reportId, serveMethod){ /* lots of code to read and convert the report */ switch(serveMethod) { case sendToProvider: /* implementation of sending */ case print: /* implementation of printing */ default: throw; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクトのコードを思い出しますか？ 私が言ったように、SRPの直接的な定義は両方とも機能しません。 そのようなコードを記述できないという情報を開発者に送信することはありません。 そして、どのコードを書くことができます。 開発者がこのコードを変更する理由はまだ1つだけです。 彼は単に以前の理由を呼び直し、スイッチを追加し、落ち着いています。 そして、ここでは、Open-Close原則の原理が登場します。これは、既存のファイルを変更することは不可能であると直接述べています。 新しい機能を追加するときに、既存のファイルを編集するのではなく、新しいファイルを追加する必要があるようにコードを記述する必要がありました。 つまり、このようなコードは一度に2つの原則の観点からは悪いです。 そして、もし最初のものがそれを見るのを助けなかったら、2番目のものが助けになるはずです。



そして、分割統治法は同じ問題をどのように解決しますか：

 async function printEmployeeReport(reportId){ const data = await dal.getEmployeeReportData(reportId);​ const formatted = reportDataService.prepareEmployeeReport(data);​ await printService.printReport(formatted);​ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しい関数を追加します。 実装を持たないため、「スクリプト関数」とも呼ばれることがあり、責任の分解部分を呼び出す順序を決定します。 明らかに、最初の2行、最初の2つの分解された責任は、以前に実装された関数の最初の2行と一致しています。 ビジネスアナリストが説明した2つのタスクの最初の2つのステップが一致するように。

したがって、プロジェクトに新しい機能を追加するために、新しいスクリプトメソッドと新しいprintServiceを追加しました。 古いファイルは変更されていません。 つまり、このコード記述方法は、2つの原則の観点から見て適切です。 そして、SRPとオープンクローズ

代替案

また、次のような適切に分解されたコードを取得するための代替の競合方法についても言及したいと思います。まず、「額に」コードを記述し、その後、ファウラーの本「リファクタリング」に従って、さまざまな手法を使用してリファクタリングします これらの方法は、チェスのゲームに対する数学的アプローチを思い出させました。戦略の観点から自分が何をしているかを正確に理解せず、自分のポジションの「重み」を計算し、動きを加えて最大化しようとします。 メソッドと変数に名前を付けることは既に困難であり、ビジネス価値がない場合は不可能になるという小さな理由で、このアプローチが好きではありませんでした。 たとえば、これらの手法で、あちこちから6つの同一の行を選択する必要があることが示唆されている場合、それらを選択して、このメソッドを何と呼びますか？ someSixIdenticalLines（）？

予約をしたい-この方法が悪いとは思わない。使い方を学ぶことができなかった。

合計

原則に従うと、メリットが得られます。



「1つの責任がなければならない」という定義は機能しません。



より良い定義といくつかの間接的な機能、いわゆる コードは分解の必要性を示す匂いがします。



分割統治のアプローチにより、すぐに適切に構造化された自己文書化コードを書くことができます。