ソフトウェア工学

現在、私の会社は、次のように編成されたSVNリポジトリにVisual Studioのソリューションを持っています。 SolutionFolder (~3.5 GB) |-> SolutionName.sln |-> .. Some source code folders... (~250 MB) |-> ThirdParty (~3 GB) |-> Tools | -> Tool1 | -> Tool2 Tool1とTool2は独立してビルドされます（独自のソリューションがあります）が、メインビルドで使用される実行可能ファイルを生成します。ThirdPartyフォルダーには、一部のプリコンパイルされた100 MB以上の.libファイルやboostなどの大きなライブラリなど、プロジェクトのすべての依存関係が含まれています。 （1）開発者が1回のチェックアウトだけを行う必要があり、（2）ビルドの各バージョンに必要な依存関係のバージョンを追跡する必要がないように、すべてを1つのSVNリポジトリに含めると便利です。反対に、このレポを確認するには時間がかかります。 このプロジェクト構造をgitに移動する最良の方法は何でしょうか？おそらく、メインリポジトリからThirdPartyとツールを除外するのが最善ですが、ThirdPartyを1ステップで簡単にダウンロードできるようにして、バージョン管理が必要です（メインリポジトリとThirdParty / Toolsのバージョンの不一致は悪いでしょう）。 この時点では、歴史を保存することには興味がありません。そのようなプロジェクトを整理する方法を理解するだけです。

13 version-control  git 

したがって、次のことが起こると想像してください（そして、すべてSourceTreeを使用している）。 私たちはすべてorigin / developに取り組んでいます。 私は一週間休みに行きます。 私の同僚は、過去数日間、起源/開発を自分のローカル開発ブランチにマージせずにローカルで作業しています。 彼はプッシュを試み、最初にマージする必要があると言われ、次にプルを行います。 彼は競合を取得し、マージ後の自動コミットの進行を停止します。 GitがSVNに似ていると仮定すると、私の同僚は作業コピーの「新しい」ファイルを破棄してから、マージをコミットします。これらの「新しい」ファイルを発信元/開発者のヘッドから消去します。 その改訂に加えて、数週間分の開発作業が行われます。 私は休日から戻ってきて、私の仕事の数日間が不足していることがわかります。 私たちはすべてGitに非常に新しい（これを使用する最初のプロジェクトです）が、それを修正するために私がしたことは： 「develop」の名前を「develop_old」に変更します。 developer_oldを新しいブランチ「develop_new」にマージします。 不良マージの前の最後のコミットに、develop_newブランチをリセットします。 Cherryはそれ以降、各コミットを1つずつ選択し、手作業で競合を解決します。 開発元と開発元をプッシュします。 この時点で、develop_newは、すべての変更の「良い」コピーであり、その後の数週間分の作業が再適用されることを望んでいます。私はまた、「逆コミット」がマージで奇妙なことをすることを想定しています。特に今後数週間の作業はそれに基づいているためです-そして、そのマージには私たちがしたいものと一緒に欲しいものがたくさん含まれているのでt。 私はこれが二度と起こらないことを望んでいますが、もし二度と起これば、私は物事を修正するより簡単/より良い方法を知りたいです。そのマージに基づいてレポで多くの作業が行われたときに、「悪い」マージを元に戻すより良い方法はありますか？

13 git 

MVVMパターンを使用してWPFアプリケーションを構築しています。現在、私のビューモデルは、サービスレイヤーを呼び出してモデルを取得し（ビューモデルとは無関係です）、モデルをビューモデルに変換します。コンストラクター注入を使用して、必要なサービスをビューモデルに渡します。 簡単にテストでき、依存関係の少ないビューモデルでうまく機能しますが、複雑なモデルのviewModelを作成しようとするとすぐに、多くのサービスが挿入されたコンストラクターがあります（各依存関係と使用可能なすべての値のリストを取得するためのもの）たとえば、itemsSourceにバインドします）。そのような複数のサービスをどのように処理し、簡単にユニットテストできるビューモデルがまだあるのか疑問に思っています。 私はいくつかの解決策を考えています： 使用可能なすべてのサービスをインターフェイスとして含むサービスシングルトン（IServices）を作成します。例：Services.Current.XXXService.Retrieve（）、Services.Current.YYYService.Retrieve（）。そうすれば、大量のサービスパラメータを含む巨大なコンストラクタはありません。 viewModelによって使用されるサービスのファサードを作成し、このオブジェクトを私のviewmodelのctorに渡します。しかし、その後、複雑なビューモデルごとにファサードを作成する必要があります。 この種のアーキテクチャを実装する「正しい」方法は何だと思いますか？

