6

当社の製品は、Web ベースのコース管理システムです。10社以上のお客様を抱えており、今後さらに多くのお客様を獲得する可能性があります。(Asp.net、SQL Server)

現在、お客様が追加の機能やカスタマイズされたビジネス ロジックを必要としている場合、必要に応じてデータベース スキーマとコードを変更します。

(1 つのブランチ コード ベースと 1 つのデータベース スキーマしかありません)

変更が他のルートに影響を与えないようにするために、Web 構成ファイルで定義されたクライアント フラグを使用するため、これらの追加フィールドとビジネス ロジックは特定の顧客のシステムにのみ適用されます。

if(ClientId = 'ABC')
{
   //DO ABC Stuff
}
else
{
   //Normal Route
}

私たちの上級同僚の 1 人は、このようにして、私たちのような小さな会社は、複数のリソースをサポートすることでリソースを節約できると言いました。

しかし、私が感じているのは、この戦略により、コードとデータベースの保守がさらに困難になるということです。

誰かが同様の状況を超えましたか？それをどのように処理しますか？

更新:これがSOにとって適切な質問でない場合、誰かがこの質問を適切なstackexchangeサイトに移動できますか?

Update2 : その通りです。コードは今や臭くなってきており、遅かれ早かれ悪夢になることは間違いありません。当社は製品を製造しており、労力を節約するために、他の顧客向けの後の製品は以前の製品に基づいています。理想的な方法は、@ej-brennan 開発チームを 2 つの部分に分けることです。1 つのチームはコア製品に取り組み、高度なカスタマイズを可能にしました。チーム 2 は、特定のクライアント向けのカスタマイズに取り組みます。しかし、当社はとても小さいので、それは本当にジレンマな状況です。:(

4

3 に答える 3

6

クライアントごとに調整するカスタムソフトウェアを販売するか、それともフリーサイズの（そしておそらく提供する機能を通じてカスタマイズ可能な）「既製の」ソフトウェアを販売するかを決定する必要があると思います。

現在のようにほんの一握りのクライアントしかいない場合は、あなたがしていることをやり遂げることができますが、この道を歩み続ければ、クライアントベースが増加し、クライアント固有のカスタマイズの量が増加することはほぼ保証できます.同様に、あなたは悪夢に見舞われるでしょう。私は複数のクライアントに対してこれを何度も経験しましたが、いつも同じように終わります。それがなくなるまではすべて対処可能ですが、それからそれはあなたの人生を実際に非常に困難にする可能性のある王室の首の痛みです.

あなたがカスタム会社であり、ソフトウェアとデータベースの複数のバージョンを持ちたいと決めた場合、それは問題ありません。そのための全費用を請求するようにしてください。つまり、複数レベルのソースコードを維持する必要があるかもしれないことを考慮してください。また、各クライアントのコード ベースをテストする必要があるため、アップグレードをロールアウトするには何倍もの労力がかかることを考慮してください。

「既製」タイプの製品になりたいと判断した場合、最善の策は、各クライアントがコードを変更せずにエクスペリエンスをカスタマイズできる機能を提供することです。つまり、構成を通じてカスタマイズ機能を組み込みます。物事がどのように機能するかを制御する画面とテーブル - しかし、誰もが同じ基礎となるコードとデータベースを引き続き使用します。前もってより多くの作業を行いますが、その後の時間を大幅に節約できます。

于 2012-09-04T15:52:18.257 に答える
4

私もあなたの立場にありましたが、それは難しいことだと思います。私の場合、クライアント向けのカスタムの単一製品サイトを構築していました。各サイトは同様のレイアウトとワークフローに従っていましたが、それぞれが完全にカスタム設計、配送とクーポンに関するカスタム ルール、および異なるマーチャント ゲートウェイと構成を持つために十分な柔軟性が必要でした。

数年後、私たちは保守可能なものにたどり着きました。まず、すべての共通コードを格納するライブラリを作成し、これらのライブラリを単純に Common と呼ばれる TFS プロジェクトに配置しました。次に、サイトごとに新しい TFS プロジェクトを作成し (多くのクライアントは複数の製品/サイトを持っていたため、クライアントではありません)、該当するプロジェクトを Common からそれらに分岐しました。次に、「デザインのない」ビュー、コントローラー、およびそれらのアクション メソッドを含む、サイトのスケルトンを含む VS テンプレート プロジェクトを作成しました (各サイトの基本フローは同じであることを思い出してください)。また、各サイトは独自のデータベースで実行されていました。このデータベースは、使用されていないほとんど空のテンプレート DB から複製されました。

各サイトが独自のブランチと DB で実行されているため、他のサイトに影響を与えることなく、テンプレートによってインストールされた元のフローと設計に変更を加えることができました (マージして戻す必要はありません)。送料計算などのビジネス メソッドをカスタマイズするために、共通クラスのサブクラスを作成し、必要に応じてオーバーライドすることができます。これを可能にしたのは、依存性注入を使用するようにすべてのコードを変換したことです。具体的には、各コントローラにサービスが注入され、各サービスにリポジトリが注入されました。Merchant Processing もインターフェイスにコーディングされ、注入されました。また、言及する価値があるのは、これにより、各サイトのすべてのアップセル ロジックをハードコーディングできることです (製品 X を購入したので、Y をお勧めします)。これは、古いアップセル ルール エンジンで複雑な構成ルールを定義するよりも、作成と維持がはるかに簡単でした。あなたにそんなものがあるかどうかはわかりませんが...

ときどき、共通コード自体に変更を加えたいと思うことがありますが、これは通常、特定のサイトの特定の必要性によって促されました。その場合、そのブランチで変更を行い、Common にマージしてから、都合のよいときに他のサイトにマージします (「重大な」変更または DB への変更も必要な変更に最適です)。同様に、DB の変更については、テンプレート DB を更新してから、他のサイト DB を同じスキーマ変更で更新するための小さなスクリプトを記述します (それでも、賢く慎重に行う必要がありました)。

追加の利点は、「デザイン」ビルド構成で使用/挿入されるモック リポジトリも作成したことです。これにより、デザイナーは、文字通りワークフローに自分自身を送信することなく、アプリケーションをジャンプして画面上で作業できるようになりました。また、バックエンドで何かが行われる前にサイトでの作業を開始することもできました。これは、「何かを見る」必要がある不安なクライアントにとって非常に重要でした.

10 人以上のクライアントは、あなたが話していることを考えると決して少数ではありません。3つでも十分苦痛でした。一度に 30 以上のサイトを運営し、3 人の開発者と 2 人のデザイナーが管理していました。

最後に、それがあなたの質問の範囲外であり、少しおこがましいことは承知していますが、デザイナーが実際に実装を開始する前に (そして開発者が作業を行う前に)、デザインに関する「最終的な」クライアント サインオフを取得することで、多くの費用を節約できました。やり直し。最終的な設計はないことは承知していますが、実装側の効率を高めることで、クライアントが承認した設計について考えを変える時間が少なくなりました。

少なくとも、考えるためのいくつかのアプローチが得られることを願っています。

于 2012-09-04T18:27:59.623 に答える
3

変更またはカスタマイズが必要なシステムで作業する人々は、そのような問題を処理するためのパターンを開発しました。

Inversion of Control に関する優れた本を読むことから始めるべきです。つまり、構成要素 (インターフェイスとして表現されるコントラクト) を定義してシステムを構築し、複数の実装を提供できます。このようなアプローチには複数の利点がありますが、2 つだけ言及すると、 - 同じインターフェースの異なる実装を提供することでカスタマイズを処理できます - アプリケーションを静的または動的に再構成できますが、どちらのアプローチも「if」よりもはるかにクリーンです。

データ層に関しては、リポジトリ パターンを調べてください。異なるプロバイダー間で切り替えることができる方法でデータ アクセスを整理するのに役立ちます。iocによく合います。

技術的なヒントとして、nhibernate は動的プロパティをサポートしています。マッピングに追加の列を提供するだけで、nh は同じコード ベースからそれをサポートできます。このようにして、db スキーマがわずかに異なるさまざまなデータベースをターゲットにすることができます。

于 2012-09-04T15:54:27.643 に答える