ソフトウェア工学

コンテキスト：C＃を使用しています クラスを設計し、それを分離し、ユニットテストを容易にするために、すべての依存関係を渡します。内部的にオブジェクトのインスタンス化は行いません。ただし、必要なデータを取得するためにインターフェイスを参照する代わりに、必要なデータ/動作を返す汎用Funcsを参照するようにします。依存関係を注入するとき、ラムダ式を使用してそれを行うことができます。 私にとっては、単体テスト中に面倒なモックをする必要がないため、これはより良いアプローチのように思えます。また、周囲の実装に根本的な変更がある場合、ファクトリクラスを変更するだけで済みます。ロジックを含むクラスを変更する必要はありません。 ただし、これまでにIoCがこのように行われるのを見たことがないため、見落としがちな潜在的な落とし穴があると思います。私が考えることができるのは、Funcを定義しないC＃の以前のバージョンとのわずかな非互換性だけです。これは私の場合は問題ではありません。 より具体的なインターフェイスとは対照的に、IoCのFuncなどの汎用デリゲート/高階関数の使用に問題はありますか？

14 architecture  interfaces  inversion-of-control  delegates 

RESTful APIを開発しており、リソースにDAOを使用すると便利だと思います。メモリを使用してそれらを格納するだけですが、使用することに決めた場合はライブラリを使用しているユーザーのドアを閉めたくないためです。 DAOのデータベース実装。 私の質問は、DAOがシングルトンであるかどうかです。そうでない場合、サービスにはDAOのインスタンスがあり、おおよそ次のようになります。 @Path("eventscheduler") public class EventSchedulerService { private IEventSchedulerDao dao = new EventSchedulerDao(); // in case a different implementation is to be used public void setEventSchedulerDao(IEventSchedulerDao dao) { this.dao = dao; } @Path("{uniqueName}") @GET @Produces(MediaType.APPLICATION_JSON) public Tournament getTournament(@PathParam("name") String uniqueName) { return dao.get(uniqueName); } @Path("create") @POST @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) …

14 java  design  design-patterns  singleton  dao 

誰かが特定のライセンスの混乱を解決してくれませんか？私は、ソフトウェアのライセンスがどのように機能するかに常に戸惑っています。 誰でも最小限の制限で、保証なしでソフトウェアを使用できるようにしたいと思います。だから私は寛容なライセンスを使用し（MITライセンスが私の選択でした）、次のように書きます すべてのファイルとその内容を含むこのプロジェクトは、MITライセンスの条件の下でライセンスされています 詳細については、LICENSE.txtを参照してください。 プロジェクトのREADMEで。 プロジェクトの「アーティファクト」（補助ファイル、実際にはソースファイルではないファイル）に対してこれがどのように機能するかについて混乱しています。プロジェクトのすべてのファイルに同じライセンス条件を適用したい ビルドシステム/ドキュメントファイル（MakefileS、 、CMakeLists.txt、Doxyfile等。私はそれは、上記の句は、それらのファイルに適用され、実際にはほぼ一定しないんです？）、 HTML / JavaScript / CSS / XML /など。ファイル（ライセンスされているものですか？わかりません。また、それらを調べたり、独自のバージョンを作成したりすることもできます） 画像やその他のバイナリアセット（プレゼンテーションなどで使用できるようにしたい）。 私は人々が彼らのプロジェクトに対して一種のデュアルライセンスを行っているのを見てきました。たとえば、ソースファイルはMITライセンスに基づいてライセンスされ、画像はCreative Commonsライセンスのいずれかに基づいてライセンスされます。なぜ彼らはそれをするのですか、MITライセンスでは十分ではありませんか？つまり、ライセンスのテキストは「ソフトウェア」についてのみ説明しています。画像が「ソフトウェア」の一部として含まれているかどうか、特に画像がソフトウェアの製品である場合（ソフトウェアがどのような種類の画像を生成できるかの例を提供したい場合など）、わかりません。それとも彼らですか？ そして、プロジェクトに実際にソースコードが含まれていない場合はどうなりますか？適切に使用しないと、ソフトウェアの別の部分が正しく動作せず、ユーザーのデータを台無しにする可能性のある（私の観点からは、有用な）構成ファイルのセットだけだとしたらどうでしょうか？ 私は本当に私のプロジェクトのすべてに一つ一つを含めるために普遍的な言葉遣いを考え出し、それでやりたいと思っています。また、役に立つ提案が出て、プロジェクトのライセンス条項を変更することにした場合、私が唯一の貢献者であれば、それを行うことができますか？プロジェクトがMITライセンスの下で「ライセンスされた」と考える。 私のプロジェクトは誰も実際に興味を持たないので、私はこれを自閉症に感じますが、これについて考えるとき、私はいつも私の脳を傷つける必要があるように感じます。 。

14 licensing 

一般的に呼ばれる、Git-flowモデルの修正プログラムは、特定のhotfix-*ブランチに導入され、リリースの直前に小さな統合修正がrelease-*ブランチに導入されます。前のバージョンからの一般的なバグ修正には場所がないようです。 どこに表示されますか？彼らbug-*はdevelop（ちょうどfeatureブランチのように）分岐する独自のブランチにあるべきですか？

14 git  gitflow 

非自明なC ++ const関連の重複を避けるために、const_castは機能するが、非constを返すプライベートconst関数は機能しない場合がありますか？ Scott MeyersのEffective C ++ item 3では、const_castと静的キャストを組み合わせることで、コードの重複を避けるための効果的で安全な方法を提案しています。 const void* Bar::bar(int i) const { ... return variableResultingFromNonTrivialDotDotDotCode; } void* Bar::bar(int i) { return const_cast<void*>(static_cast<const Bar*>(this)->bar(i)); } マイヤーズは、const関数にnon-const関数を呼び出すことは危険であると説明しています。 以下のコードは反例を示しています。 マイヤーズの提案に反して、静的キャストと組み合わせたconst_castは危険な場合があります 時々const関数がnon-constを呼び出すことはそれほど危険ではありません const_castを使用して両方の方法で潜在的に有用なコンパイラエラーを隠すことがあります。 const_castを避け、const以外のメンバーを返すconst constメンバーを追加することも別のオプションです コードの重複を回避するconst_cast戦略のいずれかが適切なプラクティスと見なされていますか？代わりにプライベートメソッド戦略を好むでしょうか？const_castは機能するが、プライベートメソッドは機能しない場合がありますか？複製以外に他のオプションはありますか？ const_cast戦略に関する私の懸念は、コードが記述されたときに正しい場合でも、メンテナンス中にコードが不正確になり、const_castが有用なコンパイラエラーを隠す可能性があることです。一般的なプライベート関数の方が一般に安全なようです。 class Foo { public: Foo(const LongLived& constLongLived, LongLived& mutableLongLived) : mConstLongLived(constLongLived), mMutableLongLived(mutableLongLived) {} // …

14 c++  dry  const 

これが概念的に言語を破る特定の理由、またはこれが技術的に実行不可能である特定の理由がありますか？ 使用法はnew演算子を使用します。 編集：私は「新しいオペレーター」と「新しいオペレーター」をまっすぐに取得することへの希望をあきらめ、率直になります。 問題のポイントは、なぜコンストラクターが特別なのかということです。もちろん、言語仕様は合法であるが必ずしも道徳的ではないことを教えてくれることに留意してください。通常、合法とは、言語の他の部分と論理的に一致するもの、単純で簡潔なもの、コンパイラーが実装できるものによって通知されます。これらの要因を評価する際の標準化委員会の考えられる理論的根拠は、意図的で興味深いものです。したがって、質問です。

14 c++ 

閉じた。この質問には、詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善したいですか？詳細を追加し、この投稿を編集して問題を明確にします。 5年前に閉鎖されました。 最近、MVCのデザインパターンについて学びました。私はHead First Design Pattern本から学んでいます。 この本によると（私が正しく理解している場合）： モデルは、ほとんどのアプリケーションロジックとデータです。 ビューは、基本的にモデルをユーザーに視覚的に表すGUIです。 コントローラーは、ビューとモデルの間の「仲介」と「仲介者」としての役割を果たす責任があります。ビューは、ユーザーがアクションを実行したことをコントローラーに報告し、コントローラーはそれをモデルのメソッド呼び出しに変換します。 しかし、ウェブ上の多くの場所は、私がその本から理解していることと矛盾しています。彼らは一般的に、ユーザーがビューではなくコントローラーと対話することを主張しています。 どちらが本当ですか、それともより一般的ですか？ユーザーはコントローラーと直接対話しますか、それともビューと直接対話しますか？両方のアプローチは受け入れられますか？どちらがより一般的ですか？

14 design-patterns  mvc 

私たちの仕事には、多くの基本機能を共有するいくつかの異なる.netアプリケーションがあります。クリーンなn層アーキテクチャを使用してこれらのアプリケーションを構築しましたが、同じ機能を何度か再実装したことに気付いたその瞬間にヒットしました。これは明らかにDRYに違反するため、修正する必要があります。すでに一般的なグルーコード（IoCの配線、ログ、設定）にNugetを使用していますが、すべてのアプリケーション間でデータ層とビジネス層を共有したいと考えています。このアイデアは、UIが実際に必要なビジネスレイヤーの部分のみを処理するというものです。 これは最初は簡単な問題のように見えますが、進行中の開発には落とし穴があり、どのように進めればよいかわかりません。すべてを支配するために1つのビジネスレイヤーを作成するとします。簡潔にするために、「Foundation」と呼びます。Foundationを使用するためにアプリケーションを移植しましたが、すべてが素晴らしいものです。Foundationはnugetを介してライトUIレイヤーに配布されており、見栄えが良いです。しかし、その後、アプリケーションに機能を追加し始め、トラブルに直面します。 プロジェクトAに取り組んでおり、Foundationの変更を必要とする新しい機能を追加するとします。Foundation（Foundation-A）に変更を加え、不安定なパッケージとしてNugetフィードにプッシュします。プロジェクトAは最新のnugetパッケージを取得し、すべてが良好です。一方、別の開発者がプロ​​ジェクトBに取り組んでいます。彼はソース管理から最新のFoundationを取得しますが、安定したブランチから取得するため、プロジェクトAの変更はありません。彼は変更を加え、Foundation-Bを作成しました。そして、すべてが良いです。しかし、その後、実際にコードを共有できるFoundation-AとFoundation-Bの実装機能を発見したため、それらを組み合わせます。一方、Foundation-Cは独自の変更を加えてそこに浮上しています。最終的に、Foundation-Bの運用準備が整いました。しかし、その後、プロダクションA、B、 これはうまくいくように思えますが、異なるデータベーススキーマで作業し、FoundationリポジトリのさまざまなブランチとプロジェクトA、B、Cリポジトリ間ですべてを同期させることを心配しています。おそらく多くの手作業が必要になるようで、エラーの可能性が広がります。これを可能な限り自動化したいと思います。 使用しているスタックは次のとおりです。C＃、継続的インテグレーションを備えたTFS、Nuget。当社のアプリケーションはすべて、さまざまな種類のASP.NETアプリケーションです。物事を簡単にする場合は、さまざまなSCMを検討します。 さまざまなソースコードブランチでNugetを正常に保つ方法を探しています。間違ったNugetパッケージを参照するため、誤って開発コードを本番環境にプッシュしたくありません。

14 c#  team-foundation-server  branching 

Windows上で実行され、ゲームのランチャーのように動作し、クライアント側のPCで自動アップデーターおよびファイル検証ツールとして機能するソフトウェアを作成しています。 私の理解していないことの1つは、私のアンチウイルスソフトウェア（Avast）が私のexeファイルを危険だと見なし、安全に使用するためにサンドボックスに入れることを求めずに起動しない理由です。 私のソフトウェアが従うべきルール、良いものとして扱われるルール、またはある種のデジタル署名などに数百ドルを支払うべきルールはありますか？ MS Visual Studio 2010でC＃を使用しています。 VirusTotalレポート。WebClient（）クラスを使用して、リモートファイルダウンローダーとして機能するDLLインジェクションはありません。 ウイルスについて警告するようなものではありませんが、サンドボックスすることを「提案」します。スクリーンショットを見てください：

14 c#  security  visual-studio-2010  software-updates 

私は画像処理（主にOCR）に取り組んでおり、開発に単体テストをどのように統合すべきか疑問に思っています。 私はすでに、より一般的なタイプのコードに対して単体テストを使用していますが、画像処理コードを処理するとき、その処理方法がわかりません。この種のコードには常に画像データの入出力が必要であり、これを模倣することは明らかではありません。今のところ、主に統合テストを行っていますが、実行には時間がかかります。この種のコードをユニットテストに分割して、より迅速に実行できるようにするためのアイデアが欲しいです。 編集：キャラクターの分析は、複数の回転、スケーリング、および形態学的操作を含む多くのステップを経ることができます。これらの手順は、アルゴリズムの開発中に頻繁に変更されます。したがって、テスト中に入力と期待される出力は大きく変化する可能性があります。各文字は100x100ピクセルにすることができるため、コード内でハードコーディングしたり、生成されたデータを操作したりするのは問題ありません。

14 testing  unit-testing  tdd  integration-tests  mocking 

Strategyパターンは、巨大なif ... elseコンストラクトを回避し、機能の追加または置換を容易にするためにうまく機能します。しかし、それでも私の意見には1つの欠陥が残っています。どの実装でも、分岐構造が必要であるようです。ファクトリまたはデータファイルの可能性があります。例として、注文システムを取り上げます。 工場： // All of these classes implement OrderStrategy switch (orderType) { case NEW_ORDER: return new NewOrder(); case CANCELLATION: return new Cancellation(); case RETURN: return new Return(); } この後のコードは心配する必要はなく、新しい注文タイプを追加する場所は1つだけですが、このセクションのコードはまだ拡張できません。データファイルにそれを引き出すことは、読みやすさをいくらか助けます（議論の余地があります、私は知っています）： <strategies> <order type="NEW_ORDER">com.company.NewOrder</order> <order type="CANCELLATION">com.company.Cancellation</order> <order type="RETURN">com.company.Return</order> </strategies> しかし、これにより、データファイルを処理するための定型コードが追加されます。付与された、より簡単にユニットテスト可能で、比較的安定したコードですが、それでも複雑さが増します。 また、この種のコンストラクトは統合テストがうまくいきません。個々の戦略は今すぐテストする方が簡単かもしれませんが、追加するすべての新しい戦略はテストの複雑さを増すことになります。パターンを使用していなかった場合よりも少ないですが、それはまだあります。 この複雑さを緩和する戦略パターンを実装する方法はありますか？それとも、これはそれと同じくらい簡単で、さらに先へ進んでも、抽象化の別の層を追加するだけで、ほとんどまたはまったく利益がありませんか？

14 design  design-patterns  unit-testing  strategy 

私はソフトウェア開発チームのソフトウェアエンジニアです。過去3年間、社内顧客のために新製品を開発しました。この製品が完成したら、既存の製品の主要な新機能に取り組みます。特定の機能について、製品管理者は開発に150時間かかると推測しています。プロジェクトマネージャーと一緒に非常に詳細な計画を作成し、300時間の努力をしています。昨日私たちはこれについて議論し、彼らは私たちが物事を著しく過大評価していると考えています。 私たちの計画では、ユニットテストを書く時間を見積もっていましたが、彼らのアイデアは時間を節約するためにそれらをダンプすることです。まだ決定は下されていません。必要に応じて、この計画と単体テストを擁護します。しかし、ここで私が本当に嫌いなのは、経営陣が開発プロセスに干渉しているということです。開発プロセスからそれらを締め出すにはどうすればよいですか？また、ユニットテストを適切な状態に保つために、どのような引数を使用できますか（品質と長期的な時間の節約に加えて）。 ちなみに、当社には3つのエンジニアリングチームがあり、私が所属するチームはソフトウェアを予定通りに提供しています（10％のマージンを与えるか、またはマージンを取ります）。主に計画の過小評価が原因で、他のチームは常に遅れて配信します。彼らはコーディングのみを計画し、その周辺の管理、テスト、および取り扱いは計画していません。

14 development-process  management 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 2年前に閉店。 仕事中のコーダーの本で、ジョー・アームストロングは次のように述べています。 再利用性の欠如は、関数型言語ではなくオブジェクト指向言語で発生すると思います。オブジェクト指向言語の問題は、それらが持ち歩くこの暗黙の環境をすべて持っているためです。バナナが欲しかったのに、バナナとジャングル全体を持ったゴリラが手に入れた ここではあまりわかりません。問題がバナナを取得することである場合、関数 'getBanana'の背後にあるすべてのロジックをカプセル化できます。猿とジャングルはこの文脈にどのように関係していますか。誰かの書き込みがあるという事実を証明、と言う、方法を理解しやすくして、問題を説明するコードスニペットでしたBananaオブジェクトが必要とするMonkeyとJungle、開始されるようにしてくださいオブジェクトを？

14 object-oriented  functional-programming 

奇妙なパターンが検出された場合に電子メールでユーザーに警告する金融アプリケーション用の小さなセキュリティサブシステムを実装すると仮定します。この例では、パターンは図のように3つのトランザクションで構成されます。セキュリティサブシステムは、メインシステムからキューからイベントを読み取ることができます。 私が取得したいのは、パターンの現在の状態をモデル化する中間表現なしで、システムで発生するイベントの直接的な結果であるアラートです。 監視が有効になりました 処理されたトランザクション 処理されたトランザクション 処理されたトランザクション アラートがトリガーされました（id：123） 送信されたアラートの電子メール（ID：123） 処理されたトランザクション これを念頭に置いて、明確な答えのない質問がありますが、イベントソーシングはここで非常にうまく適用できると思いました。この例でトリガーされたアラートには、明らかな副作用があり、電子メールを送信する必要があります。これは、一度しか発生しない状況です。したがって、集合体のすべてのイベントを再生するときに発生することはありません。 ある程度、CQRS /イベントソーシングの文献で何度も見たクエリ側で生成された実体化と同様に送信する必要がある電子メールが表示されますが、それほど微妙な違いはありません。 この文献では、クエリ側は、すべてのイベントを再度読み取る特定の時点で状態の具体化を生成できるイベントハンドラから構築されています。ただし、この場合、前に説明した理由により、そのように正確に実行することはできません。すべての状態が一時的であるという考えはここでそれほど適切ではありません。アラートがどこかに送信されたという事実を記録する必要があります。 私にとって簡単な解決策は、以前にトリガーされたアラートの記録を保持する別のテーブルまたは構造を持つことです。IDがあるため、同じIDのアラートが以前に発行されたかどうかを確認できます。この情報があると、SendAlertCommandはべき等になります。複数のコマンドを発行できますが、副作用は一度しか発生しません。 その解決策を念頭に置いても、これがこの問題のこのアーキテクチャに何か問題があるというヒントかどうかはわかりません。 私のアプローチは正しいですか？ これに関する詳細情報を見つけることができる場所はありますか？ これについての詳細情報を見つけることができなかったことは奇妙です。たぶん私は間違った表現を使っていたのかもしれません。 どうもありがとうございます！

14 event-programming  cqrs  event-sourcing 

どのデザインパターンがこの問題の解決に役立つかはわかりません。 使用するWorkerクラスを決定する「コーディネーター」クラスがあります-存在するすべての種類のWorkerについて知る必要はありませんが、WorkerFactoryを呼び出し、共通のIWorkerインターフェイスに基づいて動作します。 次に、適切なWorkerを動作するように設定し、 'DoWork'メソッドの結果を返します。 これまでは順調でした...今までは。新しいワーカークラス「WorkerB」の新しい要件があります。これは、作業を行うために追加の情報、つまり追加の入力パラメーターを必要とします。 余分な入力パラメーターを使用してオーバーロードされたDoWorkメソッドが必要なようですが、既存のすべてのワーカーはそのメソッドを実装する必要があります。これらのワーカーは本当にそのメソッドを必要としないので間違っているようです。 これをリファクタリングして、どのワーカーが使用されているかをコーディネーターに認識させずに、各ワーカーがジョブを実行するために必要な情報を取得できるようにしますが、不要な作業はワーカーに行わせませんか？ 既に多くの既存のワーカーがいます。 新しいWorkerBクラスの要件に対応するために、既存の具象ワーカーを変更する必要はありません。 ここではデコレータパターンが良いと思うかもしれませんが、デコレータが同じメソッドでオブジェクトを異なるパラメータで装飾するのを見たことはありません... コードの状況： public class Coordinator { public string GetWorkerResult(string workerName, int a, List<int> b, string c) { var workerFactor = new WorkerFactory(); var worker = workerFactor.GetWorker(workerName); if(worker!=null) return worker.DoWork(a, b); else return string.Empty; } } public class WorkerFactory { public IWorker …

14 c#  design-patterns