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

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 プログラマーの典型的な見方は、私が読んで見たことから、グラフィックスをあまり上手くできない。しかし、私はプログラミング（OOP、PHP、C ++、Objective-Cが望ましい）が大好きで、Webデザインに独特の趣味を持っているという事実を否定することはできません。「ちょっと待って、私はプログラマーです。どうすればうまく設計できますか？」と思いました。質問：プログラミングと設計が得意ですか？ここの誰もが同じように感じていますか？ 記録のために：私が作成した実際の画像は、友人によって以前にプログラマーアートと呼ばれました

22 design  stereotypes 

擬似コードは、言語に依存しない方法でタスクを理解するのに役立ちます。開発ライフサイクルの一部として擬似コードを作成することは、ベストプラクティスですか、または推奨されるアプローチですか？例えば： コーディングタスクの特定と分割 擬似コードを書く [PLまたはTLによる]承認を得る 擬似コードに基づいてコーディングを開始する これは推奨されるアプローチですか？業界で実践されていますか？

22 design  pseudocode 

一部の開発者にとって、疎結合は、適切に設計されたソフトウェアの聖杯です。予測可能な将来に発生する可能性のある変更に直面してコードをより柔軟にする、またはコードの重複を回避する場合、それは確かに良いことです。 一方、コンポーネントを疎結合しようとすると、プログラム内の間接参照の量が増え、そのため複雑さが増し、理解が難しくなり、効率が低下することがよくあります。 疎結合のユースケースを使用しない疎結合（コードの重複を回避したり、近い将来発生する可能性のある変更を計画するなど）をアンチパターンと考えていますか？ゆるい結合はYAGNIの傘の下に落ちますか？

22 design  design-patterns  object-oriented 

私の会社は現在、マイクロサービスアーキテクチャの採用に取り組んでいますが、その過程で成長中の痛み（衝撃！）に直面しています。私たちが直面している主要な競合ポイントの1つは、異なるサービス間で大量のデータを通信する方法です。 ちょっとした背景として、社内全体で処理する必要があるドキュメントのリポジトリとして機能するドキュメントストアがあります。このストアとのやり取りは、クライアントに一意のIDとドキュメントをストリーミングする場所を提供するサービスを介して行われます。ドキュメントの場所は、指定されたIDを使用したルックアップを介して後でアクセスできます。 問題はこれです-すべてのマイクロサービスが、ドキュメントとやり取りする目的のために、APIの一部としてこの一意のIDを受け入れることは理にかなっていますか？私にとってこれは本質的に間違っているように感じます-サービスはもはや独立しておらず、ドキュメントストアのサービスに依存しています。これによりAPIの設計が簡素化される可能性がありますが、おそらく、パフォーマンスを改善するだけでなく、結果として得られるカップリングの利点が相殺される可能性もあります。 レインボーユニコーン（Netflix、Amazon、Googleなど）がサービス間の大きなファイル/データ交換を処理する方法を知っている人はいますか？

22 design  rest  xml  microservices 

私が読んださまざまなデザインの本では、クラスに必要なメソッドの数に重点が置かれることがあります（たとえば、JavaまたはC＃などのオブジェクト指向言語を考慮）。多くの場合、これらの本で報告されている例は非常に簡潔でシンプルですが、「深刻な」または複雑なケースをカバーすることはめったにありません。 ただし、範囲は5〜8のようです。 プロジェクトでは、属性としてTitle、Desctiption、CreateDateなどの属性を持つクラス「Note」を開発しました。次に、getRelations（メモが別のドキュメントに割り当てられている場合）、getExpiryDate、ect などの基本的なメソッドを作成しました。 ただし、アプリケーションの開発を進めるには、より多くの機能が必要であったため、より多くのメソッドが必要でした。 クラスのメソッドが少ないほど、疎結合になります。これは、モジュール性と再利用性の面で確かに優れた利点であり、さらに編集が容易です。 ちなみに、コンテキストでサブクラスを作成する必要がない場合（または感覚さえある場合）、必要なすべての関数がそのクラスに関連している場合、さらにいくつのメソッドを追加できますか？ 15を超えるメソッドを使用する場合は、少し再設計が必要になる可能性があることに同意します。しかし、その場合でも、メソッドまたは継承の一部を削除することがオプションではない場合、適切な方法はどれですか？

22 design  programming-practices 

