問題タブ [code-reuse]

私たちは、さまざまな顧客 (多くのさまざまなプロジェクトに含まれています) に販売したブログ システムを持っています。このシステムには、いくつかの aspx ページ、1 つまたは 2 つの ascx コントロール、1 つの css ファイル、1 つの javascript ファイル、およびいくつかの分離コード/vb.net ユーティリティ ファイルなど、さまざまなファイルが含まれています。一般に、このモジュールの 90% 以上は顧客間で同じですが、もちろんすべての顧客は、表面的な html/css の変更からサーバー/クライアント ロジックの微調整まで、何らかのカスタマイズを望んでいます。

現在、ブログ システムを新しいプロジェクトに展開するには、ファイルを (最後に作業したプロジェクトから) コピーし、必要に応じてファイルをカスタマイズするだけです。しかし、今では、ブログ システムの一意で互換性のないコピーが 10 個あります。各プロジェクトでブログ システムを機能させるだけでも、かなりの時間がかかります。また、新しいブログ システムから古いシステムやメンテナンスに改善を広めることは、本当に頭の痛い問題です。

理想的には、一般的なケース (90%) に対応するブログ システム ファイルの単一の「ゴールデン コピー」が必要です。そのゴールデン コピーを新しいプロジェクトに追加して、ブログ システムをほぼ瞬時に動作させることができますが、必要に応じてファイルを追加またはカスタマイズすることもできます。さらに良いことに、「ゴールデン コピー」に改良を加えると、これらの変更をすべてのサイトに簡単に展開でき、お客様のために行ったカスタマイズを尊重します.

新しい css ファイルを追加してベース クラスを変更し、ベース サーバー側のロジックをオーバーライドする新しい vb.net クラスを追加できることはわかっていますが、aspx、ascx、および js ファイルを処理する方法が本当にわかりません。 理想的には、ファイル ベースまたはソース セーフなソリューションを見つけることができます。たとえば、カスタマイズされた新しいファイルが存在する場合、ゴールデン ファイル内の対応するマークアップ/js/etc を自動的にオーバーライドします。 もちろん、私たちはすべてのソリューションに対してオープンです。これは非常に一般的なシナリオのように思われるため、誰かが「ベスト プラクティス」を開発してくれることを期待していました。私が説明していることは可能ですか？アドバイスや指示をいただければ幸いです。よろしくお願いします。

シェーン

多くのjavascriptとcssが添付されたユーザーコントロール(ユーザー詳細フォーム)があります。特定のファイルが必要であることをコントロールに宣言するのに苦労しているため、htmlの「ヘッド」セクションに含まれます。

また、コントロールの複数のインスタンスを入力するとどうなるのだろうか (これは InamingContainer または類似のものではありません)。