13 architecture  dependency-injection  mvvm 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 Javaで書かれた大規模なユーザー向けWebサイトの開発に興味があります。 設計に関しては、メインのWebアプリケーションに対するデータプロバイダーとして機能できる、独立したモジュラーサービスの開発を考えています。 これらのモジュラーサービス（データプロバイダー）の作成については、Springなどの既存のフレームワークを活用し、RESTfulデザインパターンに従ってこれらのサービスを開発し、JSONなどのメッセージ形式でHTTPを介してリソースを公開するか、既存のネットワークを活用できますNetty（http://netty.io/）のようなフレームワークとProtobufs（https://developers.google.com/protocol-buffers/docs/overview）のようなシリアル化形式、およびシリアル化されたprotobuf を送受信するTCPサーバーを開発するペイロード。 どちらを選択するかはいつですか？Protobufsのようなシリアル化形式を使用して、ワイヤを介してバイトストリームを送信する利点はありますか？JSONを使用するだけでオーバーヘッドが発生しますか？TCP / IPを使用してからHTTPを使用するまでのオーバーヘッドはどれくらいですか？そのようなサービスを構築するためにSpring over Nettyをいつ使用する必要がありますか？

13 java  rest  http  serialization  tcp 

Javaでは、慣例により、ブールフィールドのゲッターおよびセッターはisField()およびになりsetField()ます。これは、のような形容詞ですフィールド名と完全に正常に動作しactive、visible、closed、など しかし、次のような動詞の意味を持つフィールドに名前を付けるにはどうすればよいhaveChildrenですか？「_ing」を動詞（）に追加しますか？havingChildren 明確にするために、メソッド名（getterおよびsetter）はIDEによって自動生成されるため、制御できません。したがって、必要なのは適切なフィールド名であり、IDEがそのゲッターを生成するときに意味があります。たとえば、hasChildrenは完全なフィールド名ですが、IDEがフィールドのゲッターを生成すると、になりますisHasChildren。これをどうやって解決しますか？

13 java  naming 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 私は数年間プロレベルでプログラミングを行ってきましたが、それでもエラー処理を完全に理解していません。私のアプリケーションは正常に動作しますが、エラー処理は専門的なレベルでは実装されておらず、多くの手法の組み合わせです。 エラー処理の背後に構造はありません。プロレベルでどのように実装されているかを学び、理解したいと思います。これは、私が知識を欠いている分野の1つです。 ロジックフローでチェックするために、いつ例外を使用し、成功ステータスを返す必要がありますか？例外を組み合わせてステータスを返すことはできますか？ 主にC＃でコーディングします。

13 c#  .net  coding-standards  error-handling 

私たちは新しいプロジェクトに取り組んでおり、2人の主任開発者であり、トークンを使用してサーバーとクライアント間の通信を保護する方法の岐路に立っています。 最初の提案：（ワンタイムトークンAKAスタティックトークン） クライアントは、ユーザー名とパスワード、およびcurrent_time（この変数はサーバーのデータベースとクライアント側にも保存されます）をAPIに送信することによってプライマリトークンを要求し、サーバーは入力を解釈し、ハッシュトークンをレンダリングします（例： 58f52c075aca5d3e07869598c4d66648）はデータベースに保存し、クライアントに返します。 クライアントはプライマリトークンを保存し、プライマリトークン+認証要求で送信されたcurrent_time変数を使用して新しいハッシュトークンを作成します（この新しいトークンmain_tokenを呼び出します）。また、サーバーも同じことを行い、同じアルゴリズムを使用して同じトークンを作成します。 クライアントがサーバーAPIを照会するたびに、main_tokenをサーバーに送信します。サーバーは、その中で生成されたトークンをクライアントが送信したmain_tokenと比較します。一致する場合、ユーザーは本物であることを意味します。 2番目の提案：（動的トークン） クライアントは2つのランダムキーを生成します（$ key1 = rand（10000,90000）; $ key2 = rand（10000,90000）;）APIの各リクエストで、クライアントはクエリタイプを使用してハッシュを作成し、複雑なアルゴリズム、およびこれらの2つのキー+ハッシュをサーバーに送信します サーバーは、クライアントで使用されるものと同じアルゴリズムを使用してハッシュを作成し、クライアントが送信したものと比較します。一致する場合、サーバーはクエリの処理に進みます さて、質問は、APIリクエストを保護するために使用する最も論理的で安全な方法はどれですか？

13 security  api 

先日、同僚と話し合っていたところ、彼はWebアプリケーションでユーザーのセッションを使用するのは間違っていると言っていました。格納している情報によっては間違っている可能性があると答えました。それ以外の場合は、MicrosoftがWebセッションサービスを提供する必要があります（ASP.NETについて話していました）。 彼は、MSでさえ、デザインが悪いと簡単に返信できると再度答えました。そして、彼はそれを示すいくつかのホワイトペーパーを見せてくれた。 残念ながら、この人に連絡する機会はもうありませんが、彼の視点についてもっと理解したいと思います。誰もがそれについての情報/視点をここに持っていますか？