「標準」のビジネスWebサイトを作成しようとしています。「標準」とは、このサイトが通常のHTML5、CSS、およびフロントエンド、バックエンド（ものを処理するため）用のJavaScriptを実行し、データベース用にMySQLを実行することを意味します。これは基本的なCRUDサイトです。フロントエンドは、データベースに保存されているものを何でも作成します。バックエンドは、ユーザーが入力したものをデータベースに書き込み、処理を行います。ほとんどのサイトと同じように。 コーディングを開始するためにGithubリポジトリを作成する際、フロントエンドバックエンドとAPIの違いを理解していないことに気付きました。私の質問を言い換える別の方法は次のとおりです。APIはこの図のどこに来ますか？ 私はいくつかの詳細と私が持っている質問をリストします-これがあなたに私の実際の質問が何であるかをよりよく理解してくれることを願っています。私は尋ねる特定の質問を知らないので混乱しています いくつかの詳細： Model-View-Controllerパターンを試してみたい。これにより質問/回答が変更されるかどうかはわかりません。 APIはRESTfulになります 私は私の希望私自身のAPIを使用するバックエンドをカンニングして、特別なクエリを呼び出すためにバックエンドを可能するのではなく。このスタイルはより一貫していると思います。 私の質問： フロントエンドは、APIを呼び出すバックエンドを呼び出しますか？または、フロントエンドはバックエンドを呼び出すのではなく、APIを呼び出すだけですか？ バックエンドはAPIを実行するだけで、APIはバックエンド（バックエンドが究極のコントローラーとして機能し、タスクを委任する）に制御を返しますか？ フロントエンドバックエンドとともにAPIの役割を説明する長く詳細な回答が推奨されます。答えがプログラミングのモデル（Model-View-Controllerパターン以外のモデル）に依存する場合、APIのこれらの他の考え方を説明してください。ありがとう。私はとても混乱しています。

22 design  web-development  architecture  terminology 

私は新しいビジネスWebアプリケーションを作成しています。 それぞれの領域から最高の技術を使用します。堅牢なORMを備えた信頼性の高いバックエンドフレームワークが必要です。そして、フロントエンドアプリケーションの最新のHTMLおよびJavascript機能を使用した、最も高度なSPA（単一ページアプリケーション）フレームワークが必要です。 さまざまなタイプのアプリケーション（たとえば、Webアプリケーション、モバイル（Android）、および場合によっては他のタイプ（スマートデバイスなど））から使用するバックエンドエンティティとビジネスサービスを公開します。 したがって、両方の要件を満たすために、バックエンドアプリケーションとフロントエンドアプリケーションでアプリケーションを完全に分離し、REST API（JSON）を使用してそれらの間の通信を整理する傾向があります。これは健全なアプローチですか？ 多くのWebアプリケーションテクノロジーには、サーバーサイドアプリケーションがビューの生成を多少制御し、ビューからの応答を部分的に処理するビューレイヤーが統合されているため、このような分離は明白な設計ソリューションではありません（たとえば、ビューレイヤーを持つSpringMVC、ビューを持つPHP Yii Java JSF / Faceletsは、サーバー上のコンポーネントの状態を完全に保存します）。そのため、より強力な結合を提案し、開発時間の短縮とより標準的な道のりを約束する多くの技術があります。だから-広く使われていない方法で技術を使い始めるとき、私は注意しなければなりません。 私が理解したように、完全に分離されたSPAフロントエンドは通常、サードパーティAPIを使用する必要性から生じます。しかし、バックエンドとフロントエンドの両方が1つの会社によって開発されたとき、そのようなデカップリングサウンドデザインはありますか？ 私が現在選択しているテクノロジーは、Java / Springバックエンドとフロントエンド用のAngular2 / Web Components / Polymerです。この質問は一般的な設計に関するものであり、具体的な技術の選択に関するものではないため、それはこの質問とは無関係です。

21 design  rest  api  front-end  backend 

