ソフトウェア工学

IReaderインターフェイス、IReaderインターフェイスReaderImplementationの実装、およびリーダーからのデータを消費して処理するクラスReaderConsumerを想定しています。 public interface IReader { object Read() } 実装 public class ReaderImplementation { ... public object Read() { ... } } 消費者： public class ReaderConsumer() { public string location // constructor public ReaderConsumer() { ... } // read some data public object ReadData() { IReader reader = new ReaderImplementation(this.location) data …

15 mocking  code-smell 

ノードの配列を設定し、それらをグラフのような構造で互いに接続するクラスがあります。次のことが最善ですか： 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 

Reduxについて学びながら、God-objectパターン（またはアンチパターン）が思い浮かびました。両方とも、すべてのアプリデータとそれらを操作するメソッドを保持する単一の大きなオブジェクトを持っています。しかし、Reduxは、オブジェクトを不変にしたり、イベントを純粋な関数に厳密な署名を維持するなど、いくつかの制約を設けています。 そこで、ReduxはサニタイズしたバージョンのGodオブジェクトを使用していますか？または、Javascriptが強く型付けされた古典的なOOPではないことに関係がありますか？

15 redux 

TL; DR-サービス間でPOJOライブラリを共有しても大丈夫ですか？ 一般的に、可能な場合は、サービス間の共有を厳密に制限します。データを共有しているサービスが、クライアントが使用するクライアントライブラリを提供するかどうかについては、いくつかの議論がありました。client-libは通常、サービスのクライアントが使用するオプションであり、client-libを使用するか、代替言語を使用してライブラリなどの一般的な側面を使用するかを問わず、APIを消費できます。 私の場合、データのオブジェクトを作成するサービスを検討しています。このオブジェクトがPETであると仮定しましょう。これはデータベースエンティティではなく、厳密に基になるデータを暗黙的に表すPOJOです。このPOJOは、APIが定義したものです。想定：ペット-年齢、体重、名前、所有者、住所、種など サービス1 -PetKeeper：何らかの理由でペットを生成し、すべてのデータを保持し、このサービスを参照してペットを取得するか、ペットに変更を加え、名前の変更または住所の変更を行う必要がありますこのサービスへのAPI呼び出し。 サービス2 -PetAccessor：このサービスはペットを収集し、検証チェックを行います サービス3,4-より多くの中間サービス呼び出し サービス5-ユーザーインターフェイス これらは非常にarbitrary意的ですが、ポイントは簡単です。UIまたはユーザー向けのサービスは、何らかの方法でこの「PET」オブジェクトを提示したいと考えています。APIを介してサービスを呼び出す必要があります。サービスは、サービスを呼び出し、サービスを呼び出すなど、必要な情報を収集してリレーバックを開始するサービスに到達するまで呼び出します。最後に、UIサービスには表示するPETオブジェクトがあります。 これは非常に一般的ですが、絶対的な考え方で、すべてのサービスでPETオブジェクトを複製しました。DRY（繰り返さないでください）の原則は、サービス内のコードにのみ適用され、サービス全体には適用されませんが、ポイントはまだあります。フィールドを追加したらどうなりますか...それぞれのPOJOの5つのサービスを変更する必要があります。 -または-APIからのpojoの一部を含むPet-Objects-Libraryを提供できます。各サービスはライブラリにインポート/依存できます。サービス自体への依存関係はありませんが、一般的なライブラリのみに依存しています。各サービスが同じタイプのオブジェクトを持ち、更新が簡単になるように、私はこのアイデアが好きです。しかし、私はGod-Objectsを心配しています。 賛否両論-最適な設計は何ですか？同じPOJOクラスの繰り返しを最小限に抑えながら分離されたままにするために、サービス間でデータを渡すために何をしましたか？

15 java  dto  microservices 

C ++では、size_t（または、より正確にはT::size_type「通常」であるsize_t、すなわち、unsignedタイプ）の戻り値として使用されsize()、引数operator[]等、（参照std::vector、ら。）。 一方、.NET言語は同じ目的でint（および、オプションでlong）を使用します。実際、CLS準拠の言語は、符号なしの型をサポートする必要はありません。 .NETがC ++よりも新しいことを考えると、配列インデックスや長さのように「おそらく」負になれないものでも使用に問題があるかもしれunsigned intないということがわかります。後方互換性のためのC ++アプローチは「歴史的なアーティファクト」ですか？または、2つのアプローチの間に実際の重要な設計上のトレードオフがありますか？ なぜこれが重要なのですか？さて... C ++の新しい多次元クラスには何を使うべきですか。size_tまたはint？ struct Foo final // e.g., image, matrix, etc. { typedef int32_t /* or int64_t*/ dimension_type; // *OR* always "size_t" ? typedef size_t size_type; // c.f., std::vector<> dimension_type bar_; // maybe rows, or x dimension_type baz_; // e.g., columns, or y …

15 c#  c++  array 

次のERダイアグラムがあるとします。 ここSchoolでStudent、inの外部キーを使用して関係を表す場合、NULL値を持つことができます（a Student に属する必要はないためSchool）。たとえば、 したがって、正しい方法（読んだ内容に基づいて）は、リレーションシップを表す交差テーブルを作成することです。次に例を示します。 この方法でNULLは、表に値を含めることはできませんSchool_has_Student。 しかし、交差テーブルを作成する代わりにNULL入力可能外部キーを使用することの欠点は何ですか？ 編集： 誤って（school_id、student_id）をSchool_has_Studentテーブルのプライマリキーとして選択したため、多対多の関係になりました。正しい主キーは次のstudent_idとおりでした。

15 database  database-design  relational-database 

私の会社のいくつかのチームは、今まで見たことのないコードレビューワークフローを実践しています。会社全体の一貫性を保つことには価値があるという考えで、その背後にある考え方を理解しようとしています。（私は複数のコードベースに貢献しており、過去の違いにつまずいたことがあります。） コード作成者がプルリクエストを送信する レビュアーはコードを調べます レビュー担当者が承認すると、「よさそうだ、気軽にマージしてください」という行に沿ってコメントを残します レビューアに懸念がある場合は、「マイナーな問題XおよびYを修正してからマージしてください」などのコメントを残します（大きな変更については、手順2に戻ります） コードの作成者は、必要に応じて変更を加え、自分のプルリクエストをマージします 次の懸念事項があります。 ステップ3での承認の場合、このワークフローはプルリクエストの作成者に対して一見不必要なラウンドトリップを作成します。すでにコードを見ているレビューアは、ただちにコードをマージできます。 ステップ3で変更が要求された場合、プルリクエストをマージする機関は、PRの作成者のみに任されています。著者以外の誰も、マージする前に変更を見ません。 このワークフローのその他の長所と短所は何ですか？このワークフローは他のエンジニアリングチームで共通ですか？

15 code-reviews  pull-requests 

私は最近マイクロサービスについて多くのことを読んでいますが、これまでに得た結論のいくつかを以下に示します（私が間違っている場合は修正してください）。 マイクロサービスアーキテクチャは、ドメイン駆動型の設計に適しています。通常、1つのMSは1つの境界付きコンテキストを表します。 マイクロサービスAがマイクロサービスBにある機能を必要とする場合、私のモデルはおそらく間違っており、AとB は実際には1つのマイクロサービス/ BCである必要があります。 マイクロサービス（直接HTTPリクエスト）間の同期通信は不良であり、マイクロサービスの目的に反し、コンポーネント間の結合を導入します。 サービス間の非同期通信が望ましい。サービスはイベントをメッセージキューに発行する必要があります。これにより、他のサービスがイベントの一部をサブスクライブおよび処理したり、コンテキストを使用してデータの一部を複製したりできます。これにより、サービスは他のサービスがダウンしていても要求を処理できますが、同期通信の場合はそうではありません。 マイクロサービスAがイベントを発行し、マイクロサービスBがそのイベントをサブスクライブし、結果として新しいイベントを生成する場合、マイクロサービスAが新しく作成されたイベントを処理するものであってはなりません。この場合、3番目のマイクロサービスを導入するか、ABマイクロサービスにAとBを組み合わせます。 マイクロサービスは実際には誤解を招く用語です。私たちは小さな文脈に努めるべきですが、そうである必要はありません。用語は「マイクロサービス」ではなく、「ジョブサービスを行うのに十分な大きさ」である必要があります。 マイクロサービスにより、システム全体を壊すことを恐れることなく、より簡単に新しい機能を導入できます。新しいサービスを導入するか、既存のサービスをリファクタリングすることで実現できます。 各マイクロサービスには、独自のデータストレージが必要です。このアーキテクチャでは、データの複製/複製が望ましい動作です。 このアーキテクチャについての私の理解を確認する以外に、質問の他の部分は主にサービスの発見に関連しています。サービスが非同期で通信しており、Amazon SQSのような中央イベントキューを使用している場合、そのようなアーキテクチャではサービスディスカバリーがその場所にないということですか？ サービスは、システム内の他のサービスに関する知識を持っていてはなりません。彼らは、自分のコンテキストと、発行または購読するイベントのみを認識していますか？

15 architecture  domain-driven-design  soa  microservices 

今日、事実上すべてのC ++開発者std::vector<bool>は、それが間違いではコンテナではないため、間違いであることに同意し、その使用例はstd::bitsetとにかく重複しています。 どのようにして標準に投票されましたか？当時は物議をかもしていましたか？主な支持論拠は何でしたか？

15 c++  history  stl 

しばらくしてから、メモリアライメント、それがどのように機能し、どのように使用するかについて、多くのことを検索して読みました。私が今見つけた最も関連性の高い記事はこれです。 しかし、それでも私はまだそれについていくつかの質問があります： 組み込みシステムでは、コンピューターに大量のメモリが割り当てられていることが多く、メモリ管理の評論を減らすことができます。私は完全に最適化に取り組んでいますが、今では、同じプログラムを比較したり、メモリーの再配置と調整なしで？ メモリアライメントには他の利点がありますか？私はどこかでCPUがアライメントされたメモリでより良く/より速く動作することを読んだのですが、それは処理するための命令をより少なくします（あなたの誰かがそれに関する記事/ベンチマークへのリンクを持っている場合）、その場合、違いは本当に重要ですか？これら2つ以上の利点がありますか？ 第5章の記事リンクで、著者は次のように述べています。 注意：C ++では、構造体のように見えるクラスはこの規則に違反する可能性があります！（基本クラスと仮想メンバー関数の実装方法に依存するかどうかは、コンパイラーによって異なります。） この記事では主に構造について説明していますが、ローカル変数の宣言もこのニーズの影響を受けますか？ C ++でメモリアラインメントが正確に機能する仕組みについて、何か違いがあるように思えますか？ この前の質問には「アラインメント」という単語が含まれていますが、上記の質問に対する回答はありません。

15 c++  c  optimization  memory-usage  speed 

socket.ioを使用して最初のオンラインゲームを作成していますが、agar.ioやdiep.ioのようなリアルタイムのマルチプレイヤーゲームになりたいです。 しかし、すべてのコンピューターを同じ速度で動作させる方法を見つけようとする問題に遭遇しました。 モデルには3つのアイデアがありますが、どれも正しいとは思えません。通常のビデオゲームではどのようにそれが行われるのでしょうか。（私のアイデアを読むことをスキップできます;私が抱えている問題を見る方法を与えてくれます。） サーバーは、クライアントが自分で実行できるようにし、サーバーに更新を渡し、サーバーから残りのクライアントに更新をブロードキャストします。これには、一部のコンピューターが他のコンピューターよりも速く動作し、更新が速くなり、画面上をより速く移動できるという問題があります。 更新するタイミングをサーバーにクライアントに伝えます。次に、最後のクライアントが応答するまで待機し（ある人が遅いコンピューターを使用している場合のひどい考え）、最初のクライアントが応答するまで待機し（再び、各フレームの前に通信を待機します）、またはできるだけ早く送信します（これは、 1）と同じ問題に遭遇するようです。 ゲームの開始時に、サーバーにクライアントに更新の速さを伝えてもらいます。これは、クライアントがその期間の間の移動を制限する責任があることを意味します。たとえば、その期間内に誰かがなんとかボタンを2回押すことができた場合、ボタンを押すイベントは1つしか送信されません。これには、一部のアクション（ダブルボタンを押すなど）が無視され、サーバーのクロックと一致しない可能性のあるクライアントのクロックに相互作用が依存するという問題があります。サーバーは、各クライアントを追跡し、更新が正しい時間に送信されていることを確認する必要があります。 私はいくつかの調査を行いましたが、私が読んだ記事は、クライアントが他のクライアントよりも速く更新を送信した場合の対処方法を具体的に扱っていないようです。 私の特定のケースでは、キーボードの速度が速い人を扱っています（彼らのコンピューターは他のコンピューターよりも多くのキーボード更新を送信します）。 プログラマは通常、これにどのように対処しますか？

15 client-server  real-time 

tl; dr：シンボルの言語に依存しない定義と、他の言語でそれらを使用する理由はありますか？ では、なぜRubyの作成者symbolsは言語の概念を使用したのですか？ これは、ルビーではないプログラマーの観点からお願いします。私は他の多くの言語を学びましたが、どれにもRubyが呼んでいるものを扱っているかどうかを指定する必要があることを知りませんでしたsymbols。 主な質問は、symbolsRuby の概念はパフォーマンスのために存在するのか、それとも言語の記述方法のために必要なものなのか、ということです。 Rubyのプログラムは、PythonやJavascriptの対応物よりも軽量または高速、あるいはその両方でしょうか？もしそうなら、それは原因symbolsでしょうか？ Rubyの目的の1つは人間が読み書きしやすいことであるため、作成者はインタープリター自体に（他の言語の場合と同様に）これらの改善を実装することでコーディングのプロセスを緩和できませんでしたか？ symbolsそもそもなぜ彼らがそこにいるのかではなく、何がどのように使われているのかを誰もが知りたいようです。

15 language-design  ruby  computer-science 

GitHubリポジトリのブランチ設定を変更したばかりなので、[次の]ブランチではプルリクエストでCIビルドを渡す必要があります。 テストの失敗について、多くのチームメンバーとの議論が続きました。 コンテキストのために... リポジトリには、リリースがあるときにのみPRされる[master]ブランチがあるため、[master]には、メジャー、マイナー、ホットフィックス、ベータ、アルファ/アルファに関係なく、最後のリリース時点のコードが含まれます。プレリリースビルド。 [次の]ブランチは「デフォルト」ブランチで、「リリース準備完了」コードを保持するつもりです。技術的には、そのブランチはいつでも[マスター]にPRされ、リリースされます。 個々のフォークには独自の開発ブランチがあり、貢献者は[次へ] PRを行います。 自明ではないPRをレビューするとき、貢献者のdevブランチを「レビュー」ブランチにマージし、すぐに修正できるものを見つけたら、変更と新しい（時々失敗する）テストをコミット/プッシュし、PR貢献者の開発ブランチに戻ります。彼らが私の変更をマージするとき、新しい失敗したテストをパスさせてプッシュし、それらのPRが同期します。それからPRを[次へ]にマージします。 しかし、この質問はテストに合格することではなく、失敗するテストに関するものです。 テストに失敗すると、修正する必要があるものが文書化されます。 既知のバグにはテストが記述されている必要があります。これにより、何が機能していないかがわかります。 技術的には、GitHubの問題リスト（バグやクリティカル ラベルに対してフィルター処理されています）も同様です。バグを文書化するために多数の失敗したテストを用意することは良い習慣ですか？ [次へ]上の障害のビルドは、私たちがリリースする準備ができていないという意味では...しかし、その後、「リリース用であることは、」ビット子供を持って「準備ができている」のようなものでしょう-あなたは決してならない、非常にこのための準備ができて、何か、どこかで（変数の重要性が）リリースで必然的にうまくいかないでしょう。 したがって、合格したテストを[次へ]にプッシュするだけです。失敗したテストをどこにプッシュしますか？つまり、PR /レビュープロセスの外ですか？ たとえば、ユーザーが問題リストに新しいバグを報告し、失敗したテストスイートを作成したい-何をする必要があるか、どこで行うかを指定して、新しい貢献者がピックアップしやすくする最終的にはPRを修正します。 これらの失敗したテストをどこにプッシュすればよいですか？または、失敗したテストをどこかにプッシュすることをお勧めしますか？

15 unit-testing  git  teamwork  continuous-integration 

なぜ：nth-​​child（）はゼロではなく1から反復するのですか？ この例に示すように。なぜ2番目ではなく最初の要素を選択するのですか？ p :nth-child(1)

15 html  css  web-design 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 閉じた3年前。 同等のテストはフロート変数では信頼できないが、整数では問題ないことを生徒に説明しました。私が使用している教科書では、> =と<=よりも>と<の方が読みやすいと述べています。ある程度は同意しますが、Forループでは？ループで開始値と終了値を指定する方が明確ではありませんか？ 教科書の著者が正しいと思うものがありませんか？ 別の例は、次のような範囲テストです。 スコア> 89グレード= 'A'の 場合スコア> 79グレード= 'B'の場合... なぜ単に言わないのですか：スコア> = 90の場合？

15 loops