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

プロジェクトを整理する特定のスタイルはありますか？ たとえば、現在ボリビアのいくつかの学校でプロジェクトを作成していますが、これが私がそれを整理した方法です。 TutoMentor (Solution) TutoMentor.UI (Winforms project) TutoMentor.Data (Class library project) プロジェクトをどのように整理しますか？あなたが組織し、誇りに思っているものの例はありますか？ソリューションペインのスクリーンショットを共有できますか？ 私のアプリケーションのUI領域では、さまざまなフォームとそれらが属する場所を整理するための適切なスキーマを決定するのに苦労しています。 編集： .UIプロジェクトでさまざまなフォームを整理するのはどうですか？どこで/どのように異なるフォームをグループ化する必要がありますか？それらをすべてプロジェクトのルートレベルに配置するのは悪い考えです。

148 c#  .net  winforms  code-organization 

私は数年間プロのコーダーをしています。私のコードに関するコメントは一般的に同じです。優れたコードを記述し、十分にテストされていますが、より高速になります。 それでは、品質を犠牲にすることなく、より高速なコーダーになるにはどうすればよいですか？この質問のために、私はスコープをC＃に制限します。それは主に（楽しみのために）コーディングするものであるか、またはJavaであり、これは多くの点で重要です。 私がすでにやっていること： 仕事を成し遂げる最小限のソリューションを書く 多数の自動化されたテストを書く（リグレッションを防ぐ） あらゆる種類の再利用可能なライブラリを作成（および使用）する よく機能する場所でよく知られた技術を使用する（例：Hibernate） 所定の位置に収まるデザインパターンを使用する（シングルトンなど） これらはすべて素晴らしいですが、時間の経過とともに私の速度が向上しているとは感じません。私がやる私が（でも10％）私の生産性を向上させる何かを行うことができれば、それは私の競合他社よりも10％高速ですので、注意して。（私が持っているわけではありません。） それに加えて、小規模なFlash開発であろうとエンタープライズJava / C ++開発であろうと、私は常にマネージャーからこの報酬を受け取りました。 編集：私が速いとはどういう意味か、そして私が遅いことをどのように知っているかについて多くの質問があるようです。さらに詳細に説明します。 私は、さまざまなプロジェクトやさまざまなテクノロジー（Flash、ASP.NET、Java、C ++）で、さまざまな企業の中小規模チーム（5〜50人）で働いていました。私のマネージャー（彼らは私に直接言った）の観察は、私が「遅い」ということです。 これは、私の仲間の多くがスピードのために品質を犠牲にしたためです。彼らはバグがあり、読みにくく、保守しにくく、自動テストを書くのが難しいコードを書きました。私のコードは一般に、十分に文書化され、読みやすく、テスト可能です。 Oracleでは、他のチームメンバーよりも一貫してバグをゆっくりと解決していました。私はそのことに対するコメントを得るので、これを知っています。これは、他の（はい、より上級で経験豊富な）開発者が、ほぼ同じ品質（読みやすさ、保守容易性、テスト容易性）で、私がかかった時間よりも短い時間で作業を行えることを意味します。 どうして？私は何が欠けていますか？どうすればこれを改善できますか？ 私の最終目標は単純です：今日40時間で製品Xを作成でき、明日20、30、または38時間で同じ製品を作成できるように、なんとか改善できるなら、それが知りたいことです-どうやってそこまで行くの？継続的に改善するためにどのプロセスを使用できますか？コードを再利用することだと思っていましたが、それだけでは十分ではないようです。

144 code-quality  code-organization 

