タグ付けされた質問 「design」

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 意思決定段階では、正規化が最初の考慮事項ではないという多くの設計を見ました。 多くの場合、これらの設計には30を超える列が含まれており、主なアプローチは「すべてを同じ場所に置く」ことでした 私が覚えていることによると、正規化は最初の最も重要なことの1つです。 編集： 優秀なアーキテクトや専門家が非正規化されたデザインを選択し、未経験の開発者が反対を選択するというのは本当ですか？正規化を念頭に置いて設計を開始することに対する議論は何ですか？

23 design  sql  database-design  relational-database  rdbms 

UMLがオブジェクト指向へのより古典的なアプローチを指向していることを考えると、JavaScriptシステムを設計するための信頼できる方法でまだ使用可能ですか？ 私が見ることができる特定の問題の1つは、実際にはクラス図がシステムの構造図であり、JavaScriptがより多くの動作駆動型であるということです。どうすれば対処できますか？ ここでは、現実世界のドメインについては話していないことに注意してください。私が達成しようとしているソリューションのモデルです。

23 design  object-oriented  javascript  uml 

不変の「パターン」はその長所から気に入っています。過去には、不変のデータ型（一部、ほとんど、またはすべて）を使用してシステムを設計することが有益であることがわかりました。多くの場合、そうすることで、作成するバグが少なくなり、デバッグがはるかに簡単になります。 しかし、私の仲間は一般的に不変を避けています。彼らはまったく経験がありません（それからはほど遠い）が、データオブジェクトを古典的な方法で書き込みます-すべてのメンバーのゲッターとセッターを持つプライベートメンバー。その後、通常、コンストラクターは引数をとらないか、単に便宜上いくつかの引数をとります。多くの場合、オブジェクトの作成は次のようになります。 Foo a = new Foo(); a.setProperty1("asdf"); a.setProperty2("bcde"); たぶん彼らはそれをどこでもします。たぶん、それらがどれほど重要であっても、それらの2つの文字列を受け取るコンストラクタを定義することすらありません。そして多分、それらは後でそれらの文字列の値を変更せず、変更する必要はありません。明らかに、これらのことが真実であれば、オブジェクトは不変として設計されるでしょう。（コンストラクターは2つのプロパティを取り、セッターはまったく取りません）。 オブジェクト型を不変として設計する必要があるかどうかをどのように決定しますか？判断するための適切な基準はありますか？ 私は現在、自分のプロジェクトのいくつかのデータ型を不変に切り替えるかどうかを議論していますが、ピアにそれを正当化する必要があり、型のデータは（めったに）変更されない可能性があります-いつでも変更できますそれは不変の方法です（新しいものを作成し、変更したいものを除いて古いオブジェクトからプロパティをコピーします）。しかし、これが単に不変物が透けて見えるのが私の愛なのか、それとも実際にそれらの必要性/利益があるのか​​はわかりません。

23 design  immutability 

厄介な、未解決の質問ですが、それは私がいつも反対している問題です： 保守と操作が簡単なソフトウェアは、適切に設計されたソフトウェアです。設計を直観的にしようとすると、次の開発者がコンポーネントの機能を推測できるような方法でコンポーネントに名前を付けます。これが、クラスに「Type1」、「Type2」などの名前を付けない理由です。 実際の概念（顧客など）をモデル化する場合、これは一般に、モデル化される実際の概念に基づいて型に名前を付けるのと同じくらい簡単です。しかし、よりシステム指向の抽象的なものを構築する場合、読みやすく、簡単に消化できる名前を使い果たすことは非常に簡単です。 （私にとっては）コンポーネントの動作を説明する基本型またはインターフェイスを使用して、型のファミリに名前を付けようとすると悪化します。これは当然、派生型ごとに実装のフレーバー（IDataConnectionおよびSqlConnection.NET Frameworkなど）を記述しようとしますが、「リフレクションによる動作と特定の属性セットの検索」のような複雑なものをどのように表現しますか？ 次に、やろうとしていることを説明していると思われるタイプの名前を最終的に選択したら、同僚は「WTFはDomainSecurityMetadataProvider実際にこれを行うのですか？」と尋ねます。 コンポーネントの意味のある名前を選択するための良いテクニックはありますか、または混乱した名前を取得せずにコンポーネントのファミリーを構築する方法はありますか？ 名前に適用できる簡単なテストはありますか？

23 design  naming 

