本当に「ソフトコーディング」とは何ですか？

で、この記事アレックスPapadimoulisすることにより、あなたはこのスニペットを見ることができます：

private void attachSupplementalDocuments()
{
  if (stateCode == "AZ" || stateCode == "TX") {

    //SR008-04X/I are always required in these states
    attachDocument("SR008-04X");
    attachDocument("SR008-04XI");
  }

  if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

  if (coInsuredCount >= 5  && orgStatusCode != "CORP") {
    //Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
    attachDocument("AUTHCNS-1A");
  }
}

私は本当にこの記事を理解していません。

引用：

すべてのビジネスルールの定数は、いくつかの設定ファイルに格納されていた場合は、人生はずっとだろう[全（原文のまま）]困難なソフトウェア保守みんなのために：1、大きなファイルを共有コードファイルがたくさんあるだろうし（または、その逆、非常に多くの小さな設定ファイル）; ビジネスルールの変更を展開するには、新しいコードは必要ありませんが、構成ファイルを手動で変更する必要があります。デバッグははるかに困難です。

これは、構成ファイルに「500000」定数整数、または「AUTHCNS-1A」およびその他の文字列定数を持つことに対する引数です。

これはどうすれば悪い習慣になるのでしょうか？

このスニペットでは、「500000」は数字ではありません。たとえば、次と同じではありません。

int doubleMe(int a) { return a * 2;}

ここで、2は抽象化する必要のない数値です。その使用は明らかであり、後で再利用される可能性のあるものを表すものではありません。

それどころか、「500000」は単なる数字ではありません。これは重要な値であり、機能のブレークポイントのアイデアを表しています。この番号は複数の場所で使用できますが、使用している番号ではありません。それは限界/境界線の概念であり、その下に1つのルールが適用され、その上に別のルールが適用されます。

構成ファイル、または#define、constまたはあなたの言語が提供するものから、それをどのように参照していますか？ソフトウェアは、別の選択を行うように後でプログラム、またはいくつかの他のプログラマに、また、それがボーダーライン必要な場合は、（ので、ねじ込みしているとき、それは変更し、何もそれが両方のファイルに変更されることを保証しません）。デバッグにとっては明らかに悪いことです。

さらに、明日、政府が「5/3/2050以降、AUTHLDG-1AではなくAUTHLDG-122Bを追加する必要がある」と要求した場合、この文字列定数は単純な文字列定数ではありません。アイデアを表すものです。それは単にそのアイデアの現在の値です（「元帳が500kを超える場合に追加するもの」）。

明確にさせてください。記事が間違っていると言っているわけではありません。わかりません。多分それはあまり説明されていません（少なくとも私の考えでは）。

可能なすべての文字列リテラルまたは数値を定数、定義、または構成変数に置き換えることは必要なだけでなく、物事を複雑にしすぎることを理解していますが、この特定の例はこのカテゴリに該当しないようです。後で必要にならないことをどのように知っていますか？それとも他の誰か？

著者は時期尚早な抽象化に対して警告している。

このラインif (ledgerAmt > 500000)は、要件が非常に複雑でありながら正確で十分に文書化されている大規模で複雑なビジネスシステムに見られるビジネスルールのように見えます。

通常、これらの種類の要件は、便利で再利用可能なロジックではなく、例外的な/エッジのケースです。これらの要件は通常、エンジニアではなく、ビジネスアナリストと主題の専門家によって所有および管理されています。

（これらの場合のビジネスアナリスト/専門家による要件の「所有権」は、通常、専門分野で働く開発者が十分な分野の専門知識を持っていない場合に発生します。ただし、開発者と分野の専門家との間の完全なコミュニケーション/協力が保護されることを期待しています曖昧な要件または記述が不十分な要件）

要件がエッジケースと非常に複雑なロジックでいっぱいになっているシステムを保守する場合、通常、そのロジックを便利に抽象化したり保守性を高めたりする方法はありません。抽象化を構築しようとすると、簡単に裏目に出る可能性があります-無駄な時間をもたらすだけでなく、保守性の低いコードももたらします。

構成ファイル、または＃define、constなどの言語が提供するものからも、その値を含めることよりも悪い方法を参照していますか？後でプログラムまたは他のプログラマーもその境界線を必要とする場合、ソフトウェアが別の選択をするように、あなたはねじ込まれます（変更されると、両方のファイルで変更されることを保証するものはありません）。デバッグにとっては明らかに悪いことです。

この種のコードは、おそらくコード自体が要件への1対1のマッピングを持っているという事実によって保護される傾向があります。つまり、開発者が500000要件に図が2回現れることを知っているとき、その開発者はコードに2回現れることも知っています。