私は、主にWebプロジェクト（W / LAMP）と、時には平均規模のC / C ++（非GUI）プロジェクトに取り組んでいる個人開発者です。 私はしばしばソースコードツリーの構築に苦労しています。実際、通常、ツリー全体をダンプして3〜4回再配置することなくプロジェクトを完了することはありません。 時々、ソースの分類が過剰になります-フォルダとサブフォルダの非常に長いツリー。それ以外の場合は、それらが提供するより大きな目的に基づいてすべてのファイルを特定のフォルダーに集中させ、ソース内の「無秩序な」フォルダーに導くことになります。 私は尋ねたい： ソースツリーの構造化に役立つ原則/論理/ベストプラクティスはありますか？ プロジェクトの分析に基づいてソースツリーを事前に視覚化するのに役立つグラフィック/ダイアグラム技術（データフローの場合はDFDなど）はありますか？ プロジェクトに関連するマルチメディアファイルツリーを構造化するために採用する戦略は何ですか？ 報奨金について：メンバーが独自の実践を共有している既存の回答に感謝しますが、より一般的で有益な回答（またはリソース）とメンバーからのより多くの回答を奨励したいと思います。

89 code-organization  solo-development 

C / C ++ページの多くの質問と回答、具体的または間接的にマイクロパフォーマンスの問題（間接関数と直接関数とインライン関数のオーバーヘッドなど）、またはO（N 2）vs O（N log N）アルゴリズムの使用100アイテムのリスト。 私は、問題がない限り、または問題があることがわかるまで、常にマイクロパフォーマンスを気にせず、マクロパフォーマンスにほとんど気を配らずに、コーディングしやすく、信頼性の高いコードを維持します。 私の質問は、なぜ多くのプログラマーがそんなに気にするのかということです。それはほとんどの開発者にとって本当に問題なのでしょうか、それについてあまり心配する必要がないほど幸運だったのでしょうか、それとも私は悪いプログラマーですか？

71 c++  c  optimization  code-organization 

私は、世界中のさまざまな顧客向けに高度にカスタマイズされた大規模なソフトウェアプロジェクトに取り組んでいます。つまり、80％のコードがさまざまな顧客に共通しているだけでなく、ある顧客から別の顧客に変更する必要がある多くのコードがあることを意味します。過去に別のリポジトリ（SVN）で開発を行い、新しいプロジェクトが開始されたとき（大規模な顧客はほとんどありませんが）、過去のプロジェクトがニーズに最適なコードベースに基づいて別のリポジトリを作成しました。これは過去に機能していましたが、いくつかの問題に遭遇しました。 あるリポジトリで修正されたバグは、他のリポジトリでは修正されません。これは組織の問題かもしれませんが、5つの異なるリポジトリのバグを修正してパッチを当てるのは難しいと思います。このリポジトリを保守しているチームは世界の別の場所にいて、テスト環境がないことに注意してください、スケジュールや要件を把握していません（ある国の「バグ」は別の国の「機能」かもしれません）。 別のプロジェクトにも役立つかもしれない1つのプロジェクトに加えられた機能と改善は失われ、別のプロジェクトで使用された場合、多くの場合、1つのコードベースから別のコードベースにそれらをマージする大きな頭痛の種を引き起こします）。 1つの開発ブランチで行われたリファクタリングとコードの改善は、ブランチ間でこれらのすべての変更をマージする必要がある場合、失われるか、害よりも害をもたらします。 現在、これらの問題を解決する方法について議論しており、これまでのところ、これを解決する方法について次のアイデアを思いつきました。 開発を別々のブランチで維持しますが、一般的なバグ修正がマージされる中央リポジトリを持ち、すべてのプロジェクトがこのセントラルリポジトリからの変更を定期的に（たとえば毎日）独自のものにマージすることで、より整理されます。これには、大きな規律と、ブランチ間のマージに多大な労力が必要です。ですから、特に時間のプレッシャーがかかったときに、それがうまくいくと確信していません。 個別の開発ブランチを放棄し、すべてのコードが存在する中央のコードリポジトリを持ち、プラグ可能なモジュールと構成オプションを使用してカスタマイズを行います。既にコードの依存関係を解決するためにDependency Injectionコンテナーを使用しており、ほとんどのコードでMVVMパターンに従ってビジネスロジックをUIから明確に分離しています。 2番目のアプローチはよりエレガントに見えますが、このアプローチには多くの未解決の問題があります。例：モデル/データベースでの変更/追加の処理方法。エンティティフレームワークで.NETを使用して、エンティティを厳密に型指定しています。ある顧客には必要だが、データモデルを乱雑にすることなく別の顧客には役に立たないプロパティをどのように処理できるかわかりません。サテライトテーブル（特定のエンティティ用の追加の列が元のエンティティへの1：1マッピングで存在する個別のテーブルを持つ）を使用してデータベースでこれを解決することを考えていますが、これはデータベースのみです。これをコードでどのように処理しますか？データモデルは中央ライブラリにあり、このアプローチを使用して顧客ごとに拡張することはできません。 この問題に苦しんでいるのは私たちだけではないと確信しており、このトピックに関する資料がほとんどないことにショックを受けています。 私の質問は次のとおりです。 高度にカスタマイズされたソフトウェアに関してどのような経験があり、どのアプローチを選択し、どのように機能しましたか？ どのアプローチをお勧めしますか、またその理由は何ですか？より良いアプローチはありますか？ お勧めできるトピックに関する良い本や記事はありますか？ 技術環境（.NET、Entity Framework、WPF、DI）について具体的な推奨事項はありますか？ 編集： すべての提案をありがとう。アイデアのほとんどは、すでにチーム内で持っていたものと一致しますが、あなたがそれらで得た経験と、それらをより良く実装するためのヒントを確認することは本当に役立ちます。 どの方向に進むかはまだわかりませんし、（単独で）決定を下すわけではありませんが、チームでこれを伝えて、役に立つと確信しています。 現時点では、テナーはさまざまな顧客固有のモジュールを使用する単一のリポジトリのようです。私たちのアーキテクチャがこれに合っているか、それを適合させるためにどれだけ投資する必要があるのか​​はわかりません。 それで、すべての応答に再び感謝します！

