ソフトウェア工学

ASP.Net Coreでは、Claims認証は具体的な方法ではないことがわかりました。我々は、何も追加することができますClaimTypeし、ClaimValueペアを。groups、firstname、lastname、brithdate、canAccessThisURI、isEditorなどです。ただし、この方法（クレームとして保存できるものはすべて保存）では、アプリケーションデータの50％を含む巨大なクレームテーブルが作成されます。 良い方法として、クレームとして保存する必要がある一般的なデータは何ですか？

9 c#  .net  identity  asp.net-core  .net-core 

私が読んだ本のデザインパターンについてのページを、そしてあなたのコードを書くときに、どのようにそれらを扱う必要があります。私の理解から、リンクのタイトルは次のように述べています： パターンはビルディングブロックではありません。 私が正しく理解していれば、これは意味があるまでデザインパターンを使用しないことを意味しますよね？戦略パターンを使用するつもりだと言って始めないでください。コードを書くまで待ってください。戦略パターンを使用することが設計に意味がある場合は、それを使用してください。 GUIアプリケーションを作成するとき、MCV / MVPパターンを同じように扱いますか？それぞれのリンクから、それは建築パターンであると述べています。 GUIアプリケーションを作成し、MCV / MVPパターンを使用していなくても、コードがクリーンで、読みやすく、保守可能である場合、MCV / MVPパターンを使用しなかったのは、コードのにおい/悪い設計であると想定します。 ？

9 design-patterns  mvc  mvp 

PHP、C＃、Python、およびおそらく他のいくつかの言語には、yieldジェネレーター関数の作成に使用されるキーワードがあります。 PHPの場合：http : //php.net/manual/en/language.generators.syntax.php Pythonの場合：https : //www.pythoncentral.io/python-generators-and-yield-keyword/ C＃の場合：https : //docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/yield 言語の機能/機能として、yieldいくつかの規則に違反していることを心配しています。それらの1つは、「確実性」と呼んでいるものです。呼び出すたびに異なる結果を返すメソッドです。通常の非ジェネレーター関数を使用してそれを呼び出すことができ、同じ入力が与えられた場合、同じ出力を返します。yieldでは、内部状態に基づいて異なる出力を返します。したがって、以前の状態を知らないで生成関数をランダムに呼び出すと、特定の結果を返すことは期待できません。 このような関数はどのように言語パラダイムに適合しますか？それは実際に慣習に違反していますか？この機能を使用することは良い考えですか？（良い点と悪い点の例を示すために、gotoかつては多くの言語の機能でしたが、現在もそうですが、それは有害であると見なされ、Javaなどの一部の言語からは根絶されました）。プログラミング言語のコンパイラ/インタープリターは、そのような機能を実装するために何らかの規則を破る必要がありますか？たとえば、言語はこの機能を動作させるためにマルチスレッドを実装する必要がありますか、それともスレッド化テクノロジなしで実行できますか？

9 programming-languages  language-agnostic  language-design  language-features 

でブログ記事のこのシリーズ、エリックリッペルトは、ウィザードとの例として、戦士を使用して、オブジェクト指向設計における問題点を説明します。 abstract class Weapon { } sealed class Staff : Weapon { } sealed class Sword : Weapon { } abstract class Player { public Weapon Weapon { get; set; } } sealed class Wizard : Player { } sealed class Warrior : Player { } 次に、いくつかのルールを追加します。 戦士は剣しか使用できません。 ウィザードはスタッフのみを使用できます。 次に、C＃型システムを使用してこれらのルールを適用しようとすると発生する問題（たとえばWizard、ウィザードがスタッフのみを使用できることをクラスに責任を持たせるなど）を示します。Liskov置換原則に違反したり、ランタイム例外のリスクを冒したり、拡張が困難なコードを作成したりする。 …

9 c#  design-patterns  object-oriented  solid 