私はリクエストを処理するプロジェクトに取り組んでおり、リクエストにはコマンドとパラメーターの2つのコンポーネントがあります。各コマンドのハンドラーは非常にシンプルです（<10行、多くの場合<5）。少なくとも20のコマンドがあり、50を超える可能性があります。 私はいくつかの解決策を考え出しました： コマンド上の1つの大きなスイッチ/ if-else 機能へのコマンドのマップ 静的クラス/シングルトンへのコマンドのマップ 各コマンドは少しエラーチェックを行い、抽象化できるビットは、各コマンドに定義されているパラメーターの数をチェックすることだけです。 この問題の最善の解決策は何ですか？また、その理由は何ですか？また、私が見逃したかもしれないデザインパターンにもオープンです。 それぞれについて、次の賛否両論のリストを作成しました。 スイッチ 長所 すべてのコマンドを1つの関数に保持します。シンプルなので、これは視覚的なルックアップテーブルになります 1か所でしか使用されない大量の小さな関数/クラスでソースを乱雑にする必要はありません。 短所 とても長い プログラムでコマンドを追加するのが難しい（デフォルトのケースを使用してチェーンする必要がある） マップコマンド->関数 長所 小さい一口サイズのチャンク プログラムでコマンドを追加/削除できる 短所 インラインで行う場合、スイッチと視覚的に同じ インラインで行われない場合、多くの機能が1か所でのみ使用されます マップコマンド->静的クラス/シングルトン 長所 ポリモーフィズムを使用して単純なエラーチェックを処理できます（3行だけですが、それでも） マップと同様のメリット->機能ソリューション 短所 多くの非常に小さなクラスがプロジェクトを混乱させます 実装がすべて同じ場所にあるわけではないため、実装をスキャンするのは簡単ではありません 追加のメモ： 私はGoでこれを書いていますが、ソリューションは言語固有のものではないと思います。他の言語でも非常に似たようなことをする必要があるかもしれないので、私はより一般的な解決策を探しています。 コマンドは文字列ですが、便利であれば、これを簡単に数値にマップできます。関数のシグネチャは次のようなものです。 Reply Command(List<String> params) Goにはトップレベルの機能があり、私が検討している他のプラットフォームにもトップレベルの機能があるため、2番目と3番目のオプションの違いがあります。

21 design  design-patterns  map  switch-statement 

私のほとんどのプロジェクトでHibernateを約8年間使用した後、私はその使用を思いとどまらせ、ストアドプロシージャを介してのみDBと対話するアプリケーションを求めている会社に行きました。 数週間これを行った後、私が構築し始めているアプリケーションのリッチドメインモデルを作成することができず、アプリケーションは（恐ろしい）トランザクションスクリプトのように見えます。 私が発見した問題のいくつかは次のとおりです。 ストアドプロシージャは最小量のデータを読み込むだけなので、オブジェクトグラフをナビゲートすることはできません。つまり、フィールドが異なる類似したオブジェクトがある場合があります。たとえば、顧客からすべてのデータを取得するストアドプロシージャと、顧客からアカウント情報といくつかのフィールドを取得するストアドプロシージャがあります。 多くのロジックは最終的にヘルパークラスになるため、コードはより構造化されます（エンティティは古いC構造体として使用されます）。 ストアドプロシージャから結果セットを抽出し、エンティティに配置するフレームワークがないため、より退屈な足場コード。 私の質問は： 誰もが同様の状況にあり、ストアプロシージャアプローチに同意しませんでしたか？あなたは何をした？ ストアドプロシージャを使用する実際の利点はありますか？「誰もドロップテーブルを発行できない」という愚かな点は別として。 ストアドプロシージャを使用してリッチドメインを作成する方法はありますか？オブジェクトグラフをナビゲートできるように、AOPを使用してエンティティにDAO /リポジトリを挿入する可能性があることを知っています。ブードゥー教に非常に近いので、このオプションは好きではありません。 結論 まず、答えてくれてありがとう。私が到着した結論は、ORMは（一部の人が述べたように）リッチドメインモデルの作成を有効にしないが、（多くの場合繰り返し）作業の量を単純化するということです。以下は結論のより詳細な説明ですが、ハードデータに基づいていません。 ほとんどのアプリケーションは、情報を要求して他のシステムに送信します。これを行うには、モデル用語で抽象化（ビジネスイベントなど）を作成し、ドメインモデルがイベントを送受信します。通常、イベントにはモデルからの情報の小さなサブセットが必要ですが、モデル全体ではありません。たとえば、オンラインショップでは、支払いゲートウェイはユーザーに請求するためにユーザー情報と合計を要求しますが、購入履歴、利用可能な製品、およびすべての顧客ベースは必要としません。そのため、イベントには小規模で特定のデータセットがあります。 アプリケーションのデータベースを外部システムとして使用する場合は、ドメインモデルエンティティをデータベースにマッピングできる抽象化を作成する必要があります（NimChimpskyが言及したように、データマッパーを使用）。明らかな違いは、各モデルエンティティのデータベース（レガシースキーマまたはストアドプロシージャ）へのマッピングを手作業で作成する必要があることです。2つは同期していないため、1つのドメインエンティティが部分的にマッピングされる可能性がありますデータベースエンティティ（たとえば、ユーザー名とパスワードのみを含むUserCredentialsクラスが他の列を持つUsersテーブルにマップされる）、または1つのドメインモデルエンティティが複数のデータベースエンティティにマップされる場合があります（たとえば、1対1の場合テーブルに1つのマッピングがありますが、1つのクラスにすべてのデータが必要です）。 エンティティが少数のアプリケーションでは、エンティティを横断する必要がない場合、追加の作業量は少ないかもしれませんが、エンティティを横断する条件付きの必要がある場合は増加します（したがって、ある種の「怠lazな」読み込み」）。アプリケーションが成長してより多くのエンティティを持つようになると、この作業は増加するだけです（そして、非線形に増加すると感じています）。ここでの私の仮定は、ORMを再発明しようとしないことです。 DBを外部システムとして扱うことの利点の1つは、アプリケーションの2つの異なるバージョンを実行し、各アプリケーションのマッピングが異なる状況を回避できることです。これは、本番環境への継続的な配信のシナリオでより興味深いものになります...しかし、これは、ORMでもそれほどではないかもしれません。 開発者は、データベースにアクセスできなくても、悪意のあるコードを挿入するだけで、システムに格納されている情報のほとんどではなくてもほとんどを取得できることに基づいて、セキュリティの側面を無視します。親愛なる主よ、顧客のクレジットカードの詳細を記録する行を削除するのを忘れたとは信じられません！）。 小さな更新（6/6/2012） ストアドプロシージャ（少なくともOracleの場合）では、テーブルの構造を変更するとプロシージャとトリガーが無効になるため、ダウンタイムがゼロの連続配信のようなことはできません。したがって、DBが更新されている間、アプリケーションもダウンします。Oracleは、このためのEdition-Based Redefinitionと呼ばれるソリューションを提供しますが、この機能について私が尋ねた少数のDBAは、実装が不十分であり、運用DBに配置しないと述べました。