数年前、私は会社で Web 開発者として働くことになりました。私の最初の Sirius Web 開発の仕事 (ASPx/C#) があるので、非常にエキサイティングで、開発者の観点からその世界について多くのことを学びました。

そのグループでは、ページ UC (ユーザー コントロール) に読み込まれるページの概念がありました。すべての言語のすべての Web 開発チームで同じであるかどうかはわかりませんが、そうであると仮定します。

契約が終了し、win32 の「winForm」アプリケーションを開発するために戻ってきました。

しかし、それら以来、私はそこで学んだwin32開発に同じ原則を適用しようとしました。つまり、フォームにロードするUC（ビジュアルユーザーコントロール）の束を持つことを意味します。これらは通常のビジュアル コンポーネントであり、ツールボックスに読み込まれず、コードはプロジェクトで使用できますが、コンポーネントはフォームで開発されず、そこに読み込まれます。

このアプローチについての意見、これと同様またはそれ以上に行っていること、および開発をスピードアップし、コードの再利用を増やすのに役立つ改善について知りたいです。それがすべてです。

私は Django で最初のサイトを作成しようとしています。そこからインスピレーションを得るサンプルアプリを探していると、「再利用可能なアプリ」と呼ばれる用語に常に出くわします。

再利用可能なアプリの概念は簡単に理解できますが、Django でアプリを再利用する方法は、私にとってはまったくわかりません。ビジネス全体で私を悩ませているいくつかの質問は次のとおりです。

既存の Django アプリを再利用するための推奨される方法は何ですか? どこに置き、どのように参照するのですか？

私が理解していることから、「PYTHONPATH」に配置することをお勧めしますが、アクセスが制限されているリモートの場所（ホスティングサービスなど）にアプリをデプロイする必要があるとすぐに壊れます。

したがって、ローカル コンピューターでサイトを開発し、ftp アクセスしかできない ISP に展開する場合、サード パーティの Django アプリを再利用して、サイトを展開してもサイトが機能し続けるようにするにはどうすればよいですか (たとえば、私が信頼できる唯一のことは、サービス プロバイダーに Python 2.5 と Django 1.x がインストールされていることです)。

Django プロジェクトを整理して、使用したいすべての再利用可能なアプリと一緒に簡単に展開できるようにするにはどうすればよいですか?

大量の PHP ファイルを含むディレクトリを反復処理し、各ファイルで定義されているクラスを検出しようとしています。

次の点を考慮してください。

上記の$php_files_and_content変数は、キーがファイル パスであり、内容がファイルのソース コードであるイテレータを表します (例から明らかではなかったかのように)。

これは、ソース コードで定義されているすべてのクラスに一致する別のイテレータ ala に提供されます。

が数値的に連続していない理由$indexは、'クラス C' が 2 番目のソース コード ファイルで定義されているためです。したがって、返される配列は再びインデックス 0 から始まります。これは RecursiveIteratorIterator に保持されます。これは、結果の各セットが個別の Iterator (したがって、キーと値のペア) を表すためです。

とにかく、私が今やろうとしているのは、これらを組み合わせる最良の方法を見つけることです。新しいイテレータを反復処理するときに、キーが ($defined_classesイテレータからの) クラス名であり、値が元のファイル パスであることがわかります。 、あら:

そして、それが私がこれまで立ち往生しているところです。

現時点で考えられる唯一の解決策は、新しい RecursiveIterator を作成することです。これは current() メソッドをオーバーライドして外側のイテレータ key() (元のファイルパス) を返し、key() メソッドを返して返します。現在の iterator() 値。しかし、次の理由から、私はこのソリューションを支持していません。

• 複雑に聞こえます (つまり、コードが見苦しく、直感的ではないということです)。
• ビジネス ルールはクラス内にハードコーディングされていますが、私はいくつかのジェネリック イテレータを定義し、それらを組み合わせて必要な結果を生成できるようにしたいと考えています。

アイデアや提案はありがたく受け取りました。

これを行うためのはるかに高速で効率的な方法があることも認識していますが、これは自分自身のためにイテレーターを使用する練習でもあり、コードの再利用を促進する練習でもあります。したがって、作成する必要がある新しいイテレーターはできるだけ最小限に抑える必要があります。既存の機能を活用してみてください。

ありがとう

さまざまなビジネス ロジック、アプリケーション層、Web サービス、および WCF コントラクト間で共有される非常に多数の階層構造 (または DTO) があります。すべてのコードをリファクタリングして、構造を個別のビジネス ドメイン領域に分割したいと考えています。

2 つの質問:

1. これを行うのに役立つツールはありますか (クラス A が必要な場合は、すべての依存関係をリストします)。

2. 異なるアプリケーション ドメインで DTO を複製して、それらが独立して進化できるようにするケースはありますか? 固定された正規のビジネス モデルのアイデアは、まったくのフィクションです。

私が取り組んでいるプロジェクトの範囲は拡大中です。アプリケーションはかなり単純ですが、現在は非常に特定のニッチをターゲットにしています。近い将来、私はプロジェクトをフォークして新しい市場をターゲットにし、2 つのプロジェクトを並行して開発し続けるように依頼されました。

両方のプロジェクトは機能的に類似しているため、元のプロジェクトの根幹の多くを一般化する非常に強いインセンティブがあります。また、近い将来、より多くの市場をターゲットにしていると確信しています (市場は地理的なものです)。

問題は、プロジェクトの以前のメンテナーが、プロジェクトを元の市場に結び付ける多くの仮定を行ったことです。汎用コードを市場固有のコードから分離するには、かなりのリファクタリングが必要です。

物事をより複雑にするために、増え続ける市場のプロジェクトをどのように編成するかについて、いくつかの提案が飛び交っています。

1. 各市場は個別のプロジェクトであり、プロジェクト間の共通点は共有ライブラリに移動され、プロジェクトは個別に展開されます。
2. 既存のプロジェクトを拡張して複数の市場をターゲットにし、購入したライセンスに基づいて機能を制限します。
3. 親アプリケーションを作成し、個別に購入したプラグインとしてプロジェクトを再設計します

3 つの提案にはすべてメリットがあります。理想的には、コードを柔軟に構成して、わずかな調整でこれらのいずれかを実行できるようにしたいと考えています。提案 3 は、プラグイン アーキテクチャを構築する必要があるため、最も困難なようです。最初の 2 つの提案は、もう少しもっともらしいです。

これらの異なるアーキテクチャの長所と短所について利用できる適切なリソースはありますか?

プロジェクト間でコードを共有することと、コピーとフォークを比較することの長所と短所は何ですか?