私は3つの基本的な手順を含む多くのコードを記述しています。 どこかからデータを取得します。 そのデータを変換します。 そのデータをどこかに置きます。 私は通常、それぞれの設計パターンに触発された3種類のクラスを使用します。 ファクトリー-あるリソースからオブジェクトを構築します。 メディエーター-ファクトリーを使用するには、変換を実行してから、司令官を使用します。 司令官-そのデータを別の場所に配置します。 私のクラスは非常に小さく、多くの場合単一の（パブリック）メソッドです。たとえば、データの取得、データの変換、作業の実行、データの保存などです。これはクラスの急増につながりますが、一般的にはうまく機能します。 私がテストに来るときに苦労しているのは、結局は密結合テストになります。例えば; 工場-ディスクからファイルを読み取ります。 Commander-ファイルをディスクに書き込みます。 もう1つがないとテストできません。ディスクの読み取り/書き込みを行うための追加の「テスト」コードを作成することもできますが、それから繰り返します。 .Netを見ると、Fileクラスは別のアプローチをとっており、（私の）ファクトリーとコマンダーの責任を組み合わせています。Create、Delete、Exists、Readの機能がすべて1か所にあります。 .Netの例をたどって、特に外部リソースを扱う場合は、クラスを一緒に結合する必要がありますか？結合されたコードですが、意図的です。テストではなく、元の実装で発生します。 ここでの問題は、単一責任の原則をやや熱心に適用したことですか？読み取りと書き込みを担当する個別のクラスがあります。特定のリソース（システムディスクなど）の処理を担当する結合クラスがある場合。

9 design  clean-code  single-responsibility 

最近、抽象クラスの使用について困っています。 時々、抽象クラスが事前に作成され、派生クラスがどのように機能するかのテンプレートとして機能します。つまり、多かれ少なかれ、それらはいくつかの高レベルの機能を提供しますが、派生クラスによって実装される特定の詳細を除外します。抽象クラスは、いくつかの抽象メソッドを配置することにより、これらの詳細の必要性を定義します。そのような場合、抽象クラスは設計図、機能の高レベルの説明、またはそれと呼ぶもののように機能します。単独では使用できませんが、高レベルの実装から除外された詳細を定義するために専門化する必要があります。 場合によっては、いくつかの「派生」クラスの作成後に抽象クラスが作成されることがあります（親/抽象クラスがそこにないため、それらはまだ派生されていませんが、私が何を意味するか知っています）。これらの場合、抽象クラスは通常、現在の派生クラスに含まれるあらゆる種類の共通コードを配置できる場所として使用されます。 上記の観察をしたので、私はこれらの2つのケースのどちらがルールであるべきか疑問に思っています。派生クラスすべてに共通しているという理由だけで、抽象クラスに詳細を吹き込む必要がありますか？高レベルの機能の一部ではない一般的なコードがありますか？ たまたま派生クラスに共通しているからといって、抽象クラス自体には意味がないコードが存在する必要がありますか？ 例を挙げましょう。抽象クラスAにはメソッドa（）と抽象メソッドaq（）があります。メソッドaq（）は、派生クラスABとACの両方で、メソッドb（）を使用します。b（）をAに移動する必要がありますか？もしそうなら、誰かがAだけを見ている場合（ABとACがそこにないふりをしよう）、b（）の存在はあまり意味がありません！これは悪いことですか？誰かが抽象クラスを見て、派生クラスにアクセスせずに何が起こっているのかを理解できる必要がありますか？ 正直なところ、この質問をしている時点で、派生クラスを調べなくても意味のある抽象クラスを書くことは、クリーンなコードとアーキテクチャの問題だと信じがちです。anyあらゆる種類のコードのダンプのように機能する抽象クラスのアイデアが、すべての派生クラスで一般的に発生するのを嫌う あなたはどう思いますか/練習しますか？

9 object-oriented  clean-code  abstract-class 

