タグ付けされた質問 「patterns-and-practices」

何年も前に、The Mythical Man-Monthを読んだとき、他の情報源からすでに知っているものをたくさん見つけました。しかし、1975年からの本にもかかわらず、そこには新しいものもありました。そのうちの1つは次のとおりです。 外科チーム ミルズは、大規模な仕事の各セグメントはチームに取り組むことを提案しますが、チームは豚の屠殺チームではなく外科チームのように組織されることを提案します。つまり、各メンバーが問題を切り捨てる代わりに、1人がカットを行い、他のメンバーが彼の有効性と生産性を高めるすべてのサポートを提供します。 これは、ソフトウェア開発チームを編成するための非常に興味深いパターンですが、他のソフトウェアエンジニアリングの本では説明されておらず、どこにも記載されていません。 何故ですか？ 「手術チーム」は当時も珍しかったですか？ または、試行されて失敗しましたか？ もしそうなら、どのように失敗しましたか？ そうでない場合、今日のソフトウェアプロジェクトでそのパターンが実装されていないのはなぜですか。

164 development-process  patterns-and-practices 

私は公開リリースを目的としたライブラリを開発しています。オブジェクトのセットを操作するためのさまざまなメソッドが含まれています-セットを生成、検査、パーティション分割、新しいフォームに投影します。関連する場合IEnumerableは、NuGetパッケージとしてリリースされるLINQスタイルの拡張を含むC＃クラスライブラリです。 このライブラリの一部のメソッドには、満たされない入力パラメーターを指定できます。たとえば、組み合わせメソッドには、m個のアイテムのソースセットから構築できるn個のアイテムのすべてのセットを生成するメソッドがあります。たとえば、次のセットを考えます： 1、2、3、4、5 2の組み合わせを要求すると、次の結果が得られます。 1、2 1、3 1、4 等... 5、3 5、4 現在、3つのアイテムのセットを提供し、各アイテムを1回しか使用できないというオプションを設定しながら、4つのアイテムの組み合わせを要求するなど、実行できないことを要求することは明らかに可能です。 このシナリオでは、各パラメーターは個別に有効です。 ソースコレクションはnullではなく、アイテムが含まれています 要求された組み合わせのサイズは、ゼロ以外の正の整数です 要求されたモード（各アイテムを1回のみ使用）は有効な選択です ただし、パラメーターの状態を一緒にすると問題が発生します。 このシナリオでは、メソッドが例外をスローすることを期待しますか（例：）InvalidOperationException、または空のコレクションを返しますか？どちらも私にとって有効なようです： あなたは、の組み合わせを生成することができないn個のセットから項目をm個の項目N> M君はそれゆえ、一度だけ、各アイテムの使用を許可しているので、この操作は不可能と考えることができる場合InvalidOperationException。 n> mが空のセットである場合にm個のアイテムから生成できるサイズnの組み合わせのセット。組み合わせは作成できません。 空のセットの引数 私の最初の懸念は、サイズが不明なデータセットを処理する場合、例外が慣用的なLINQスタイルのメソッドのチェーンを妨げることです。言い換えれば、あなたはこのようなことをしたいと思うかもしれません： var result = someInputSet .CombinationsOf(4, CombinationsGenerationMode.Distinct) .Select(combo => /* do some operation to a combination */) .ToList(); 入力セットのサイズが可変の場合、このコードの動作は予測できません。場合は.CombinationsOf()、例外をスローしたときsomeInputSetよりも少ない4つの要素を持っている場合、このコードがします時々、いくつかの事前チェックせずに、実行時に失敗します。上記の例では、このチェックは簡単ですが、より長いLINQチェーンの途中で呼び出す場合、これは面倒になります。それが空のセットを返す場合、空になりますresult。 例外の引数 私の2番目の懸念は、空のセットを返すと問題が隠れる可能性があることです-LINQのチェーンの途中でこのメソッドを呼び出して静かに空のセットを返す場合、後でいくつかの手順で問題が発生するか、空の結果セット。入力セットに何かが確実に含まれていた場合、それがどのように発生したかは明らかではないかもしれません。 あなたは何を期待しますか、それに対するあなたの議論は何ですか？

