web-dev-qa-db-ja.com

不均一な保守性に関連する用語は何ですか？

開発者は、多数のレコードを反復処理し、各レコードに通知を送信するサービスを作成する必要があります。通知のタイプはレコードごとに異なる可能性があるため、次のようなロジックを想像できます。

switch (record.DeliveryPreference)
{
    case "email": SendEmail(record); break;
    case "sms": SendSms(record); break;
}

開発者は、いつか他の配信方法がある可能性があると判断したため、ケース/スイッチを削除し、代わりに構成のみを介して配信方法を追加できるようにしたいと考えています。

<DeliveryMethod type="Company.Channels.Plugins.Sms.SmsClient, Company.Channels.Plugins.Sms.Library" />
<DeliveryMethod type="Company.Channels.Plugins.Email.EmailClient, Company.Channels.Plugins.Email.Library" />

...次に、タイプメタデータ（別名Reflection）を使用して新しい配信方法を検出し、それらを自動的に使用します。

構成を介して新しいDeliveryMethodを追加する機能はover設計されているため、これは非公式に「不均一な保守性」と呼ばれる問題だと思います。

なぜそれは過剰設計されているのですか？さて、会社が新しい配送方法を導入しようとすると、それは大きなプロジェクトになります。資金を調達し、プロバイダーを調達し、接続を確立し、プロキシとファイアウォールを開き、新しい接続を使用するコードベースを作成する必要があります。迅速で簡単なものになる方法はありません。そこで、ここで開発者はこの複雑さをすべて追加して、500時間のプロジェクトから30分のコーディングを節約できるようにしました。これはほとんどメリットがないようです。

一方、追加の複雑さは実際には有害である可能性があります。通常の理由で、不必要な複雑さは有害です。しかし、特に1つの理由が私には際立っています。開発者がシステムパラメータを簡単に指定できる場所として実際に構成を使用する代わりに、システムが機能するために一連の魔法の文字列を含む必要があるドキュメントになりました。すべての設定ファイルは常に同じように見え、1文字がずれていると、問題が発生します。情報理論の観点からは、構成ファイルの割合が equivocation に増加したと言えます。これは、情報コンテンツがダウンしたことを意味します。

別の種類の例えでは、他のすべての厚板が剛性または柔軟性のある厚板で構成される橋を視覚化します。その結果、剛性も柔軟性もありませんが、全体的に弱いブリッジになります。

私は例や長所と短所などを続けることができますが、それは意見に基づくものであり、この質問のポイントではありません。 「役に立たない柔軟性」や不均一な保守性の概念を扱う用語や工学の原則を探しています。

designarchitectureprogramming-practicesmaintainability
2
John Wu

彼がそれを作ったとき、私たちは開発者の頭にはいません：

  • 余計な時間がかからなかったので、それだけの価値があると思っていたかもしれません。
  • 彼はまた、ダミーの実装を提供することにより、テスト時にSMS /電子メール送信を無効にする方法を必要とする可能性があります。

しかし、私はあなたの観点から2つの異なる問題を見ています：外部設定とそれがどのように実装されたかです。

最後に、開発者が自分のやり方を考えたとき、適切な分析に時間をかけていなかった可能性があるため、最も自然な方法を選択しました。

そして、どのように名前を付けるのですか？それはアプリケーションのグローバルな状態に依存します。

前に言った仮説だけを見て検討するのであれば、このオーバーエンジニアリングを内部プラットフォームと呼ぶことはありません。私を悩ませた唯一のことは、彼がこの種のもののためのより良いツールを使用する代わりにリフレクションを使用したという事実です。

このように、私たちが名前を付けたいものは何でもそれについての私たちの見解に依存します、そして明らかにそれはただの意見です。

1
Walfrat