最近、私が使用するいくつかの大きなC＃コードベースの周りに浮かぶいくつかのヘルパースタイルの「ユーティリティバッグ」静的クラスを確認していました。 // Helpers.cs public static class Helpers { public static void DoSomething() {} public static void DoSomethingElse() {} } 私がレビューした特定の方法は 主に互いに無関係です 呼び出し間で持続する明示的な状態なしで、 小さい、そして それぞれが、関連のないさまざまなタイプによって消費されます。 編集：上記は申し立てられた問題のリストを意図したものではありません。これは、私が検討している特定のメソッドの一般的な特性のリストです。回答がより関連性の高いソリューションを提供するのに役立つコンテキストです。 この質問のためだけに、この種のメソッドをGLUM（一般的な軽量ユーティリティメソッド）と呼びます。「glum」の否定的な意味合いは部分的に意図されています。これが馬鹿げた言い回しとして出くわしたらすみません。 GLUMについての私自身のデフォルトの懐疑論はさておき、私はこれについて以下のことを好きではありません。 静的クラスは名前空間としてのみ使用されています。 静的クラス識別子は基本的に無意味です。 新しいGLUMが追加されると、（a）この「バッグ」クラスは理由もなく触れられるか、または（b）新しい「バッグ」クラスが作成されます（通常、それ自体は問題ではありません。悪いのは、新しい静的クラスは多くの場合、無関係な問題を繰り返すだけですが、メソッド数は少なくなります）。 メタ命名は、それはだかどうか、必然的に、ひどい非標準、通常は内部的に矛盾しているHelpers、Utilitiesまたは何でも。 これをリファクタリングするための合理的に良い＆単純なパターンは何ですか？ 私はおそらく強調する必要があります：私が扱っているすべての方法は、互いにペアで関係がありません。それらをよりきめ細かく、それでもマルチメンバーの静的クラスのメソッドバッグに分解するための合理的な方法はないようです。

9 c#  design-patterns 

新しいソフトウェア開発プロジェクトでStructureMapを使用しています。チームメンバーの1人が、基本的にStructureMapコンテナー構成をテストする単体テストを実装しました。これを行うには、次のようにします。 アプリケーションの名前空間のクラスに構成されているアセンブリのインスタンスの数をカウントします。 クラスレベルで予期されるインスタンスを定義します 予想されるインスタンスが見つかったインスタンスの総数と一致することを表明します。 予想されるインスタンスがテストで定義されたインスタンスと一致することを表明する この例は次のとおりです。 var repositories = container.GetAllInstances<IEnvironmentRepository>(); Assert.AreEqual(1, repositories .Count()); foundInstances = foundInstances + repositories .Count(); 次のクラスの「単体テスト」もあります。 public MyClass(IEnvironmentRepository environmentRepository) { } これらのテストでは、IEnvironmentRepositoryをモックしているため、ライブシステムで発生するようなコンテナーからの注入は行いません。 同僚は、「ユニットテストはそれ自体の構成のみをテストする」というコメントを付けて、structuremap configのユニットテストを無視しました。これは明らかにテストの目的であり、私の意見では完全に有効です。テストを無視した人に構造テストの構成を削除してIEnvironmentRepository（テストはまだ無視されています）、完全な単体テストスイートを実行するように依頼したところ、すべて成功しました。次に、アプリケーションを実行しましたが、コンテナー構成が無効になったため、アプリケーションが倒れました。私の意見では、これはテストの価値を証明しました、私の同僚はまだ反対しました。彼は単に構成をテストするべきではないと述べましたが、これは単体テストの範囲内であると私は思います。 したがって、いくつかの質問があります。 それは有効な単体テストですか？ストラクチャマップが機能するのではなく、コンテナの構成をテストしています（ただし、重複が確認できます） そうでない場合、テストせずに構成を検証するにはどうすればよいですか。誰かが誤って必要なコード行を削除してチェックインしないようにするにはどうすればよいですか？ なければならないMyClassユニットテストは、のインスタンスを解決IEnvironmentRepositoryコンテナからとでこれを渡しますか？

9 c#  unit-testing 