28 design  architecture  development-process  database-design  code-organization 

私は多くの定数を持つアプリケーションに取り組んでいます。前回のコードレビューで、定数が分散しすぎているため、すべてを単一の「マスター」定数ファイルに整理する必要があることがわかりました。意見の相違は、それらを整理する方法についてです。大多数は、定数名を使用することで十分であると感じていますが、これは次のようなコードにつながります。 public static final String CREDITCARD_ACTION_SUBMITDATA = "6767"; public static final String CREDITCARD_UIFIELDID_CARDHOLDER_NAME = "3959854"; public static final String CREDITCARD_UIFIELDID_EXPIRY_MONTH = "3524"; public static final String CREDITCARD_UIFIELDID_ACCOUNT_ID = "3524"; ... public static final String BANKPAYMENT_UIFIELDID_ACCOUNT_ID = "9987"; このタイプの命名規則は扱いにくいと思います。ネストされたパブリッククラスを使用する方が簡単だと思い、次のようなものがあります。 public class IntegrationSystemConstants { public class CreditCard { public static final String …

21 java  code-organization 

OK ..すべての議論の後、私が扱っている具体的な例をより良く反映するために質問を少し変更しています。 私は2つのクラスModelOneとを持っていますModelTwo。これらのクラスは同様のタイプの機能を実行しますが、互いに無関係です。しかし、私はCommonFunc両方ModelOneで実装されているいくつかのパブリック機能を含む3番目のクラスをModelTwo持っていDRYます。2つのモデルはModelMainクラス内でインスタンス化されます（それ自体はより高いレベルなどでインスタンス化されますが、このレベルで停止しています）。 私が使用しているIoCコンテナはMicrosoft Unityです。私はそれの専門家であるふりはしませんが、インターフェイスのクラスとコンテナをクラスに登録し、具体的なクラスが必要な場合は、特定のインターフェイスに一致するオブジェクトをIoCコンテナに尋ねることです。これは、Unityからインスタンス化するすべてのオブジェクトに対して、一致するインターフェイスが必要であることを意味します。各クラスは異なる（重複しない）機能を実行するため、これは、インターフェイスとクラス1の比率が1：1であることを意味します。しかし、それは私が書くすべてのクラスのためにインターフェースを慎重に書いているという意味ではありません。 したがって、コード的には2になります。 public interface ICommonFunc { } public interface IModelOne { ICommonFunc Common { get; } .. } public interface IModelTwo { ICommonFunc Common { get; } .. } public interface IModelMain { IModelOne One { get; } IModelTwo Two { get; } .. } public …

17 c#  interfaces  class  code-organization 

私は最近、複数の.netソリューションがあり、それぞれがそのソリューションに固有のいくつかのプロジェクトをホストしているが、他のプロジェクトを「借りる」/「リンクする」（既存のプロジェクトを追加する）古いレガシーコードベースを持つ新しいクライアントで働き始めました技術的には他のソリューションに属します（少なくともTFSのフォルダー構造を使用する場合） これが絡み合ったセットアップを見たことはなく、明確なビルド順序はなく、ソリューションAのプロジェクトはソリューションBでホストされているプロジェクトの出力ディレクトリから直接DLLを参照する場合があり、プロジェクトが存在する場合でもプロジェクトが直接含まれている場合がありますフォルダー構造で遠ざかります。 すべてが開発者の怠lazのために最適化されているようです。 CIサーバーを持っていない理由について私が彼らに立ち向かったとき、彼らはそのように組織されたコードでセットアップするのは難しいと答えました。（私は今それを設定し、このコード編成を呪っている） ソリューションは展開アーティファクト（一緒に展開する必要があるものは同じソリューション内にあります）を中心に編成されていますが、賢明な決定だと思いますが、それらのソリューション（プロジェクト）の内容はいたるところにあります。 複数のソリューション/展開アーティファクトで共通のクラスライブラリを再利用するときに使用するベストプラクティスのコンセンサスはありますか、 VCSでコードを構造化する方法 個別のデプロイメントアーティファクト間でビジネスロジックの共有を促進する方法

16 version-control  deployment  code-organization  projects-and-solutions 

ノードの配列を設定し、それらをグラフのような構造で互いに接続するクラスがあります。次のことが最善ですか： 1つの機能でノードを初期化および接続する機能を保持します 2つの異なる関数で初期化および接続機能を使用します（これらの関数はプライベートであることに注意してください）。 方法1：（1つの関数が2つのことを行っている点が悪いが、依存する機能をグループ化したままにしている-最初に初期化されない限り、ノードを接続しないでください。） init() { setupNodes() } private func setupNodes() { // 1. Create array of nodes // 2. Go through array, connecting each node to its neighbors // according to some predefined constants } 方法2：（自己文書化という意味では、ただし、connectNodes（）をsetupNodes（）の前に呼び出さないでください。したがって、クラス内部で作業する人はこの順序を知る必要があります。） init() { setupNodes() } private func setupNodes() { createNodes() connectNodes() } private func …

15 functions  code-organization  file-structure 

他のすべての機能をインターフェースできるように、main関数のみを持ち、他の関数を持たないmain.cファイルを持つことは良い習慣ですか？ 決定的なルールがない場合、そうすることとそうでないことはいつ良いですか？

14 c  code-organization  file-structure  modules 

単一の（git）リポジトリに保存されている一連の関連する独立したC ++プロジェクトの編成に関するアドバイスをお願いします。プロジェクトはCMakeを使用します。 簡単な例として、2つのプロジェクトAとB、Bに依存するAを想定します。Aを開発するほとんどの人は、パッケージングシステムを介してBを取得します。したがって、Aのみをコンパイルします。ただし、開発者がAとBの両方を個別にコンパイル（およびインストール）できるようにする必要があります。 これが提案です： └── Repo1 ├── CMakeLists.txt (1) ├── A │ ├── CMakeLists.txt (2) │ ├── include │ │ ├── aaa.h │ │ ├── aaaa.h │ │ └── CMakeLists.txt (3) │ └── src │ ├── aaa.cpp │ ├── aaaa.cpp │ └── CMakeLists.txt (4) ├── B │ ├── CMakeLists.txt (2) …

12 c++  organization  code-organization  dependency-management  cmake 

私の会社のチームリーダー\アーキテクトは、「ロジックで接続されたエンティティ」が1つの.csファイルに配置されていると、大規模プロジェクトの方が理解しやすいと主張しています。 私は引用する： 「ロジックとインターフェースとクラスの構造全体を1か所で見ることができます。これは反論の余地のない議論です。同じことを見るために、ツールを使用するために必要なファイルがたくさんあります図、ナビゲーション用のR＃など」 「貧弱な理論に従って、分離したファイルの軍隊はクールだと叫ぶかもしれませんが、既存のコードに変更を加えることになると、特にこのコードの作成者ではない場合、たくさんの散在するファイルを理解することは非常に困難です。フォーラムでは、「1つの列挙-1つのファイル」と書くことができますが、実際にはこのアプローチは決して使用すべきではありません 「...開発者間でのコードベースの分離に関しては、現在では同じファイルを同時に編集することは問題ではありません。マージは問題ではありません。」 列挙型、クラスなどごとに1つの.csファイルを作成する必要があることを何度も耳にし、読んでいます。これがベストプラクティスです。 しかし、私は彼を納得させることはできません。彼は、Jon Skeetのような有名なプログラマーを信頼していないと言います。ところで、このトピックに関するスキートの意見は次のとおりです。列挙型を見つけるのに最適な場所はどこですか？ どう思いますか？本当の問題はありますか？または、それは趣味の問題であり、組織のコーディング標準によって規制されるべきですか？

12 c#  .net  project  code-organization 

私はiOSプラットフォーム用のアプリを開発してきましたが、これまでずっと、ファイル（.h、.m、.mm）を整理するというひどい仕事をしてきたことに気づきました。iOSプロジェクトのファイルの整理に関して、業界標準やベストプラクティスはありますか？ 私のファイルには、カスタムクラス（View Controllerの横）、カスタマイズされたView Controller、サードパーティのコンテンツ、iOS 5.0以降でのみ動作するコード、以前のバージョンで動作するコードが含まれています。私が探しているのは、他の人（または今後数年のうちに私）がこれを見て、そこにある複数のファイルで迷子にならないように、物事を整理するソリューションです。

12 ios  objective-c  code-organization  xcode  project-structure 

無数のオープンソースプロジェクトに利用できる100万のファイルシステム構造があります。モジュール、言語ファイル、ドメイン、サードパーティライブラリ、移行、国際化、バックアップ、システムの他の部分へのsyslinkなどのものが、プロジェクトのファイルシステムを編成する多くのアプローチを生み出しています。 PHP開発者として、プロジェクト間で何らかの標準化が出現し始めているのではないかと思っています。PSR-0 、我々は最終的にファイルを命名し、ロードするための標準を持っている-しかし、それシステムやそれらがどのように正気の方法で処理することができますを構成するコンポーネントの残りの部分についての私の知識に何もありません。 私たちが扱っているのはMVCだけではありません。これらのすべてを正しく処理する大規模なプロジェクトの例にはどのようなものがありますか？

10 php  project-management  code-organization  file-structure 

ここで何が質問されているのかを理解することは困難です。この質問は、あいまいで、あいまいで、不完全で、過度に広い、または修辞的であり、現在の形では合理的に回答することができません。再開できるようにこの質問を明確にするヘルプについては、ヘルプセンターに アクセスしてください。 7年前休業。 私は複数のAndroidプロジェクトに取り組んでいるインディーデベロッパーです。異なるプロジェクトで同じ機能を維持することに問題があります。たとえば、私のアプリのうち3つは同じ2つのクラスを使用しています。これらは異なるプロジェクトであるため、これらのクラスを変更する必要がある場合は、3回変更する必要があります。この種の一般的な問題に対する簡単な解決策はありますか？

9 project  personal-projects  code-organization