21 java  design  orm  stored-procedures  domain-driven-design 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行 。 私は、この原則が何であり、言語設計にとってそれが非常に重要であるのかを理解するのに苦労しています。 基本的に、すべての式に対して expr言語の、この構造とまったく同じである必要があると述べています。 (function () { return expr; })() また、Rubyはこの原則に従うが、Pythonは従わないと聞いた。これがなぜ真実なのか、それともまったく真実なのかはわかりません。

21 design  language-agnostic 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Martin Fowlerの本「Refactoring：Improving the Design of Existing Code」が出てくる前は、コードの大きな変更を「再構築」、小さな変更を「クリーンアップ」と呼んでいました。IMO、リファクタリング技術はすべて常識であり、私たちがこれまでずっとやってきたことです。 リファクタリングは新しいものだと思いますか？おそらく、管理をtrickしてコードをクリーンアップする時間を割り当てる方法でしょうか？

21 design  refactoring  terminology 

データベースエントリ（データ）のバージョン管理を許可する方法は何ですか？ 記事の変更を元に戻すコンテンツ管理システムの機能を考えてください。 彼らの長所/短所は何ですか？

21 design  database 

私が知っているすべてのIT担当者ではないにしても、ほとんどの場合、コーディングの前にUMLまたは他のタイプのダイアグラムでソフトウェアをモデル化することが有益であると考えています。（私の質問は、特にUMLに関するものではなく、ソフトウェア設計のグラフィックまたはテキストによる説明です。） 私はそれについてはよくわかりません。主な理由は次のとおりです。コードは嘘をつかない。コンパイラーまたはインタープリターによってチェックされます。自動化されたテストがあり、静的コード分析に合格する必要があります。モジュールが別のモジュールと正しくインターフェイスしていない場合、エラーメッセージが表示されるため、通常はコードで明らかです。 このすべてを図や他のドキュメントで行うことはできません。はい、UMLをチェックするツールはありますが、これまで見てきたことはすべて非常に限られています。したがって、これらのドキュメントは不完全、一貫性のない、または単純な偽である傾向があります。 ダイアグラム自体が一貫していても、コードが実際にそれらを実装していることを確認することはできません。はい、コードジェネレーターはありますが、すべてのコードを生成することはありません。 モデリングの強迫観念は、コードが不可解に不可解な混乱であり、建築家、デザイナー、または全体像をつかむ他の有給の人々が対処する必要がないという前提から生じることに執着するように感じることがあります。そうでなければ、あまりにも高価になってしまいます。したがって、設計上のすべての決定は、コードから移動する必要があります。コード自体は、それを書くことができる（そしておそらく読むことができる）専門家（コードモンキー）に任せるべきですが、他に何も処理する必要はありません。これはおそらくアセンブラが唯一のオプションであったときに意味をなしましたが、最新の言語では非常に高いレベルの抽象化でコーディングできます。したがって、モデリングの必要性は実際にはありません。 ソフトウェアシステムをモデル化するための引数がありません。 ところで、図はソフトウェア設計の特定の側面を文書化して伝達するのに最適な方法であると考えていますが、それはソフトウェア設計をそれらに基づいて行うべきではないということです。 明確化： この質問は不明確であるとして保留されています。したがって、いくつかの説明を追加しましょう。 私は、ソフトウェア設計に関する真実の主要な情報源としてソフトウェアをモデル化する（コードではない）ドキュメントを使用することが理にかなっているかどうかを尋ねています。コードの大部分がこれらのドキュメントから自動的に生成されることを念頭に置いていません。この場合、ドキュメント自体をモデルではなくソースコードと見なします。 この手順の欠点をいくつか挙げたので、（私の経験では）なぜ多くの人がこの手順をソフトウェア設計の好ましい方法と考えているのか疑問に思います。