13 web-applications 

中規模のCライブラリプロジェクトの関数命名規則に関する実用的なアドバイスを見つけるのに苦労しています。私のライブラリプロジェクトは、独自のヘッダーを持ついくつかのモジュールとサブモジュールに分割され、大まかにOOスタイルに従います（すべての関数は、グローバルなどではなく、最初の引数として特定の構造体を取ります）。次のように配置します。 MyLib - Foo - foo.h - foo_internal.h - some_foo_action.c - another_foo_action.c - Baz - baz.h - some_baz_action.c - Bar - bar.h - bar_internal.h - some_bar_action.c 一般的に、関数は大きすぎて（たとえば）固執some_foo_actionしanother_foo_action、1つのfoo.c実装ファイルに入れて、ほとんどの関数を静的にして、1日で呼び出します。 ユーザーのクライアントプログラムとの競合を避けるために、ライブラリを構築するときに内部（「モジュールプライベート」）シンボルを削除することもできますが、問題はライブラリ内のシンボルの名前の付け方ですか？これまで私はやってきた： struct MyLibFoo; void MyLibFooSomeAction(MyLibFoo *foo, ...); struct MyLibBar; void MyLibBarAnAction(MyLibBar *bar, ...); // Submodule struct MyLibFooBaz; void MyLibFooBazAnotherAction(MyLibFooBaz *baz, ...); しかし、私は（例よりはるかに長い）クレイジーな長いシンボル名になってしまいました。名前の前に「偽の名前空間」を付けない場合、モジュールの内部シンボル名はすべて衝突します。 注：キャメルケース/パスカルのケースなどは気にせず、名前だけを気にします。

13 c  naming  project-structure 