500000要件ドキュメント内の複数の場所に表示される他の（同様の可能性が高い）シナリオを考えますが、主題専門家はそのうちの1つのみを変更することを決定します。そこには、const値を変更する誰かが500000異なることを意味するために使用されることに気付かない可能性があるというさらに悪いリスクがあります-したがって、開発者はコード内でそれを見つけた唯一の場所でそれを変更し、彼らが何かを壊すことになります彼らが変わったことに気づかなかった。

このシナリオは、特注の法律/金融ソフトウェア（保険見積りロジックなど）で頻繁に発生します。このような文書を書く人はエンジニアではなく、仕様のチャンク全体をコピーして貼り付け、いくつかの単語/数字を変更しても問題ありませんが、ほとんどが同じままです。

これらのシナリオでは、コピーペーストの要件に対処する最良の方法は、コピーペーストのコードを記述し、コードを要件にできるだけ似たものにすることです（すべてのデータのハードコーディングを含む）。

このような要件の現実は、通常はコピーと貼り付けが長く続くことはなく、値は定期的に変更されることもありますが、多くの場合、それらは並行して変更されないため、これらの要件を合理化または抽象化または簡素化しようとしますいずれにせよ、要件を逐語的にコードに変換するだけでなく、いずれにしてもメンテナンスの頭痛の種になります。

この記事には良い点があります。構成ファイルに定数を抽出することはどのように悪い習慣になりますか？コードを不必要に複雑にするのは悪い習慣です。コードに直接値を設定することは、構成ファイルから値を読み取るよりもはるかに簡単であり、記述されたコードは簡単に理解できます。

さらに、明日、政府は「5/3/2050から、AUTHLDG-1AではなくAUTHLDG-122Bを追加する必要があります」と言います。

ええ、コードを変更します。この記事のポイントは、構成ファイルを変更するよりもコードを変更する方が複雑ではないということです。

この記事で説明されているアプローチは、より複雑なロジックを取得する場合にはスケーリングしませんが、ポイントは判断の呼び出しを行う必要があることであり、場合によっては最も単純なソリューションが単に最良であるということです。

後で必要にならないことをどのように知っていますか？それとも他の誰か？

これがYAGNI原則のポイントです。現在のデザインとはまったく異なる、未知の未来のためにデザインしないでください。値500000がプログラム内の複数の場所で使用されている場合、もちろん定数に抽出する必要があることは正しいです。しかし、これは問題のコードには当てはまりません。

ソフトコーディングは本当に関心の分離の問題です。コアアプリケーションロジックから独立して変化する可能性があることがわかっている情報をソフトコードします。接続文字列をデータベースにハードコーディングすることはありません。アプリケーションロジックとは独立して変更される可能性があり、環境ごとに区別する必要があるためです。Webアプリでは、ビジネスロジックをhtmlテンプレートやスタイルシートから分離するのが好きです。なぜなら、それらは独立して変化し、さらには異なる人々によっても変化する可能性があるからです。

ただし、コードサンプルの場合、ハードコードされた文字列と数字はアプリケーションロジックの不可欠な部分です。制御できないポリシーの変更により1つのファイルの名前が変更される可能性がありますが、別の条件の新しいif-branchチェックを追加する必要があることも同様に考えられます。この場合、ファイル名とファイル番号を抽出すると、実際には凝集性が失われます。

この記事では、「エンタープライズルールエンジン」について説明しますが、これはおそらく彼が主張していることのより良い例です。

ロジックは、構成が複雑になり、独自のプログラミング言語が含まれるポイントまで一般化できるということです。

たとえば、この例のドキュメントマッピングへの状態コードは、構成ファイルに移動できます。しかし、その後、複雑な関係を表現する必要があります。

<statecode id="AZ">
    <document id="SR008-04X"/>
    <document id="SR008-04XI"/>
</statecode>

たぶん、元帳の金額も入れますか？

<statecode id="ALL">
    <document id="AUTHLDG-1A" rule="ledgerAmt >= 50000"/>
</statecode>

すぐに、あなたが発明した新しい言語でプログラミングしており、ソースまたは変更管理のない構成ファイルにそのコードを保存していることがわかります。

この記事は、この種のことが一般的なアプローチであった2007年のものであることに注意してください。

最近は、おそらく依存性注入（DI）の問題を解決するでしょう。すなわち、あなたは「ハードコードされた」でしょう

InvoiceRules_America2007 : InvoiceRules

ハードコード化された、またはより構成可能なものに置き換えます

