複雑さをいつ除去すべきか？

設計パターンが必要になる前に実装することにより、時期尚早に複雑さを導入することは良い習慣ではありません。

しかし、すべての（またはほとんどの）SOLIDの原則に従い、共通の設計パターンを使用すると、機能と要件が追加または変更され、設計が必要に応じて保守可能かつ柔軟に維持されるため、多少の複雑さが生じます。

しかし、その複雑さが導入され、チャンピオンのように機能するようになったら、いつそれを削除しますか？

例。クライアント用に作成されたアプリケーションがあります。元々従業員に昇給を与えるいくつかの方法がある場所で作成されたとき。戦略パターンとファクトリーを使用して、プロセス全体をきれいに保ちました。時間が経つにつれて、アプリケーション所有者によって追加または削除される特定のraiseメソッド。

時間が経ち、新しい所有者が引き継ぎます。この新しい所有者は頑固で、すべてをシンプルに保ち、昇給する方法は1つしかありません。

戦略パターンに必要な複雑さはもはや必要ありません。現在の要件からこれをコーディングする場合、この余分な複雑さは導入しません（ただし、必要に応じてほとんど、またはまったく作業をせずに導入できることを確認してください）。

戦略の実装を今すぐ削除しますか？この新しい所有者が昇給の方法を変えることはないと思います。しかし、アプリケーション自体は、これが起こる可能性があることを実証しています。

もちろん、これは新しい所有者が引き継ぎ、多くのプロセスを簡素化したアプリケーションのほんの一例です。数十のクラス、インターフェース、ファクトリーを削除し、アプリケーション全体をよりシンプルにすることができました。現在の実装は正常に機能し、所有者はそれで満足していることに注意してください（そして、議論された複雑さのために、私は彼女の変更を非常に迅速に実装できたことに驚き、そしてさらに幸せです）。

この疑いのほんの一部は、新しい所有者が私をもう使用しない可能性が高いためです。大きな収入源ではないので、他の誰かがこれを引き継ぐことを本当に気にしません。

しかし、私は2つの（関連する）ことを気にします

1. コードを理解しようとするとき、新しいメンテナーが少し難しく考える必要があることに少し気を配ります。複雑さは複雑さであり、私に続く心理マニアを怒らせたくありません。

2. しかし、競合他社がこの複雑さを認識し、仕事に時間を費やすためにデザインパターンを実装するだけだと考えていることをさらに心配しています。次に、この噂を広めて、他のビジネスを傷つけました。（私はこれが言及されたと聞いています。）

そう...

一般に、以前は必要だった複雑さは、それが機能し、複雑さに対する歴史的に実証された必要性があったとしても削除されるべきですが、将来必要になるという兆候はありませんか？

上記の質問が一般的に「いいえ」と回答されたとしても、プロジェクトを競合他社（または見知らぬ人）に引き渡す場合、この「不要な」複雑さを取り除くことは賢明でしょうか？

ある意味では、これは主にビジネス上の決定であり、必ずしもコード自体に基づいているわけではないと思います。考慮すべき事項：

• 変更を行うための支払いを受けていますか？
• 現在、コードは期待どおりに機能していますか？
• コードにセキュリティまたはパフォーマンスの問題はありますか？
• 技術的負債の額は、それを修正するコストを上回っていますか？
• コードをそのままにしておくと、現実的に何が起こる可能性がありますか？
• リファクタリングの有無にかかわらず発生する可能性のある将来の問題は何ですか？
• あなたとあなたのビジネスに対するコードの責任はどれくらいですか？

あなたはこれらの質問に答えるのに最適な立場にいます。しかし、あなたの説明に基づいて、リファクタリングと単純化を煩わせるかどうかはわかりません。時間の価値があるとは思えないからです。現在動作している場合、クライアントは満足しているので、すべてを更新するための支払いを受け取りたくない場合は、それを許可して収益を上げる活動に取り組みます。

要するに、両方の経路の費用便益分析とリスク評価を行い、最も安全で、最も効率的で、最も収益性の高い行動を取ります。

このコードを削除して、クライアントが考慮して料金を支払う必要のある機能を将来コーディングしやすくするために、単純なものに置き換えないのですか？

他の開発者が学ぶことができる何か有用なものがあるかもしれませんが、プラグインする別のクライアントのアプリを見つける可能性は低いでしょう。

競合他社のコードについてうわさは、あなたが防ぐことができるものではありません。彼らはクライアントを否定的にリクルートしようとして愚かに見えるでしょう。

一般的な言い回しは、「壊れていない場合は修正しないでください」です。

このルールの背後にはいくつかの理論的根拠があります。それらのいくつかは、「単純化」が新しく、異なる、おそらくより大きなバグを導入するリスクを負い、他のより価値のある努力から開発時間を延ばす可能性があり、予期しない将来のビジネスチャンスのための完全に間違った変更である可能性があります発生します。

このコードの移植性と保守性を高めるのに十分なビジネス価値がある場合は、その値が現在のコードが「壊れている」と考えるのに本当に十分かどうかを判断します。大規模なビジネスの拡大が計画されている場合、またはビジネスをダウンさせる可能性のある複雑さに潜んでいる潜在的なバグが疑われる場合、それは多分可能性があります。

まず、アプリが新しい所有者に既に引き継がれている場合、再び発生する可能性があります。そして、次の所有者は、その恩恵を受けていない複雑さを再び使い始めるかもしれません。

