タグ付けされた質問 「code-organization」

Silverlightアプリケーションに取り組んでいます。私はそれをいくつかのアセンブリに分割しました： ドメイン リポジトリー（Sterlingデータベースに存続するものすべて） UI ... これは私が学んだ方法ですが、疑問に思いました。DLLが再利用されないことがわかっている場合、それらを分割する必要がありますか？または、すべてを1つのアセンブリに配置し、フォルダと名前空間を使用して整頓できますか？ アセンブリが多すぎるプロジェクトも見ました。適切な場所で名前空間を使用する代わりに。 それで、いつ新しいコードの一部に対して新しいアセンブリを作成するのですか？このテーマに関する良いリソースはありますか？また、コードを技術的に（ドメイン、データ、UIなど）に分割したり、機能的に（つまり、患者管理、患者医療、病院ロジスティクスなど）分割したりしますか？

9 .net  architecture  visual-studio  code-organization 

私はアプリケーションレイヤーについて読んでおり、次のプロジェクト（c＃、. Net）でこのデザインを使用したいと考えています。いくつかの質問： レイヤーの分離は名前空間を通じて行われますか？Project.BLL.Whatever、Project.DAL.Whatever レイヤー、コンポーネント（Project.BLL.Component1）、またはコンポーネント、レイヤー（Project.Component1.BLL）で分離する方が適切ですか？ 私のDALの場合、このレイヤーはさまざまなクラスを使用してさらに編成されますか？すべてのデータベース呼び出しが単一のクラスに入れられる場合、組織はありません。これらを異なるクラスまたは名前空間に分割する方が良いでしょうか？ DALクラスは通常静的ですか？毎回そのメソッドの1つを呼び出す前にDALオブジェクトをインスタンス化するのは面倒です。 これらのレイヤーで正しい方法で物事を行うためのその他のヒントをいただければ幸いです。

9 c#  code-organization  layers 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私は物事に名前を付けるのがかなり苦手です。 私が一般的に思いつくことができる唯一の名前は「ヘルパー」です。たとえば、パスを操作するための支援関数を含むヘッダーファイルがある場合、それを「ヘルパー」ディレクトリ内に置き、「path-helper.hpp」などの名前を付ける傾向があります。 明らかに、それは悪い命名規則です。:) 自分のヘッダーとライブラリを常に参照するために使用できるフォルダー（および名前空間）に一貫した名前付けスキームを設定したいのですが、入力や覚えやすい名前（などboost）を見つけるのに問題があります...それらの一部を「ヘルパー」や「stdext」などと呼ぶことになってしまいますが、これは素晴らしいアイデアではありません。 覚えやすくタイプしやすく、一般的ではないライブラリの名前をどのようにして見つけますか（「ヘルパー」、「std」、「stdext」など）。 これを行う方法についての提案はありますか？

8 c++  naming  organization  code-organization 

私は大規模なコンピューターサイエンスの学生で、現在、大規模なエンタープライズWebアプリケーションを作成およびサポートしている会社の就職年にいます。現実の世界でソフトウェアがどのように生産されるかを体験した経験を愛しており、既存の機能を維持および拡張するだけでなく、製品の完全に新しい機能を開発する機会を提供する会社を見つけることができてとても幸運です。 とはいえ、これが正しく開発するための完璧な例になる可能性は非常に低いと私は非常に意識しています。実際、それとはかけ離れています。ここでの経験から多くのことを学んでいるように感じます。間違ったことを学んだり、道を進むのが難しいかもしれない同僚から悪い習慣を身につけたりしたくありません。ほとんどの場合、良い点と悪い点を簡単に区別できます。たとえば、ここでの単体テストのカバレッジは、さまざまな理由で事実上存在しません（ほとんどの場合、1つまたは2つの有効なポイントが混じった不十分な言い訳）。しかし最近は、よくわからないことが定期的に発生していることに気づきました。 新しいプロジェクトを始めるときはいつでも、当然、拡張、変更、または削除する必要がある関連コードを見つける必要があります。ほとんどの場合、アプリケーションの最も一般的に使用されるセクション内にないものは、コードベース内で見つけるのに時間がかかります。コードのセクションをよく知っている1人または2人の技術リーダーがいますが、彼らは時々困惑し、必要なものを探すのに長い時間を費やす必要があるか、最近コードのその部分を編集している人に頼る必要があります（誰か）助けを求めて。長い時間を言うとき、私は時間（通常）を意味するわけではありませんが、システムに漠然と精通している誰にとっても、良いコードベースは最低でも数分以内の任意のポイントにナビゲートできるように思えます。 だから、私の質問。上記の問題は、不十分な構造のコードが原因ですか？あるいは、開発者がコードベースについて十分な知識を持っていないためでしょうか？または、大規模なアプリケーションでは、ファイル構造を明確に保つためにどれだけの労力がかかるかに関係なく、それは単に避けられないのでしょうか？ または、確かに...私は本当に重要ではないトピックに私の時間を無駄にしていますか？

8 maintenance  maintainability  code-organization