108 exceptions  libraries  patterns-and-practices 

複数のサブモジュールで構成されるプロジェクトのテストを書いています。作成した各テストケースは互いに独立して実行され、テスト間ですべてのデータをクリアします。 テストは独立して実行されますが、場合によっては複数のサブモジュールが必要になるため、実行順序の強制を検討しています。たとえば、サブモジュールがデータを生成し、別のサブモジュールがデータに対してクエリを実行しています。データを生成するサブモジュールにエラーが含まれている場合、サブモジュール自体が正常に機能していても、クエリサブモジュールのテストも失敗します。 私がテストしている主な機能は、最初のサブモジュールからのみデータを取得するブラックボックスリモートサーバーへの接続であるため、ダミーデータを操作することはできません。 この場合、テストの実行順序を強制してもいいですか、それとも悪い習慣ですか？このセットアップには臭いがあるように感じますが、より良い方法は見つかりません。 編集：質問は、1つのテストが別のテストのセットアップである場合のテストの構成方法からですか？「前の」テストはセットアップではなく、セットアップを実行するコードをテストするためです。

84 unit-testing  testing  patterns-and-practices 

Javascriptはプロトタイプベースのオブジェクト指向言語ですが、次のいずれかの方法により、さまざまな方法でクラスベースになります。 自分でクラスとして使用する関数を書く フレームワークで気の利いたクラスシステムを使用する（mootools Class.Classなど） Coffeescriptから生成する 最初はJavascriptでクラスベースのコードを書く傾向があり、それに大きく依存していました。しかし最近、私はJavascriptフレームワークとNodeJSを使用していますが、これらはクラスの概念から離れ、次のようなコードの動的な性質により依存しています。 非同期プログラミング、コールバック/イベントを使用するコードの作成と使用 RequireJSを使用したモジュールのロード（グローバルネームスペースにリークしないようにするため） リスト内包表記（マップ、フィルターなど）などの関数型プログラミングの概念 とりわけ これまでに収集したことは、私が読んだほとんどのオブジェクト指向の原則とパターン（SOLIDやGoFパターンなど）は、SmalltalkやC ++のようなクラスベースのオブジェクト指向言語向けに書かれたものです。しかし、Javascriptなどのプロトタイプベースの言語に適用可能なものはありますか？ Javascriptに固有の原則やパターンはありますか？コールバックの地獄、悪の評価、またはその他のアンチパターンなどを避けるための原則

79 design-patterns  javascript  object-oriented  patterns-and-practices  design-principles 

個々の貢献者（プログラマー/デザイナー）が唯一の目的のためにアーティファクトを開発したパターンの名前は何ですか？管理者が最終製品のその機能を削除できるように流用として機能することですか？ これは、ある大手ゲーム開発会社で働いていた元同僚から聞いた民間伝承です。その会社では、中間管理職が製品に「インプットを与え」、「変更を加える」ようプレッシャーをかけられていることはよく知られています。こうした状況は、これらの余分な「管理入力」のために多くのプロジェクトを遅らせました。 上記の会社の1つのプロジェクトでは、アーティストと開発者が、あらゆるカットシーンに登場し、親指のように突き出る過剰なアニメーションキャラクターを作成しました。彼らは、ゲームが出荷される前に簡単に削除できるように設計しました（これは、ゲームがまだダウンロード可能な製品ではなく物理メディアで販売されていたときです）。明らかに、経営陣はアニメーションを削除することを投票しました。肯定的な側面として、経営陣は、製品に建設的なインプットを提供したことを示したため、プロジェクトを遅らせるような不必要な変更を導入しませんでした。 このプロセスパターンには、企業で働くゲームプログラマーの間で名前がありますが、実際の名前が何であるか忘れていました。私はそれがカモだと信じています。誰もが名前を指摘し、おそらくパターンがどのように展開するかについてのかなり信頼できる参照を指摘するのを助けることができますか？

64 project-management  terminology  patterns-and-practices  game-development 