これとは別に、作業コードの重要な変更は常にリスクを伴うため、クライアントは（他の人が述べたように）それらに同意（および支払い）する必要があります。現在の「余分な」複雑さが目立って測定可能な欠点（パフォーマンスの問題など）を引き起こさない場合、それを削除する強力な理由はありません。

（潜在的な）競合他社の噂だけに基づいてあなたを雇う（しない）クライアントは、あなたが収入を必死に必要としているのでなければ、とにかく持つ価値はありません。アプリを自分のやり方で実装したのは、論理的で正当な理由があり、真面目なクライアントなら誰でもそれを理解するでしょう。そうしない人、またはあなたに質問する気さえない人は、とにかく仕事の価値よりもあなたに多くのトラブルを引き起こす可能性があります。

一般に、以前は必要だった複雑さは、それが機能し、複雑さに対する歴史的に実証された必要性があったとしても削除されるべきですが、将来必要になるという兆候はありませんか？

番号。

上記の質問が一般的に「いいえ」と回答されたとしても、プロジェクトを競合他社（または見知らぬ人）に引き渡す場合、この「不要な」複雑さを取り除くことは賢明です。

いいえ。なぜこのように優先度の低い作品を修正するのに時間を浪費するのですか？そこに残っているコードに害はありません。

あなたの質問に関して：複雑さはいつ除去されるべきですか？

私の意見は、それが壊れていなければ、それを直さないことです。

複雑さを取り除くには、次の条件が満たされている必要があります。

1. 削除されたピースは、プログラムから独立している必要があります。周囲のプログラムから問題のコードへの依存関係がある場合、複雑さを取り除くだけでは機能しません
2. 残念ながら、複雑に見える場合は、ピースが独立していない可能性が高く、ピースを削除すると依存関係によってプログラムが破損する可能性があります
3. すべての依存関係を削除するには時間がかかるため、操作に労力を費やす価値があるかどうかを見積もる際には、時間を考慮する必要があります。
4. ほとんどの場合、努力する価値はありませんが、新しいコードで古いコードを使用しないようにするだけです。

ここにはもっと大きな仕事があると思います...スケーラビリティ

あなたが話していることはスケーラビリティと呼ばれます。コーディングが複雑であるかどうかは関係ありません。アプリケーションが新しいビジネスルールに基づいて進化できるか、変更されたビジネスルールに基づいて進化できるかは重要です。次の所有者がまったく異なるものを望んでいる場合はどうなりますか。

だから、私はコードを保持し、それを文書化すると言います。これは、アプリケーションの利用方法の特徴です。

一般に、以前は必要だった複雑さは、それが機能し、複雑さに対する歴史的に実証された必要性があったとしても削除されるべきですが、将来必要になるという兆候はありませんか？

複雑さを取り除く努力とリスクがあります。追加の労力と過度に複雑なコードを維持するリスクよりも高い場合は、それを維持します。それ以外の場合は、削除します。ただし、これらのリスクを見積もることは困難です。

コードで最初に設計パターン戦略を使用した理由を文書化することにより、より困難なメンテナンスのリスクを軽減できることを付け加えます。私は個人的に、デザインパターンは明示的な要件（機能的または非機能的）にトレーサブルであるべきだと考えています。

上記の質問が一般的に「いいえ」と回答されたとしても、プロジェクトを競合他社（または見知らぬ人）に引き渡す場合、この「不要な」複雑さを取り除くことは賢明でしょうか？

パディング時間の競争に悩まされるあなたのシナリオは、まさに複雑さを文書化する必要がある理由です。パターンの使用を文書化し、（特定の顧客要件で）正当化する場合、あなたはカバーされます。顧客の要件でパターンを正当化できない場合、過剰設計またはパターン炎のように見えます。

要件が変更された場合、コードを壊すリスク（またはパターンを外科的に除去するための作業量）があるため、要件をそのままにしておくことができます。

パターンはしばしば両方を伴うため、偶然の複雑さと本質的な複雑を区別するのは良いことだと思います。

つまり、レイズを決定するためのさまざまなアルゴリズムをサポートするための要件は、本質的な複雑さです（解決すべき問題の一部）。コードのメンテナンスは戦略パターンによって簡単になりますが、ハードコードされたif / then戦略の代替は引き続き機能します。私は修士課程で演習を行い、学生はオープンソースプロジェクトに戦略を適用する機会を見つけました。戦略を適用するとき、複雑さは必ずしも良くも悪くもありません（本質的な複雑さのため）。コードは、1つの大きなif / then / elseブロックではなく、多態性を持つ複数のクラスに分割されるため、Strategyを理解するのがさらに困難になる場合があります。

理想的には、パターンが提供するメリットが欠点のコストを上回る場合に機能します。繰り返しますが、これらのことを定量化することは困難です。多くの場合、パターンは開発者を幸せにします（新しいレイズ戦略を追加するのが簡単になるだけでなく、パターンが適用されたことを知るために開発者に暖かいあいまいさを与えます）。お客様にどのように利益をもたらすかを示すのは難しいです。

顧客は詳細を気にかけず、理解すらしません。新しい所有者がKISSをプロセスに適用する場合、ソフトウェアソリューションに影響を与える可能性のある本質的な複雑さを軽減します。