問題タブ [organization]

アイテムを新しい名前空間にさらに分類する前に、特定の名前空間にいくつのクラス、インターフェースなどを入れる必要があるかについて、一般的な経験則はありますか? ベスト プラクティスやコミュニティの好みは？それとも、これはすべて個人的な好みですか？

または

Delphi 用または IDE 統合による汎用用の優れたコード スニペット アプリケーションはありますか? コード、クエリ、メモなどを保存したいと思います..

ありがとう

約 50 のフォームを持つビルド中の Web アプリがあります。

これらのフォームの作成と送信を非常にうまく処理する非常に優れたフォーム構築クラスがあり、エラーハンドラーなどでラップされています。ヘルプは必要ありません。

ただし、フォームは 120 ページにわたって散らばっています。これらのページ/フォームの理想的な組織構造について、皆さんからの意見を参考にすることができます. ここにいくつかのアイデアがあります。どちらにも長所と短所があります。

1. 各ページのヘッダーでフォームが作成され、$_POST['action'] 変数の存在が検出され、そこでフォームが処理されます。

2. 各フォームはフォーム関数ファイル内の関数によって構築され、ページのヘッダーで呼び出されたときにフォーム オブジェクトを返します。処理時には、$_POST はスーパーグローバルであるため、ページのヘッダーでも処理関数が呼び出されます。 .

3. profile.php などの各ページについて、上記の方法 #1 または #2 が発生する profile.forms.php を含むヘッダーにファイルを含めます。

アイデア？

1 ページに複数のフォームが存在することはめったにありません。

Visual Studio 2008 でメソッドをアルファベット順に並べ替えるためのプラグインやツールはありますか? 理想的には、自動またはオンデマンドで、選択または指定されたタイプ (つまり、メンバー変数ではなくメソッドのみ) をアルファベット順に並べ替えるツールが必要です。

I'm just wondering what other developers have done in this area.

What does your organization do to get a hierarchical view of your reporting structure? Did you write something custom or use shrink-wrapped tool? How have you integrated that with other internal tools?

私は DDD について学び始めたので、他の人がどのようにプロジェクトを編成したか知りたいと思っていました。

AggregateRoots を整理することから始めました。

MyApp.Domain (ドメイン モデルの名前空間)

MyApp.Domain.Product
- 製品
- IProductService
- IProductRepository
- など

MyApp.Domain.Comment
- コメント
- ICommentService
- ICommentRepository
- など

MyApp.Infrastructure
- ...

MyApp.Repositories
- ProductRepository : IProductRepository
- など

これで遭遇した問題は、ドメイン製品を MyApp.Domain.Product.Product または Product.Product として参照する必要があることです。また、製品の linq データ モデルと競合します....MyApp.Domain.Product.Product と MyApp.Respoitories.Product などの 2 つを区別するために、醜いコード行を使用する必要があります。

他の人がどのように DDD のソリューションを構成しているかを知りたいです...

IDE として Visual Studio を使用しています。

どうもありがとう。

先日、同僚と、開発組織にソフトウェア ファクトリを実装することと、アクティブ レコードのような足場ソリューションを使用することの類似点について話し合っていました。大規模な開発者グループがいて、コード ベース内で一定レベルの一貫性と規則を維持したい場合、ソフトウェア ファクトリを実装することは良いアイデアであると考える人もいるかもしれないと私たちは考えました。

もう少し考えてみると、私はソフトウェア ファクトリを個人的に使用するというアイデアが本当に好きであることに気付きました。なぜなら、書くことで頭痛の種を大幅に節約できるので、楽しみのために取り組んでいるプロジェクトのコードを簡単に作成できるからです。 「ボイラープレート」コード。そうは言っても、大規模な組織でソフトウェア ファクトリの使用を強制すると、チーム内で争いが生じる可能性があると思います。一部の開発者は、それが創造力の侵害になると考える可能性があるからです。

そこで私が疑問に思っているのは (ファクトリを実装した組織の一員だった人から) 、組織内でファクトリを使用することを決定するためにどのような基準が必要になるかということです。 ?

開発チームでスクラムを使い始めた方へ: 従来のチームを維持したり、新しいチームを結成したりしましたか? 私たちの組織では、データベース、製品開発、およびフロントエンド開発者 (単純化されています!) に分かれています。

他の人が実際にスクラムのためにチーム構造全体を再編成したのか、それとも「古い」チームの 1 人などを組み合わせて専用のプロジェクト (?) チームを結成したのかに興味があります。

ネットワーク上でさまざまな起動スクリプトを実行するために多数のvbscriptを維持しており、それらのほとんどすべてで使用する関数がいくつかあります。

コピーアンドペーストを除いて、再利用可能なvbscriptコードのライブラリを作成する方法について誰かが提案を持っていますか。コピーアンドペーストよりも頭痛の種でない限り、コードジェネレーターを使用することを嫌がりません。しかし、どんな推奨もいただければ幸いです。

ありがとう

特に再利用可能なコンポーネントに関して、人々がコード ライブラリをどのように編成しているかに興味があります。以下ではオブジェクト指向の用語で話していますが、他の種類の言語のライブラリをどのように編成しているかにも興味があります。

例えば：

• あなたはすべてのクラス ライブラリ プロジェクトに固執しますか? それとも、すべてを 1 つのプロジェクトにまとめることを好みますか?
• ビルド済みの DLL を再利用しますか、それとも以前のプロジェクトの個々のクラスを現在の作業に含めますか? 個々のクラスの場合、それらをプロジェクト間で共有して、すべてが最新の状態に保たれるようにしますか? それとも分岐を許可しますか?
• 再利用可能な要素の大きさは? 彼らはどのくらい集中していますか？彼らはどのように集中していますか？
• 優先プラクティスを通じて、どのレベルの再利用を達成できますか?

等

編集

ここで特定のガイダンスを求めているわけではありません。人々の考えや実践に興味があるだけです。単一のプロジェクト内ではなく、異なるプロジェクト間でのコードの再利用に特に関心があります。(残念ながら、ここでの「プロジェクト」の使用は誤解を招きます。つまり、Visual Studio の意味でのプロジェクトではなく、顧客のために実施される実際のプロジェクト間での再利用を意味します。)