私は素晴らしい投資銀行で2年間働いてきました。 私は、最適化されたコードを作成し、適応された優れたデザインパターン、ソリッド原則、デメテルの法則を尊重し、あらゆる種類のコードの重複を回避することを望んで、いくつかの技術プロジェクトを作りました 本番環境での配信=>バグがゼロの場合、すべてが期待どおりに行われています。 しかし、大部分の開発者は、すべてのコードが読解には複雑すぎることを正確にするために来ました。たとえば、「ifおよびinstanceofをいくつか作成し、ポリモーフィズムを忘れて、緊急の生産バグを修正するのが非常に簡単になるようにします」。私は答えることを好まなかった...... これらの開発者はまったく好奇心がないことを知っており、優れた設計を理解する努力を拒否しています（たとえば、90％の開発者は戦略パターンとは何かを知りません。 ）、私のプロジェクトマネージャーは、私は本当に間違ったやり方であり、世銀の世界にとって理想主義すぎると言った。 私に何をアドバイスしますか？本当に良いコードの欲求を維持するか、そうである開発者の大多数に私を適応させるならば、私によると、私による開発者の仕事のすべての美しさである設計コードによって本当に面白くないです。 それとも逆に、基本的なオブジェクト指向の原則とベストプラクティスを習得して、自分のコードに適応する必要がありますか？

23 java  design  design-patterns  solid 

記事-インターフェイスの代わりにデリゲートを使用するタイミング（C＃プログラミングガイド）を読んだ後 、以下の特定のポイントを理解するのに多少の助けが必要です。これらの例や詳細な説明はありますか？ 次の場合にデリゲートを使用します。 イベンティングデザインパターンが使用されます。 静的メソッドをカプセル化することが望ましいです。 簡単な構成が望まれます。 クラスには、メソッドの複数の実装が必要な場合があります。 次の場合にインターフェースを使用します。 呼び出される可能性のある関連メソッドのグループがあります。 クラスには、メソッドの実装が1つだけ必要です。 私の質問は、 イベントデザインパターンとはどういう意味ですか？ デリゲートを使用した場合、どのように構成が簡単になりますか？ 呼び出される可能性のある関連メソッドのグループがある場合、インターフェースを使用します-それにはどんな利点がありますか？ クラスがメソッドの実装を1つだけ必要とする場合、インターフェースを使用します。利点の点でそれはどのように正当化されますか？

23 c#  design  .net 

今日は、AdventureWorksデータベースのチャンスをうかがっていたと私はテーブルの数が（ことに気づいたHumanResources.JobCandidateと Sales.Individual例えば）XMLデータを格納している列を持っています。 私が知りたいのは、基本的にデータベーステーブルの行のデータを別のテーブルの列に保存する利点は何ですか？これにより、この情報をクエリするのが難しくなりませんか？それとも、データを照会する必要はなく、保存するだけでよいという前提ですか？

23 design  database  xml 

現在、私のスーパーバイザーは、バグ追跡ソフトウェアを使用して要件のドキュメント/仕様を作成しています。これは私にとってひどいアイデアのように思えます。すべての要件はこれらの小さなチケットにあり、要件を取得するためにこの馬鹿げたWebフォームをクリックする必要があります。要件/ソフトウェア仕様に対する健全なソフトウェアソリューションとは何ですか？ 明確にするために、私は非常に多くの機能を備えたこの大きなソフトウェアコンポーネントを構築しており、これらの機能はこのバグ追跡ソフトウェアで説明されています。

23 design  requirements  issue-tracking 

私は依存関係管理にMavenを使用しているSpring-MVCアプリケーションに取り組んでいます。プロジェクトが大きいので、プロジェクトをいくつかの部分に分割することを考えています。いくつか疑問がありましたが、ここで答えが得られることを願っています。 現在、ROOT.warサーバー上のApache Tomcatのように単一のWARファイルをデプロイしています。プロジェクトが大きいので、通知とメール、サードパーティサービス、PUSH（Cometd）、REST APIなどのようなwebappの部分があります。現在、それらはすべてクラブであり、互いに依存しています。たとえば、通知はユーザーに合わせて調整されるため、Notificationオブジェクトもオブジェクトに依存しPersonます。 大きなプロジェクトを分割する主な目的は、バグ修正、機能の追加、テストなどのために個々のモジュールで作業できるようにすることです。そして、満足したら、このモジュールのみをアプリケーション全体ではなくサーバー上で置き換えることができます。これは可能ですか？ 前述したように、オブジェクト間に依存関係とマッピングがあります。これらは異なるサブモジュール間でどのように管理されますか、またはインポートステートメントだけが他のプロジェクトを含むように変更されますか？ 私が言ったように、意図は個々のモジュールに取り組み、それらを展開できるようにすることです（できればホット）。現在、として単一のWARファイルのみがありますROOT.war。分割により複数のwarファイルが作成され、URLで参照されますdomain-name.com/module_name/some_mappingか？ 現在ドキュメントを確認していますが、これはMavenが提供するマルチモジュールで達成したい主な目的であり、これが実現可能かどうかを知りたいと思っています。さらに情報が必要な場合は、お知らせください。 現在、私は次のように春から親POMを使用しています： <parent> <groupId>io.spring.platform</groupId> <artifactId>platform-bom</artifactId> <version>1.1.3.RELEASE</version> <relativePath /> </parent>