InvoiceRules_America2008 : InvoiceRules

法律またはビジネス要件が変更されたとき。

それどころか、「500000」は単なる数字ではありません。これは重要な値であり、機能のブレークポイントのアイデアを表しています。この番号は複数の場所で使用できますが、使用している番号ではなく、制限/境界線の概念であり、1つのルールの下に適用され、その上に別のルールが適用されます。

そして、それは次のように表現されます（そして、コメントさえも冗長であると私は主張できます）：

 if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

これは、コードが実行していることを繰り返しているだけです。

LEDGER_AMOUNT_REQUIRING_AUTHLDG1A=500000
if (ledgerAmnt >= LEDGER_AMOUNT_REQUIRING_AUTHLDG1A) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
}

著者は、500000の意味がこのルールに関連付けられていると想定していることに注意してください。他の場所で再利用される、または再利用される可能性のある値ではありません。

この前述のソフトコーディングが考慮できる唯一のビジネスルールの変更は、フォームAUTHLDG-1Aを必要とする元帳金額の変更です。その他のビジネスルールの変更には、構成、ドキュメント、コードなど、さらに多くの作業が必要です。

私の見解では、この記事の主なポイントは、数字は単なる数字である場合があるということです。コードで伝えられること以外に特別な意味はなく、他の場所では使用されない可能性があります。したがって、ハードコーディングされた値を避けるためだけに、コードが何をしているのかを（今）ぎこちなく変数名に要約することは、せいぜい不必要な繰り返しです。

他の答えは正しく、思慮深い。しかし、ここに私の短くて甘い答えがあります。

  Rule/value          |      At Runtime, rule/value…
  appears in code:    |   …Is fixed          …Changes
----------------------|------------------------------------
                      |                 |
  Once                |   Hard-code     |   Externalize
                      |                 |   (soft-code)
                      |                 |
                      |------------------------------------
                      |                 |
  More than once      |   Soft-code     |   Externalize
                      |   (internal)    |   (soft-code)
                      |                 |
                      |------------------------------------

ルールと特別な値がコードの1つの場所に表示され、実行中に変更されない場合は、質問に示されているようにハードコードします。

ルールまたは特別な値がコード内の複数の場所に表示され、実行中に変更されない場合は、ソフトコードします。ルールのソフトコーディングでは、特定のクラス/メソッドを定義するか、Builderパターンを使用します。値の場合、ソフトコーディングは、コード全体で使用される値の単一の定数または列挙を定義することを意味します。

実行時にルールまたは特別な値が変更される可能性がある場合は、それらを外部化する必要があります。通常、データベース内の値を更新することによって行われます。または、ユーザーがデータを入力して、メモリ内の値を手動で更新します。また、ファイル変更日時の変更について繰り返しスキャンされるテキストファイル（XML、JSON、プレーンテキストなど）に値を保存することによっても実行されます。

これは、おもちゃの問題を使用するときに陥り、実際の問題を説明しようとするときに、ストローマンソリューションのみを提示するときに陥るtrap です。

与えられた例では、与えられた値がインライン値としてハードコードされているか、constとして定義されているかどうかに違いはありません。

この例がメンテナンスとコーディングの恐怖になるのは、周囲のコードです。周囲のコードがない場合、少なくとも一定のリファクタリングの環境では、スニペットは問題ありません。リファクタリングが発生しない傾向にある環境では、そのコードのメンテナーはすぐに明らかになる理由ですでに死んでいます。

周囲のコードがある場合は、明らかに悪いことが起こります。

最初の悪い点は、値50000がどこかの別の値に使用されることです。たとえば、州によっては税率が変化する元帳の金額などです。コード内の50000の2つのインスタンス（同じ50kを意味するか、まったく関係のない50ksを意味するか）。また、誰かが定数として使用した場合のために、49999と50001も検索する必要がありますか？これは、別のサービスの設定ファイルでこれらの変数をplonkするための呼び出しではありませんが、インラインでハードコーディングすることも明らかに間違っています。代わりに、それらは定数であり、定義され、使用されるクラスまたはファイル内でスコープされる必要があります。50kの2つのインスタンスが同じ定数を使用する場合、それらはおそらく同じ立法上の制限を表します。そうでない場合は、おそらくそうではありません。いずれにせよ、彼らは名前を持ち、