20 design  architecture  uml  modeling 

私は過去にこの主題について多くのことを読み、ボブおじさんのこのような興味深い講演をいくつか見てきました。それでも、デスクトップアプリケーションを適切に設計し、UI側の責任とロジック側の責任を区別することは常に非常に難しいと感じています。 優れた実践の非常に短い要約は、このようなものです。UIから切り離したロジックを設計する必要があります。これにより、どの種類のバックエンド/ UIフレームワークに関係なく（理論的に）ライブラリを使用できるようになります。これが意味することは、基本的にUIは可能な限りダミーであるべきであり、重い処理はロジック側で行われるべきだということです。別の言い方をすれば、文字通り、コンソールアプリケーション、Webアプリケーション、またはデスクトップアプリケーションで素敵なライブラリを使用できます。 また、ボブおじさんは、どのテクノロジーを使用するとさまざまなメリットが得られるか（良いインターフェース）を議論することを提案します。 ですから、この質問は非常に広範な質問であり、インターネット全体で何度も議論されてきました。そこで、何か良いものを得るために、pyqtでMCVを使用しようとする非常に小さなダミーの例を投稿します。 import sys import os import random from PyQt5 import QtWidgets from PyQt5 import QtGui from PyQt5 import QtCore random.seed(1) class Model(QtCore.QObject): item_added = QtCore.pyqtSignal(int) item_removed = QtCore.pyqtSignal(int) def __init__(self): super().__init__() self.items = {} def add_item(self): guid = random.randint(0, 10000) new_item = { "pos": [random.randint(50, 100), …

20 design  python  mvc  gui  coupling 

バックグラウンド テスト駆動開発は、私がすでに学校を卒業した後、業界で普及しました。私はそれを学ぼうとしていますが、いくつかの大きな事柄がまだ私を逃れています。TDDの支持者は、次のような多くのことを言います（以降、「単一アサーション原則」またはSAPと呼びます）。 しばらくの間、TDDテストを可能な限りシンプルで表現力豊かでエレガントにする方法について考えてきました。この記事では、テストをできる限り単純かつ分解したものにすることについて、各テストで単一のアサーションを目指して少し探ります。 ソース：http : //www.artima.com/weblogs/viewpost.jsp?thread=35578 彼らはまた、このようなことを言います（以下「プライベートメソッドの原則」またはPMPと呼ばれます）： 通常、プライベートメソッドを直接単体テストすることはありません。これらはプライベートなので、実装の詳細と考えてください。誰もそれらのいずれかを呼び出して、特定の方法で動作することを期待することはありません。 代わりに、パブリックインターフェイスをテストする必要があります。プライベートメソッドを呼び出すメソッドが期待どおりに機能している場合、拡張機能によってプライベートメソッドが正常に機能していると想定します。 ソース：プライベートメソッドを単体テストする方法 状況 ステートフルデータ処理システムをテストしようとしています。システムは、データを受け取る前の状態を考えると、まったく同じデータに対して異なることを行うことができます。システムに状態を​​構築し、特定のメソッドがテストすることを意図した動作をテストする簡単なテストを検討してください。 SAPは、「状態ビルドアッププロシージャ」をテストするべきではないことを提案します。状態はビルドアップコードから予想されるものであると想定し、テストしようとしている1つの状態変化をテストします。 PMPは、この「状態構築」ステップをスキップして、その機能を独立して制御するメソッドをテストすることはできないことを示唆しています。 私の実際のコードの結果は、肥大化し、複雑で、長く、書くのが難しいテストです。状態遷移が変更された場合、テストを変更する必要があります...これは、小さく効率的なテストでは問題ありませんが、これらの長い肥大したテストとは非常に時間がかかり、混乱を招きます。これは通常どのように行われますか？

20 design  unit-testing  tdd