エンティティの単一の責任（変更する理由）は、それ自体を一意に識別することである必要があります。言い換えると、その責任を見つけられるようにすることです。 エリックエヴァンのDDDの本、ページ。93： エンティティの最も基本的な責任は、動作が明確で予測可能なように継続性を確立することです。彼らは予備にされている場合、彼らはこれを最善にします。属性や動作に焦点を当てるのではなく、Entityオブジェクトの定義を最も本質的な特性、特にそれを識別する、またはそれを検索または一致させるために一般的に使用される特性まで取り除きます。その動作に必要な概念と属性に不可欠な動作のみを追加します。 それを超えて、コアエンティティに関連付けられた他のオブジェクトへの動作と属性を削除することを検討してください。 1。 ... ENTITYオブジェクトの定義を最も本質的な特性、特にそれを識別する、またはそれを検索または一致させるために一般的に使用される特性まで取り除きます。コンセプトに不可欠な動作のみを追加します... いったんエンティティが割り当てられている固有のIDを、そのアイデンティティが確立され、私はそのような実体がするいかなる行動を必要としないと仮定しますので、そのアイデンティティを維持したりするために、それは自分自身を識別するのに役立ちます。したがって、著者が「概念に不可欠な振る舞い」findとはどのような振る舞いを参照しているのか理解できません（およびmatch 操作以外）。 2。 ... ENTITYオブジェクトの定義を最も本質的な特性、特にそれを識別する、またはそれを検索または一致させるために一般的に使用される特性まで取り除きます。...さらに、動作と属性を削除して、コアENTITYに関連付けられている他のオブジェクトを探します。 そのため、エンティティを特定するのに役立たないが、そのエンティティの固有の特性として行動を特徴付けます（つまり、characterえは犬に固有、飛行は飛行機に固有、産卵は鳥に固有です。） 。）、そのエンティティに関連付けられている他のオブジェクトに配置する必要があります（例：犬のエンティティに関連付けられているオブジェクトにbarえる動作を配置する必要があります）？ 3。 それを超えて、コアENTITYに関連付けられた他のオブジェクトの動作と属性を削除してください。 a）MyEntity責任A_respをおよびにそれぞれ委任B_respします。ab ほとんどのにもかかわらずA_respとB_resp仕事をすることによって行われa、およびbインスタンス、クライアントはまだ提供されているA_respとB_resp通じMyEntityクライアントの観点から二つの責任はに属していることを意味しています、MyEntity。したがって、それはMyEntityまたA_resp、B_resp責任と責任を持っていることを意味していないので、SRPに違反していますか？ B）私たちがいることを前提としていてもA_respとB_respに属していないMyEntity、MyEntityまだ責任があるAB_respオブジェクトの動作を調整するにaしてb。そうしないMyEntity違反SRPを最低でも、それは持っているので、2つの責任を一意に自身を識別し、またして- AB_resp？ class MyEntity { private A a = ... private B b = ... public A GetA() { ... } public B GetB() { ... } /* coordinates operations of objects …

13 domain-driven-design  single-responsibility 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 私のコードでは、上記の2つのオプションのいずれかが同様に機能しますが、両方のアプローチの長所と短所を見つけることに興味があります。

13 python 

私はこれを行う必要があるかどうかを概念的に理解しようとしています： item = Model() screen = View() brain = Controller(item, screen) またはこれ.. brain = Controller() item = Model(brain) screen = View(brain) またはこれ.. class Controller(): def __init__(self): item = Model(self) screen = View(self) または完全に何か他のもの？

13 mvc 

グラフ検索の最適化問題を解決しています。有向グラフを介して、k個の最適な非循環最短経路を見つける必要があります。 正確で近似的なk-bestアルゴリズムが多数あることは知っていますが、最近の研究のほとんどは、非常に大きく、非常にまばらに接続されたグラフ（道路のルーティングや方向など）を対象としているようです。 私の問題の側面を区別する： グラフは約160の頂点で構成されています。 グラフはほぼ完全に接続されています（双方向であるため、〜160 ^ 2〜= 25kエッジ） kは非常に小さい（おそらく10未満） 最大パス長はおそらく制限され、同様に非常に小さくなります（例：3-5エッジ） 上記で「非周期的」と言いましたが、繰り返しますが、ソリューションにはサイクルを含めることはできません。これは1-best最短パスの問題ではありませんが、k-bestの問題になります-たとえば、道路のルーティングを検討すると-AからBへの2番目の最短パスは1-bestと同じで、どこかのブロックの周りの簡単な旅行。それは数学的に最適かもしれませんが、あまり有用な解決策ではありません。;-) 計算ごとに、エッジをその場で再重み付けする必要がある場合があります。エッジコストはいくつかの要因の加重合計で構成され、最終要件（取得する場合はいつでも）により、ユーザーはそれらの加重要因の独自の優先順位を指定して、エッジの重みを変更できます。これは比較的小さなグラフであるため（数百KBで表すことができるはずです）、メモリ内でグラフを複製し、再重み付けを適用してから、複製されたグラフで検索を実行するのが妥当です。しかし、その場で重みを計算しながら検索を実行するより効果的な方法があれば、興味があります。 Santos（K最短パスアルゴリズム）、Eppstein 1997（k最短パスの検索）などで説明されているアルゴリズムを探しています。Yenのアルゴリズムは、主に既存のJava 実装のために興味深いものです。私は研究論文を読むことを恐れていませんが、私の問題の詳細を捨てて、読書時間を節約するための指針を求めることは価値があると思いました。 また、Java実装へのポインターがある場合は、さらに良いでしょう。

13 java  algorithms 

synchronizedを使用するよりも使用することが望ましい単一のシナリオ（古代のJVMとの互換性以外）がありますLockか？誰でも新しいシステムを使用しwaitたりnotify、新しいシステム上で正当化することはできますか？ 実装でそれらのいずれかを使用する必要があるアルゴリズムはありますか？ この問題に触れた以前の質問がありますが、これをもう少し詳しく見ていきたいと思いdeprecateます。新しい施設で解決されたtrapや落とし穴、注意事項は非常に多くあります。すぐにそれらを陳腐化する時が来るかもしれないと感じています。

13 java  synchronization  deprecation 

テストを作成していて、テストに合格する必要があり、独自の機能に分離する必要がある追加の機能が必要であることに気付いたとき、何をしますか？その新しい関数もテストする必要がありますが、TDDサイクルでは、テストを失敗させ、成功させてからリファクタリングするように指示されています。テストに合格しようとしているステップにいる場合、実装する必要がある新しい機能をテストするために、別の失敗したテストを開始することは想定されていません。 たとえば、関数WillCollideWith（LineSegment）を持つポイントクラスを作成しています。 public class Point { // Point data and constructor ... public bool CollidesWithLine(LineSegment lineSegment) { Vector PointEndOfMovement = new Vector(Position.X + Velocity.X, Position.Y + Velocity.Y); LineSegment pointPath = new LineSegment(Position, PointEndOfMovement); if (lineSegment.Intersects(pointPath)) return true; return false; } } LineSegment.Intersects（LineSegment）関数が必要だと気づいたとき、CollidesWithLineのテストを書いていました。しかし、この新しい機能を作成するために、テストサイクルで実行していることを停止する必要がありますか？これは「赤、緑、リファクタリング」の原則を破っているようです。 lineSegments IntersectをCollidesWithLine関数内で検出し、動作後にリファクタリングするコードを記述する必要がありますか？LineSegmentからデータにアクセスできるので、この場合はうまくいきますが、その種のデータがプライベートな場合はどうでしょうか？

13 unit-testing  tdd