取得中に私のコードはここに見直さ使用しての問題constのキーワードを思い付きました。変数の読み取り専用動作を実装するために使用されることを理解しています。 私は、さまざまな状況が役に立つときに混乱する。 関数のプロトタイプを明確にするために使用すべきですか？ コード開発中のセキュリティ対策として使用する必要がありますか？ 実行時定数を宣言するために、さまざまな関数のスコープで使用する必要がありますか？ それはまったく使用されるべきですか？ これらの質問は、私が直面している混乱のほんの一例です。一般的な混乱は ときにする必要がありますconstCプログラミングで使用するキーワード？ Cでこのキーワードを使用することで得られるさまざまなタイプの利点は何ですか？ constキーワードを使用することの短所はありますか？ 私の質問の詳細にあるこれらすべての質問のために、この質問は広すぎるかもしれないと指摘されています。これらの質問は、主な質問に関する混乱を明確にするためだけのものであることを明確にしたかっただけです。 Cで変数にconstキーワードを使用するタイミングと目的は何ですか？ 言い換えることもできます const同じ長所と短所を備えたC` でのキーワードの適切な使用。

58 c  readability  patterns-and-practices  const 

かなり基本的に聞こえますが、最近、同僚に、呼び出されたメソッドstartHttpServerがまだ実行されていない場合にサーバーを起動するだけなので、理解するには複雑すぎると言われました。「真剣に？私はこれを何十年も続けてきました。これはプログラミングの一般的なパターンです」と答えたとき、私はトラブルに陥ります。私が認めようと思うよりも頻繁に、彼は、プログラミングコミュニティ全体が彼の視点の背後にあることを示す文書化された証拠とともに戻ってきて、私はひどい気持ちになります。 質問：必要なアクションが既に有効になっている場合、ノーオペレーションであるメソッドの概念の背後にある文書化された設計パターンはありますか？または、パターンでない場合、名前もありますか？そうでない場合、この方法でメソッドを記述することを検討するのが複雑すぎると考える理由はありますか？

54 design-patterns  patterns-and-practices  anti-patterns 

私はWPF MVVMフレームワークCaliburn.Microを見ていましたが、多くの標準的なものは命名規則に基づいていることを読みました。 たとえば、ViewのプロパティをViewModelのプロパティに自動バインドします。これは便利なように見えますが（定型コードを削除します）、私の最初の本能的な反応は、このコードを読む新しいプログラマーにとって完全に明白ではないということです。つまり、アプリケーションの機能は、独自のコードによって完全に説明されるのではなく、フレームワークのドキュメントによっても説明されます。 編集： したがって、このアプローチは設定よりも規約と呼ばれます。これに関する質問が見つからなかったため、質問を変更しました。 私の質問は： 構成に対する規約は物事を単純化する正しい方法ですか、それともプログラミングの原則に違反していますか（もしそうなら、どの原則に違反していますか）？

51 patterns-and-practices 

実行を停止してはならないいくつかのエラーを処理するためにerror、クライアントがチェックして例外をスローするために使用できる変数があります。これは反パターンですか？これを処理するより良い方法はありますか？この動作の例については、PHPのmysqli APIをご覧ください。可視性の問題（アクセサ、パブリックスコープとプライベートスコープ、クラス内の変数はグローバルですか？）が正しく処理されると仮定します。

44 design-patterns  object-oriented  exceptions  patterns-and-practices  anti-patterns 

Carクラスがあると言いましょう： public class Car { public string Engine { get; set; } public string Seat { get; set; } public string Tires { get; set; } } 駐車場に関するシステムを作成しているとしましょう。私は多くのCarクラスを使用するので、クラスを作成しCarCollectionますFindCarByModel。 public class CarCollection { public List<Car> Cars { get; set; } public Car FindCarByModel(string model) { // code here return new Car(); …

35 c#  object-oriented  programming-practices  class-design  patterns-and-practices 

私は多くの異なる親/子クラスを持つオブジェクトモデルを開発しています。各子オブジェクトには、その親オブジェクトへの参照があります。親参照を初期化するいくつかの方法を考えることができます（そして試してみました）が、各アプローチには重大な欠点があります。以下で説明するアプローチのうち、どれが最良であるか、またはそれよりも優れている場合を考えます。 以下のコードがコンパイルされることを確認しませんので、コードが構文的に正しくない場合は、私の意図を確認してください。 常に表示するわけではありませんが、一部の子クラスコンストラクターは（親以外の）パラメーターを取ることに注意してください。 呼び出し元は、親を設定し、同じ親に追加する責任があります。 class Child { public Child(Parent parent) {Parent=parent;} public Parent Parent {get; private set;} } class Parent { // singleton child public Child Child {get; set;} //children private List<Child> _children = new List<Child>(); public List<Child> Children { get {return _children;} } } 欠点：親の設定は、消費者にとって2段階のプロセスです。 var child = new …

35 c#  patterns-and-practices 

どちらが優れていると考えられますか： サービスと直接やり取りするディレクティブを持つ または コントローラが動作をバインドする特定のフックを公開するディレクティブを持っていますか？

35 design-patterns  patterns-and-practices  angularjs 

私は自分のクライアントに使用し、将来一般に公開したいシンプルなAPIに取り組んでいます。異なる「タイプ」を持つことができる「アイテム」オブジェクトがあります。型はCの「typedef enum」です。 typedef enum { ItemTypeBool, ItemTypeNumber, ItemTypeDate, } ItemType; （将来、いくつか追加するかもしれません） 整数として転送するのか、定義された「文字列」として転送するのかを考えています。JSONは次のようになります。 整数の場合： { "name": "The name", "type": 0, ... } 文字列の場合： { "name": "The name" "type": "boolean" ... } これにベストプラクティスがあるかどうか疑問に思っています。整数を保持すると、コードが若干単純化され、帯域幅が削減されますが、開発者は文字列を覚えやすくなります。私はプロジェクトに取り組んだことを思い出し、1 = image、2 = audio、3 = htmlを思い出さなければなりませんでした。 あなたが私が考慮すべき他の側面を知っているなら、私はあなたに尋ねています。

32 api  patterns-and-practices  enum 

具体的には、JavaScriptで記述しています。 私の主な機能が機能Aであるとしましょう。機能Aが機能Bを複数回呼び出し、機能Bが他のどこでも使用されていない場合、機能A内に機能Bを配置するだけですか？ それは良い習慣ですか？または、関数Bを関数Aと同じスコープに配置する必要がありますか？

30 javascript  programming-practices  patterns-and-practices  encapsulation  scope 

すべてのプログラミングプロジェクトについて、過去のプログラミング経験のあるマネージャーは、プロジェクトのデザインパターンを推奨するときに輝かそうとします。理にかなっている場合、またはスケーラブルなソリューションが必要な場合、デザインパターンが好きです。たとえば、プロキシ、オブザーバー、コマンドパターンを積極的に使用してきましたが、毎日そうしています。しかし、オブジェクトを作成する方法が1つしかない場合、Factoryは将来的にすべてを簡単にする可能性がありますが、コードを複雑にし、純粋なオーバーヘッドであるため、Factoryパターンを使用することを本当にためらっています。 だから、私の質問は私の将来のキャリアと、ランダムなパターン名を投げるマネージャータイプに対する私の答えです： どのデザインパターンを使用しましたか？最悪の設計パターンはどれですか、それらが理にかなっている単一の状況を除いて考慮する必要があるものです（読んでください：どの設計パターンが非常に狭く定義されています）？（アマゾンの全体的な良い製品のネガティブなレビューを探して、デザインパターンを使用する際に最もバグを起こした人々を探しているようです。）そして、ここでアンチパターンについてではなく、通常と考えられるパターンについて話しています「良い」パターン。 編集：一部の人が答えたように、問題はほとんどの場合、パターンが「悪い」のではなく「間違って使用されている」ことです。パターンを知っていれば、それはしばしば誤用されるか、使用するのが難しい場合でも、答えとして当てはまります。

28 bad-code  anti-patterns  patterns-and-practices  design-patterns