ファイル名は関数に渡されます-attachDocument（）-パスまたは拡張子なしで、文字列としてベースファイル名を受け入れます。ファイル名は、基本的に、何らかのファイルシステムまたはデータベースへの外部キー、またはattachDocument（）がファイルを取得する場所です。しかし、文字列はこれについて何も教えません-いくつのファイルがありますか？どのような種類のファイルですか？新しい市場に参入するときに、この機能を更新する必要があるかどうかをどのように知っていますか？どのような種類のものに取り付けることができますか？メンテナーは完全に暗闇の中に残されており、彼が持っているのは文字列だけです。これはコードに複数回現れ、出現するたびに異なることを意味する場合があります。ある場所では、「SR008-04X」はチートコードです。別の例では、SR008ブースターロケットを4個注文するコマンドです。ここでは、saファイル名？これらは関連していますか？誰かがその関数を変更して、別のファイル「CLIENT」に言及しました。それから、あなたは、貧弱なメンテナーで、「CLIENT」ファイルの名前を「CUSTOMER」に変更する必要があると言われました。しかし、「CLIENT」という文字列はコード内で937回表示されます...どこから探し始めますか？

おもちゃの問題は、値がすべての異例であり、合理的にコード内で一意であることを保証することができるということです。「1」または「10」ではなく「50,000」。「クライアント」または「レポート」ではなく、「SR008-04X」。

strawmanは impenetrably不透明定数の問題に対処するための唯一の他の方法は、いくつかの無関係なサービスの設定ファイルにそれらをオフハイブにあるということです。

一緒に、これらの2つの誤りを使用して、任意の引数が正しいことを証明できます。

これにはいくつかの問題があります。

1つの問題は、プログラム自体の外ですべてのルールを簡単に構成できるようにルールエンジンを構築する必要があるかどうかです。これに似た場合の答えはほとんどの場合ノーです。ルールは予想しにくい奇妙な方法で変更されるため、変更があるたびにルールエンジンを拡張する必要があります。

別の問題は、これらのルールとバージョン管理での変更の処理方法です。ここでの最善の解決策は、ルールを各ルールのクラスに分割することです。

これにより、各ルールに独自の有効性を持たせることができ、一部のルールは毎年変更され、一部の変更は許可が与えられたときまたは請求書が発行されたときに依存します。適用する必要があるバージョンのチェックを含むルール自体。

また、定数はプライベートであるため、コードの他の場所で悪用されることはありません。

次に、すべてのルールのリストを作成して、リストを適用します。

さらなる問題は、定数の処理方法です。500000は目立たないように見えますが、正しく変換されるように細心の注意を払う必要があります。浮動小数点演算を適用すると、500,000.00001に変換される可能性があるため、500,000.00000との比較が失敗する可能性があります。さらに悪いことに、500000は常に意図したとおりに機能しますが、変換すると565000が何らかの理由で失敗します。変換が明示的であり、コンパイラーの推測ではなく、ユーザーによって行われていることを確認してください。多くの場合、これは使用前にBigIntegerまたはBigDecimalに変換することで行われます。

質問では直接言及されていませんが、重要なことはビジネスロジックをコードに埋めないことです。

コード、上記の例のように、それがコードして外部から指定されたビジネス要件が本当におそらくという名前のソースツリー、別個の部分に生きるべきbusinesslogicか、似たような、そしてケアは、それがいることを保証するように注意しなければならないだけ単にビジネス要件をエンコードし、読み出し可能と最小限の定型文と明確で有益なコメントを付けて、できるだけ簡潔に。

たとえば、この例のメソッドの実装などのビジネスロジックを実行するために必要な機能を実装する「インフラストラクチャ」コードや、一般的なUI、ロギング、データベースコードなどと混合しないでください。一方で1つの分離を強制する方法は、「ソフトコード」の設定ファイル内のすべてのビジネス・ロジックであり、これははるかにだけ（または最高）メソッドからです。attachDocument()

このようなビジネスロジックコードは、コーディングスキルのないビジネスドメインの専門家に見せた場合に理解できるように、十分に明確に記述する必要があります。少なくとも、ビジネス要件が変更された場合、それらをエンコードするコードは、コードベースに慣れていない新しいプログラマーでも、ビジネスロジックを簡単に見つけ、レビューし、更新できるように十分に明確でなければなりません。定性的に新しい機能は必要ありません。

理想的には、このようなコードはドメイン固有の言語で記述され、ビジネスロジックと基盤となるインフラストラクチャの分離を強制しますが、基本的な社内アプリでは不必要に複雑になる場合があります。つまり、たとえば、それぞれが独自のビジネスルールのカスタムセットを必要とする複数のクライアントにソフトウェアを販売している場合、単純なドメイン固有のスクリプト言語（たとえば、Luaサンドボックスに基づいているなど）だけで十分かもしれません。