ソフトウェア工学

システム開発ライフサイクル内で働く専門家、学者、学生向けのQ&A

1
C#の知識がなくても深刻なF#プロジェクトにアプローチするにはどうすればよいですか?
したがって、基本的に私が着手したいプロジェクトはSVGエディターです。アプリケーションレイアウトにXAMLを活用できるため、WPFを使用することをお勧めします(デザイナーは気の利いたものです)。残念ながら、私は.NETフレームワークをほんの数か月しか使用していませんが、ほとんどのクラス名にはまだ馴染みがありません。 F#は関数型プログラミング言語であり、F#の再帰と素晴らしいリスト操作とタプルを組み合わせることで、F#を使用することが目標でした。そして、目標は、使用可能なドキュメント化されたクラスの膨大なライブラリとサンプルを備えた.NETを使用することです。 私はすでにこの質問を見ました。/software/3129/is-there-a-canonical-book-on-f しかし、答えは一般にF#に対するものであり、すでにC#を知っていると仮定しています。 。 上記の質問に対する答えとしてのトップブックは、実世界の関数型プログラミング:F#およびC#の例を使用したものでした。ただし、この本のAmazonの3つ星レビューは、かなり厳しく、おそらく誇張されているものの、私の問題を正しく示しています。 関数型プログラミングに興味があるが、F#を学習しようとしているC#ではない場合は、この本を安全にスキップできます。 私はオンラインでWPF F#の例を探しましたが、あちこちにさまざまなコードスニペットがありますが、単一のファイルスクリプト.fsxの外で使用されていることや、それが実際にエンタープライズレベルまたは少なくともプロフェッショナルレベルでさえ使用されていないことを示しています。 そのため、Microsoftでさえ、F#で.NETを実行する方法について多くの例がありません。私が見つけた例は通常、F#に固有の機能のみです。F#の基本セクションと高度なセクションを見てください。構文を教えているだけで有罪であることがわかります。たとえば、LineクラスのWPFのMSDNには、F#のコード例はありません。 F#のコードサンプルタブを下にスクロールすると、 No code example is currently available or this language may not be supported. 使用可能なコード例が非常に少ないため、このプロジェクトに着手するのは難しいと感じています。 私の質問 は、C#があまりよくわからないときにF#を使用してこのプロジェクトに取り組む方法を理解するのに役立ちます。
11 wpf  f# 