背景： EBMLファイルを書き込むマイクロコントローラーCコードを書いています。EBMLは要素がネストされたバイナリXMLに似ていますが、開始タグと終了タグの代わりに、開始ID、長さ、そしてデータがあります。低電力アプリケーションの外部フラッシュにこれを書き込んでいるので、フラッシュアクセスを最小限に抑えたいと思います。決して簡単なことはないので、メモリも制限されます。 EBML要素全体をメモリに保持できる場合、その長さがわかったら、各要素の長さに戻って入力できるため、生成は簡単です。問題は、要素全体をメモリに保持できない場合の対処方法です。私が見るオプションは： 私が知っていることを書いてから、戻って長さを追加します（最も簡単ですが、必要以上にフラッシュアクセスを追加します） 書き始める前に各要素の長さを計算します（比較的簡単ですが、プロセッサ時間は長くなります） メモリがいっぱいになったらモードを切り替えて、データを調べ続けますが、すでにメモリに予約されている要素の長さを計算するだけです。次に、メモリにあるものを書き込み、戻って、中断したところからデータの処理を続けます。（これまでのところ私のお気に入りのオプション） 要素を書き込む必要があり、最終的な長さがまだわからない場合は、要素に最大または最悪の場合の長さを指定します。（上記より簡単ですが、裏目に出てスペースを無駄にする可能性があります） 質問：これは、人々が考えていた比較的一般的な問題であるように思われます。一部のデータパケットを形成するときにも発生する可能性があることを知っています。私がここで見逃している/より一般的/より受け入れられたより良いテクニックはありますか？または、私が検索できる問題のいくつかの用語？

9 design-patterns  c  file-handling  arm  firmware 

私の会社はWebアプリケーションをゼロから書き直しています。これは、金融業界で複雑なドメインを持つ大規模なエンタープライズレベルのアプリケーションです。 永続化のためにORM（エンティティフレームワーク）を使用しています。 本質的に、アプリケーションの半分はユーザーから生データを収集して保存することに集中しており、実際のドメインロジックのほとんどを含むアプリケーションの残りの半分はその生データを使用して、元のデータとは大きく異なるドメイン画像を作成します生の入力、およびそれを計算エンジンに渡し、計算を実行し、結果を吐き出し、ユーザーに表示します。 レイヤーを使用したDDDアプローチでは、CRUD操作がドメインレイヤーを通過するように見えます。しかし、少なくとも私たちの場合、これは意味をなさないようです。 たとえば、ユーザーが編集画面に移動して投資口座を変更した場合、画面のフィールドはデータベースに保存されているフィールドそのものであり、後で計算に使用されるドメイン表現ではありません。では、編集画面でデータベース表現（生の入力）が必要なときに、なぜ投資口座のドメイン表現を読み込むのでしょうか。 ユーザーが投資口座画面で[完了]をクリックし、コントローラーに対してPOSTが実行されると、コントローラーには、保存する必要のある投資口座のほぼ正確なデータベース表現が表示されます。しかし、何らかの理由で、コントローラーのモデルをデータベースモデル（エンティティフレームワークモデル）に直接マッピングするのではなく、ドメイン表現をロードして変更を加えることになっていますか？ つまり、本質的には、データモデルをドメインモデルにマッピングします。これにより、永続化するためにデータモデルにマッピングし直すことができます。それはどういう意味ですか？

9 design-patterns  object-oriented-design  domain-driven-design  enterprise-architecture 

私は現在、キュウリのようなBDDテストフレームワークを調査しています。 機能ファイルはシンプルな自然言語で記述されているため、わかりやすさが向上し、明確なビジョンが得られます しかし、自然言語は、ソフトウェアエンジニアリングで発生する問題のほとんどの原因ではありませんか？ 自然言語があいまいであり、それがクライアントの要件の誤解と開発者の理解のために多くのソフトウェアプロジェクトが失敗する理由です。私はここでニッチを取得しません。 はい、テストを小さな単純で実行可能なアクションに分解することは理にかなっており、ある程度の明快さを提供しますが、全体として生産性を向上させますか？ PS：私は専門家ではないので、ここでは意見を述べていません。私はその概念を理解したいだけです。

9 bdd  cucumber 