23 java  design  architecture  web-development  maven 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 閉じた3年前。 言葉なしでは考えられないこの問題を抱えている人もいます。そして、彼らの考えや決定を書き留めることは、最も効果的な進め方です。 だから-コーディング中にNotepad ++ファイルに自分の考えや決定を書き留めることは正常で受け入れられますか？ 技術文書を再作成したり、より複雑なアルゴリズムについて推論したりする場合など、受け入れられるべき場合もありますが、設計オプションを検討して判断しようとする場合など、奇妙な場合もあります。 このプラクティスが生産性に与える影響は不明です。片側から-内側の言葉を使った推論は、書かれた言葉を使った場合よりも速いかもしれません。反対側から-より複雑な問題は書く必要があります。それに、デザインの選択肢が増えれば、意思決定が書かれたときのフィーリングが良くなり、士気が上がります。

22 design  maintenance  concepts  coding 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 ペアプログラミングは、今日では非常に有名です。 以下のようないくつかの利点があります。 バグの少ないプログラム。 ポストプロダクションのメンテナンスコストははるかに低くなります。 確立された慣行は挑戦され、新しいアイデアが生まれます。 プログラマーはお互いから学びます。 プログラマーはソフトスキルを開発します。 しかし、ペアプログラミングの欠点は何ですか？

22 design  programming-practices  pair-programming 

このC＃クラスを作成しましょう（Javaでもほぼ同じです）。 public class MyClass { public string A {get; set;} public string B {get; set;} public override bool Equals(object obj) { var item = obj as MyClass; if (item == null || this.A == null || item.A == null) { return false; } return this.A.equals(item.A); } public override int GetHashCode() …

22 java  c#  design  language-design  collections 

最近、スケーラブルなエンタープライズコンピューターアーキテクチャのニュアンスを学び始めました。中心的なコンポーネントの1つはメッセージングキューです。プログラミングパラダイムからできる限り多くを学ぶために、独自のバージョンのメッセージングキューサービスを実装しようとしています。 これまでのところ、私の最初の設計はスレッドソケットリスナーで実行されますが、2つの別々の処理ノードによって同じメッセージが2回ダウンロードされるのを防ぐために、読み取りが開始されるとメッセージキューインデックスレジスタがロックされ、レジスタがロック解除されるとロックが解除されます更新しました。そのため、これはスレッド化の必要性をなくし、メッセージングキューサービスが実行されているサーバーの処理速度に基づいてスケーラブルなシステムのサイズに上限があることを意味します。 これを回避する方法は、複数のサーバーでメッセージキューサービスを実行することですが、これにより、同じメッセージが2回ダウンロードされる可能性が高くなります。このような問題の発生を防ぐ唯一の方法は、（サーバー、または単一サーバー上のスレッドでさえ、情報を同期し、そのような再発行を検出した後）処理ノードに停止するように命令する失効コールバックを含めることです現在のジョブ、および次のメッセージのためにメッセージキューを再クエリしますが、送信されるトラフィックのほとんどが同期および失効コールバックであり、ボトルネックを引き起こし、情報の処理を遅らせる天井があります多くの処理ノードがnull操作を実行し、時間を浪費します。 この問題を回避するために考えることができる最後の方法は、各メッセージキューサーバー（および各サーバーの各スレッド）がキュー内のどこを探しているかに関して特定のオフセットを持たせることですが、それは特に処理を特定の順序で実行する必要がある場合は、アプリケーションのタイプ。 ということで、既存のエンタープライズグレードのメッセージキューサービスがこれらの問題をどのように回避するかを示すことができるメッセージキューアーキテクチャの設計はありますか？

22 design  scalability  message-queue 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 そのため、いくつかの明確に定義された要件を備えた新しい候補者に、簡単なコーディング演習を提示します。時々、実際に目の前の問題を解決することはできませんが、認識された問題を解決するために過剰に設計されたソリューションを受け取ることがあります-多くの場合、演習の範囲外です。 さて、私の質問は、これは警告サインですか？ 編集：議論のかなりの部分は、テストの欠陥に基づいています-これは公平な点です。コメントで説明したように、テストの基本的な前提は、ファイルからデータを賢明な方法で読み取る方法を示すことです（そして、私たちが見るさまざまなアプローチに驚かれることでしょう）。更新間の待ち時間を計算する前の項目。これが機能するためには、データについて特定の前提条件を作成する必要があり、これらの前提条件を探します。また、2時間ですべてのアプローチ（OOアプローチなどを含む）を見たいと明示的に述べています。時間枠。 私見、私がインタビューしたとき、それは私が出くわした中で最も完全な運動でした。 私が熟考している特定のシナリオは、ファイルから読み取るのではなく、候補がマルチスレッドアプリケーションで「ネットワーク」入力を受け入れた場合です。これは明らかに範囲外です。

22 design  programming-practices  interview 

静的言語（C＃やJavaなど）と動的言語（RubyやPythonなど）で構築されるアプリケーションを設計するときに、アーキテクチャ上の大きな違いはありますか？ 一方のタイプに適した設計で、もう一方のタイプに悪い設計の可能性はどれですか？一方のタイプでは実現できない便利な機能がありますが、他のタイプでは実現できません（もちろん、設計とアーキテクチャにおいて）。 また、ダイナミック固有のデザインパターンはありますか？

22 design  architecture  dynamic-typing  static-typing