3
強制的なコードレビューの適切なガイドラインと実践[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 コミットごとに必須のコードレビューを試行しています。作成者ではなく、少なくとも1人が検証していないマスターは何もありません。開発者と管理者の両方から賛同を得ています(これは驚くべき状況です)。 明らかなバグの削減 プロジェクトの周りで起こっている変化についてのより多くの認識 「誰かがこれを見て、怠けないようにする」/反カウボーイ効果 プロジェクト内/プロジェクト間の一貫性の向上 しかし、速度を低下させることが知られているものを導入しており、間違ってやるとコミットパイプラインに愚かな官僚的なステップができてしまい、時間がかかります。私が心配していること: 単なるピッキングに発展するレビュー (双曲線的に)2行のコミットレビューの一環として、巨大なアーキテクチャの問題を公開する人々。 答えに他のことを偏らせたくありません。 私たちはすべて合理的な人であり、多くの自己分析を行っていますが、レビューセッションで実際にどのようなことを達成しようとしているかについて、戦いで得た洞察を間違いなく使用して、レビューを実際に機能させることができます。動作することがわかっているガイドラインとポリシーは何ですか?

3
ハードコードされたオブジェクトでメソッドをモックする方法は?
私は複数のレイヤーを持つアプリケーションに取り組んでいます。データソースからデータを取得して保存するデータアクセスレイヤー、データを操作するビジネスロジック、画面にデータを表示するユーザーインターフェイス。 ビジネスロジックレイヤーの単体テストも行っています。唯一の要件は、ビジネスレイヤロジックのフローをテストすることです。そこで、Moqフレームワークを使用してデータアクセスレイヤーをモックし、MS Unitでビジネスロジックレイヤーを単体テストします。 インターフェイスプログラミングを使用して、ユニットテストを実行できるように、設計を可能な限り分離します。インターフェイスを介したビジネスレイヤコールデータアクセスレイヤ。 ビジネスロジックメソッドの1つをテストしようとすると、問題に直面しています。このメソッドはいくつかの作業を行い、オブジェクトを作成してデータアクセスレイヤーに渡します。そのデータアクセスレイヤーメソッドをモックしようとすると、正常にモックできません。 ここでは、問題を示すデモコードを作成しようとしています。 モデル: public class Employee { public string Name { get; set; } } データアクセス層: public interface IDal { string GetMessage(Employee emp); } public class Dal : IDal { public string GetMessage(Employee emp) { // Doing some data source access work... return string.Format("Hello {0}", emp.Name); …

5
2つの曲線の特徴を比較する方法は?
2つの曲線f(x)とg(x)を比較する必要があります。それらは同じxの範囲にあります(たとえば、-30から30)。f(x)には、鋭いピークまたは滑らかなピークと谷がある場合があります。g(x)は、同じピークと谷を持つ場合があります。もしそうなら、私はこれらの機能が目視検査なしでどれくらいうまく一致するかについての測定が欲しいです。この問題を次の方法で解決しようとしました。 各データポイントを関数の総面積で除算して、両方の関数を正規化します。正規化された関数の面積は1.0です 各xで、f(x)とg(x)から最小値を取得します。これにより、基本的にf(x)とg(x)の重複領域である新しい関数が提供されます。 ステップ2の結果の関数を統合すると、1.0から合計重複領域が得られます しかし、これは山と谷が一致するかどうかを教えてくれません。これができるかどうかはわかりませんが、誰かが方法を知っているなら、あなたの助けに感謝します。 ==編集==説明のために、画像を含めました。 2つの曲線(黒と青)の違いは同じではないかもしれませんが、補完的な形状になります。 背景:関数は、化合物の原子軌道の投影状態密度(PDOS)です。s、p、d軌道の状態があります。材料にsp、pd、またはddハイブリダイゼーション(軌道混合)があるかどうかを判断したい。私が持っている唯一のデータはPDOSです。s軌道(関数f(x))のPDOSが、p軌道(関数g(x))のPDOSと同じエネルギー(x値)のピークと谷を持っているとすると、その材料にはsp混合があります。
11 geometry 

2
雇用主固有の変更を伴うオープンソースプロジェクトで作業するための最高のGitワークフローは何ですか?
私の現在の雇用者では、Githubでホストされているオープンソースプロジェクトをアプリケーションのコンポーネントとして使用しています。私はこのプロジェクトに取り組んでおり、必要な機能を追加したり、ビルドシステムと統合したりしています。私のマネージャーと私は、このコンポーネントに関する作業を、オープンソースプロジェクトに合理的な範囲で提出することに同意します。私の質問は、オープンソースプロジェクトに追加する意味のあるもの-バグ修正と十分に一般的な新機能-を簡単に分離できるように、Gitコミットを維持するための最良のワークフロー/テクニックについてです。ビルドの場所やアプリケーションの定数など、プロジェクトに固有のものから。 これまで行ってきたことは、適切な粒度ですべての変更をコミットするプライベートGitブランチを維持することです。次にcherry-pick、オープンソースのコミットをmasterブランチに追加し、Githubに送信します。 私はこれを行うためにマージを使用する必要があるようです。そのため、同じ内容の個別のコミットを作成し続けることはできませんが、会社固有のコミットを除外して合理的なワークフローを維持しながらこれを行う方法はわかりません。 たとえば、マスターでオープンソース可能なものとプライベートブランチで会社固有のものをコミットし、必要に応じてマスターをそのブランチにマージし、マージ前にマスターブランチがコミットを指すようにして、オープンソース可能なものを再度コミットしてから、再度マージします。このワークフローで厄介なように思えるのは、どのブランチに属しているかを行うすべてのことを事前に決定し、完了したと思われるものに取り組んでから、テストしてからコミットしてマージする必要があることです。Gitで私が本当に気に入っていることの1つは、アプリケーションを機能させるために必要なことを何でもすることが簡単で、後で変更をコミットする方法と場所を決めることです。私が知る限り、あなたが現在ブランチにいて、何らかの作業を行っている場合、 私は長期的な貢献のために合理的なワークフローを行っていますか?誰かがより良いかもしれない別のワークフローを推奨できますか?なぜそれが良いですか?
11 git 

1
MVC + 3層; ViewModelsが登場する場所
ASP.NET MVC 4を使用して3層アプリケーションを設計しています。次のリソースを参照として使用しました。 CodeProject:MVC + N層+エンティティフレームワーク ASP.NET MVCでのデータアクセスの分離 これまでに次のようなデザインがあります。 プレゼンテーション層(PL) (メインMVCプロジェクト、MのMVCは、データアクセス層に移動されました): MyProjectName.Main Views/ Controllers/ ... ビジネスロジックレイヤー(BLL): MyProjectName.BLL ViewModels/ ProjectServices/ ... データアクセス層(DAL): MyProjectName.DAL Models/ Repositories.EF/ Repositories.Dapper/ ... 現在、PLはBLLを参照し、BLLはDALを参照しています。このように、下層は上の層に依存しません。 この設計では、PLはBLLのサービスを呼び出します。PLはビューモデルをBLLに渡すことができ、BLLはビューモデルをPLに戻すことができます。 また、BLLはDALレイヤーを呼び出し、DALレイヤーはモデルをBLLに戻すことができます。BLLは、ビューモデルを作成してPLに返すことができます。 今まで、このパターンは私のために働いていました。ただし、ViewModelsのいくつかがいくつかのエンティティで結合する必要があるという問題に遭遇しました。プレーンMVCアプローチでは、コントローラーでjoinsを実行してからを実行するためにLINQクエリを使用しましたselect new MyViewModel(){ ... }。しかし今、DALでは、ViewModelが定義されている場所(BLL内)にアクセスできません。 これは、DALで参加してBLLに戻すことができないことを意味します。(1つのクエリでの結合の代わりに)DALで個別のクエリを実行する必要があり、BLLはこれらの結果を使用してViewModelを構築します。これは非常に不便ですが、DALをViewModelに公開する必要はないと思います。 このジレンマを解決する方法はありますか?ありがとう。

5
コードの繰り返しと複数の責任がある方法
私は単一責任原則(SRP)に準拠し、コードの繰り返しを省略しようとします。しかし、少なくとも意味のある名前付きメソッドへの抽出に抵抗する呼び出しのコードブロックにすぎないコードの繰り返しがある場所がしばしばあります。 DoAction1(); DoAction2(); if (value) DoAction3(); DoAction4(); そのようなコードをメソッドに抽出する最良の方法とその命名方法は何ですか?

2
リファクタリングコメント付きのコードを広めることは良い考えですか?
私は「スパゲッティコード」プロジェクトに取り組んでおり、バグを修正して新しい機能を実装している間、コードをユニットテスト可能にするためにリファクタリングも行っています。 コードはしばしば非常に密結合または複雑であるため、小さなバグを修正すると多くのクラスが書き直されます。そこで、リファクタリングを停止するコードのどこかに線を引くことにしました。これを明確にするために、次のような状況を説明するコメントをコードにいくつか落とします。 class RefactoredClass { private SingletonClass xyz; // I know SingletonClass is a Singleton, so I would not need to pass it here. // However, I would like to get rid of it in the future, so it is passed as a // parameter here to make this change …

1
yieldキーワードがreturnとbreakと共に使用され、それ自体では使用されないのはなぜですか?
C#では、あなたは、戻り値の型を持つメソッド構築することができますIEnumerable<T>し、使用をyield returnしてyield break流れを制御します。両方のコントロールを使用する簡単な例を次に示します。 public IEnumerable<int> GetEvens(int start, int end) { if(end < start) yield break; if(start & 2 != 0) start++; for(int i = start; i <= end; i+=2) { yield return i; } } 私の質問は、もともと次のように2つのキーワードをyield使用し、単一のyield「戻り値を返す」ように使用しないように設計されていた理由です。 public IEnumerable<int> GetEvens(int start, int end) { if(end < start) return; // stop completely …
11 c# 

2
ネストされた静的ライブラリの依存関係は可能ですか?
私はQTで働いています。 静的ライブラリは別の静的ライブラリに依存できますか?(静的ライブラリは別の静的ライブラリをリンクすることで作成されます) はいの場合、lib2にリンクした後、生成されたlib(lib1)にlib2のすべてのコードが含まれない可能性はありますか? 私のQtプロジェクトでは、複数のライブラリに依存する静的ライブラリを使用しています。すべてのライブラリ(プロジェクト内のすべてのヘッダーを含む)を追加する必要がありましたが、コードに必要なのは1つのlib(およびそのクラスの1つの.h)だけです。 シナリオを説明してください。
11 c++  qt  static-linking 

3
.NETでCILとCLRが必要なのはなぜですか?
ここでこの素敵な画像を見ました。.net言語をサポートするすべてのコンパイラがソースコードをCILフォーマットに変換することを学びました。現在、Microsoftは.NET、すべてのオペレーティングシステム用のCLRを作成して、すべてのオペレーティングシステムを導入することはありません。次に、そのような中間コード形式とそのCILを実行するためのCLRを保持する理由。それは対処する頭痛ではありません。なぜマイクロソフトはこのように選んだのですか? 編集このちょっとしたアーキテクチャには価格があります。パフォーマンスが低下しますか?Javaはプラットフォームの独立性を維持するためにこれを行いますが、どのような理由で.NETがそれを行いますか?コンパイラのような単純なプレーンなCを保持しないのはなぜですか。また、新しい言語を追加する必要がある場合、どのような方法でもコンパイラーがコードをCILに変換する必要がありますが、唯一の違いはターゲット言語です。Tat's all。
11 .net 

1
複数のリポジトリにまたがるプロジェクトのGitHub組織?
GitHubで少なくとも3つのリポジトリを含むプロジェクトを開始しました。 リポジトリの1つは、一般的なドキュメントとサンプルのダンプであり、他の2つのリポジトリには、プロジェクトのバックボーンを形成する2つのプログラムの実装が含まれています。 このような構成を処理するためにGitHub組織を使用する必要がありますか?または、完全に無関係な他の12個のリポジトリとともに、すべてを自分のアカウントにすべてダンプする必要がありますか?

2
SQL Server Data Tools&Entity Framework-ここに相乗効果はありますか?
Linq2Sqlを使用したプロジェクトから出てくると、次の(より大きな)ものがEntity Frameworkの腕に私を押し込むかもしれないと思います。私はこのテーマについてある程度調べましたが、見つけられなかったのは、SQL Server Data ToolsとEntity Frameworkをどのように使用する/使用する/使用するかについての一貫した話です。 それらは完全に別々に構想されていたのですか? それらは何らかの形で完全に直交しているのですか? 両方が必要だと思う理由: SSDTは、「コンパイル済み」(チェック済み)で、バージョン管理が容易なSQLおよびスキーマを持つのに最適です しかし、SSDTの「移行/更新」の話は説得力がありません(私にとって)。「すべてを更新する」はスキーマでは問題なく動作しますが、データで動作する方法はありません(AFAIK)。 一方で、同様の問題が発生するかどうかを知るためにEFの移行を試みたことはありませんが、Up / Downビットは非常に便利に見えます。

3
アーキテクチャ的に言えば、MicrosoftのEntity Frameworkなどのデータベース抽象化レイヤーは、別のデータアクセスレイヤーの必要性を無効にしますか?
そうだった 長年にわたって、ソフトウェアソリューションを次のように整理してきました。 データにアクセスするビジネスを抽象化するデータアクセス層(DAL) ビジネスルールをデータセットに適用したり、認証を処理したりするためのビジネスロジックレイヤー(BLL) ユーティリティ(Util)は、私が長年にわたって構築してきた一般的なユーティリティメソッドの単なるライブラリです。 もちろん、Web、デスクトップ、モバイルなど何でもよいプレゼンテーション層。 今のやり方 過去4年ほどの間、私はMicrosoftのEntity Framework(私は主に.NET開発者です)を使用しており、Entity Frameworkが既に行っているという事実のために、DALがクリーンよりも厄介になっていることに気付きました私のDALが使っていた仕事:データベースに対してCRUDを実行するビジネスを抽象化します。 したがって、通常、次のようなメソッドのコレクションを持つDALになります。 public static IQueryable<SomeObject> GetObjects(){ var db = new myDatabaseContext(); return db.SomeObjectTable; } 次に、BLLでは、このメソッドは次のように使用されます。 public static List<SomeObject> GetMyObjects(int myId){ return DAL.GetObjects.Where(ob => op.accountId == myId).ToList(); } BLLには通常、さらに数行のロジックが適用されるため、これはもちろん簡単な例ですが、そのような限られた範囲でDALを維持するのは少し過剰に思えます。 DALを放棄して、単にBLLメソッドを次のように記述する方が良いと思いませんか。 public static List<SomeObject> GetMyObjects(int myId){ var db = new myDatabaseContext(); return db.SomeObjectTable.Where(ob …

1
コードのどの部分が最も頻繁に実行されるかを確認するにはどうすればよいですか?
何千行ものソースコードの中で最も頻繁に実行され、最も時間がかかるコードを確認したいと思います。これの目的は最適化のためです。 最適化には、コードのどの部分が最も頻繁に実行されるかを確認できることが重要です。これらの部分は、高速化のために焦点を合わせる必要があるためです。同時に、一部のコードは非常に頻繁に実行されますが、実質的に時間はかかりません。そのため、どのコードに最も時間がかかるかを確認することも重要です。 両方の長所は、実行されたすべての時間を含めて、コードにかかる時間を合計するプログラムになると思います(そのため、コード全体が最も遅くなる原因を見つけます)。これには一種のツールがありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.