ソリューションの開発中は、少なくとも3つの異なる環境が必要です。 開発：プログラマはいつでも自由に変更を加えて変更をプッシュし、コードをすばやくテストして他の変更と統合することができます。何も壊す恐れはありません。これはTESTデータベースとサービスに接続されています。 UAT：ハードウェアに関する本番環境の「できるだけ良い」コピーが含まれている必要があるため、開発者は敬意を持って扱う必要があります。ただし、この環境は本番データの編集可能なコピーでUATデータベースに接続されている点が異なります。 Q＆Aチームとユーザーの両方が、本番環境への変更を検証するために使用します 生産：本当の取引。 私はに見てきたソフトウェア工学にこの質問、およびServerFaultの上でこの質問、および彼らがステージング環境の意味は何に異なるように見えます。また、主題に関するウィキペディアのページには、次のように述べられています。 ステージング環境の主な用途は、本番環境に適用する前に、すべてのインストール/構成/移行スクリプトと手順をテストすることです。これにより、本番環境へのすべてのメジャーアップグレードとマイナーアップグレードが、エラーなしで、最小限の時間で確実に完了します。 私にとって、ステージングは​​UATと同じです。UATでは、現実の世界に移行する前に、アプリケーションと展開の手順をテストする必要があります。そのため、本番環境にプッシュするのと同じ方法でUATに変更を加えてパッケージをプッシュします。完全に自動化され、本番環境で必要なすべてのセレモニーが行われます。 とはいえ、UAT環境とステージング環境の適切な違いは何ですか？ - 編集：明確にするために、私はインターネットアプリケーションでもイントラネットウェブサイトでも、Webアプリケーションの観点から考えています。「フォーム」アプリやモバイルアプリはありません。

9 web-applications  continuous-delivery  environment 

正規表現のサービス拒否（ReDoS）を知っています。ユーザーが指数関数的に遅いパターンを送信しないことを保証しながら、ユーザーがカスタム正規表現を作成できるようにする合理的な方法はありますか？

9 regular-expressions 

私は自分のプロジェクトにtestsユニットテストではないコードをいくつか持っています。これらは実行することを意図しており、結果は人間が評価する必要があります。これは、物理エンジンを作成していて、開発中に自分が何をしているかを確認する必要があったためです。それでsimulation、テストモジュールでパッケージを作成しました。シミュレーションはユニットテストライブラリを使用しているため、技術的にはユニットテストですが、実際のユニットテストのようにすべてを実行するわけではありません。 すべての単体テストを簡単に実行したいので、これらの特別なテストを単体テストと区別します。機能テストに少し似ていると思います。アプリケーションを機能テスト用に準備しなければならないケースに遭遇したことがありますか？その機能テストの準備（基本的には私のシミュレーション）はプロジェクトのどこに配置し、ユニットテストとどのように区別するのですか？ 私はJavaを使用しているため、すべてのメソッドシグネチャをから@Test public void myNamedTest()に変更できpublic static void main(String[] args)ますが、シミュレーションを使用するのは面倒で実用的ではありません。 プロジェクトで使用junitしていgradleます。で特別なテストフォルダを作成するソリューションgradleは大歓迎です。

9 java  unit-testing  testing  functional-testing  gradle 

長いメソッドは一般的に悪いと考えられていますが、私のコードには理解しにくい長いメソッドがあります（50行以上）。内部の単一のステートメントはすでに50行を超えているため、これらのメソッドを読みやすくするのに苦労しています。その単一のステートメントを読み取るのは、ORMを使用してデータベースクエリを作成し、特定のジョブを実行することです。メソッド名に明記。ステートメントが複数の列に結合し、複数のwhereを適用し、複数の異なる列を選択して必要な文書化された出力形式を作成するため、ステートメントが非常に長い理由。 そのような読みにくいコードは悪いコードと見なされますか？同様に、複雑なアルゴリズムのコードを記述して、明確に名前が付けられたメソッドでラップされた読みにくいコードを生成した場合、そのコードは悪いコードですか？

9 readability