ソフトウェア工学

私は過去6か月ほどの間にC＃を学び、現在はJavaを掘り下げています。私の質問は、インスタンスの作成に関するものです（どちらの言語でも）、それはもっと多くのことです。この例を取ります Person Bob = new Person(); オブジェクトが2回指定されている理由はありますか？ありsomething_else Bob = new Person()ますか？ 私が慣習に従っているなら、もっと似ているように思えます： int XIsAnInt; Person BobIsAPerson; または、おそらく次のいずれかです。 Person() Bob; new Person Bob; new Person() Bob; Bob = new Person(); 「それがまさに行われている方法」よりも良い答えがあるかどうか興味があります。

17 java  c#  object-oriented 

たとえば、実行するのではなく、なぜ関数を呼び出すのか疑問に思っていました。 Googleでの検索function call etymologyや類似の用語は有用ではありません。ウィキペディアでは言及されていません。オンライン辞書にはエントリがまったくないか、語源セクションがありません。 関数を「呼び出す」という概念はどこから来たのですか？

17 terminology  language-agnostic  history 

私にとって長年の疑問は、いつデータベーステーブルにデータ（実際の値）を保存し、いつコードに保存するのかということです。 知られていないコンセンサスは、通常そのようなものでした（*）： 単一の変数または単純な構造、またはいくつかの値の配列である場合、コードにデータを直接入れます。 [* コンセンサスはコメントと回答で議論されていますが、基本的には、質問を開始するための何らかの前提を望んでいたので、気軽に挑戦して改善してください] 例： $number = 44; $colors = array("blue", "yellow", ... "mauve"); 同じタイプの数百行以上のデータがある場合は、データベースを使用します。 しかし、灰色の領域があるようです。それほど明確ではないケースはどうですか？決定を下すために注意を払う必要がある考慮事項と要因は何ですか？ 例： 会社が「412T」として表すことができる10〜15種類のモーターフレームを使用しているとします。あなたはそれらの約30を持っています、そして、彼らはめったに変わりません。それらのDBテーブルを作成するか、データベースにハードコーディングできます。この場合、モーターは静的で物理的なものであり、頻繁に変更されることはありません。 それらをコードに保持すると、ソース管理の対象となります。データベースでは、通常、DBの変更は追跡されません。しかし、それらをデータベースに保持すると、コードをデータから解放（分離）できます。 私が使用できる別の（実際の）例は、私の質問です：https : //stackoverflow.com/questions/26169751/how-to-best-get-the-data-out-of-a-lookup-table（現在48オプションデータの行）。

17 database  source-code  separation-of-concerns 

CおよびC ++は、隣接する文字列リテラルを単一の文字列リテラルとしてコンパイルします。例えばこれは： "Some text..." "and more text" 以下と同等です： "Some text...and more text" C＃やJavaなどの他のCファミリ言語では、これは構文エラーです（完全に問題ありません）。 CおよびC ++がこれを行う理由/歴史的理由は何ですか？

17 c++  c  language-features 

過去には、さまざまな環境で働いてきました。デスクトップアプリ、ゲーム、埋め込みコンテンツ、Webサービス、コマンドラインジョブ、Webサイト、データベースレポートなど。これらの環境はすべて同じ特徴を共有しました。複雑さやサイズに関係なく、テストするマシンまたは開発環境でアプリケーションのサブセットまたはスライスを常に保持できました。 今日はしません。今日私は、スケーラビリティに主眼を置いている環境にいることに気づきました。環境を再現することは法外に費用がかかります。環境の一部を取りますが、もっともらしい（一部のピースはシミュレートする必要があるか、実行しないようにシングルインスタンスモードで使用する必要があります）が、同時実行性とロードを不明瞭にするため、目的を無効にします実際のシステムが遭遇します。小さな「テスト」システムにも欠陥があります。2つのノードがある場合と64のノードがある場合は、動作が異なります。 最適化への私の通常のアプローチ（測定、何かを試す、正しさを検証する、違いを測定する、繰り返す）は、重要な問題の部分（同時実行性の堅牢性とパフォーマンスの下で効果的にステップ2と3を実行できないため、ここでは実際に機能しません負荷）。ただし、このシナリオはユニークではないようです。この種の環境でこの種のタスクを行うための一般的なアプローチは何ですか？ 関連する質問がいくつかあります。 この質問は、ハードウェア（スペクトルアナライザーなど）が利用できないことに関するものであり、（比較的）簡単にエミュレートできます。 この質問は、実稼働環境にのみ存在するバグを追跡することに関するものです。これは役に立ちますが、異なる種類のアクティビティです。

17 testing  optimization  scalability 

あると仮定nホットラインのためのラインは。 顧客がホットラインに電話をかけるたびに、コールはいずれかのn回線に転送されます。そして、n行のそれぞれに呼び出しの割合を割り当てたいと思います。2つの回線があり、1つの回線に60％が割り当てられ、もう1つの回線に40％が割り当てられていると仮定します。 各回線への呼び出しの割合は事前にわかっていますが、問題は、1日に受信される呼び出しの数がわからないことです。 総通話数を知らずに通話数を分配するにはどうすればよいですか？

17 design  algorithms 

私たちのチームは、FogBugz＆Kiln / MercurialからJira＆Stash / Gitに切り替えました。ブランチにはGit Flowモデルを使用し、機能ブランチからサブタスクブランチを追加しています（Jira機能のJiraサブタスクに関連）。プルリクエストを作成して親ブランチにマージするときにStashを使用してレビュアーを割り当てます（通常は開発しますが、サブタスクは機能ブランチに戻ります）。 私たちが見つけている問題は、複数の開発者が同じ機能、たとえばフロントエンドとバックエンドで相互に依存しているコードで作業している場合、機能ケースの最適な計画と内訳でもです。別のブランチでは、1人の開発者が他の開発者をブロックします。 開発中に、お互いのブランチ間をプルしようとしました。また、各開発者が複数のブランチからプルして、開発時に統合をテストできるローカル統合ブランチを作成しようとしました。最後に、これはこれまでのところ私たちにとっておそらく最もうまく機能しているようですが、もう少しオーバーヘッドがありますが、機能ブランチからすぐに統合ブランチを作成しようとしました。サブタスクブランチ（機能ブランチ外）がプルリクエストとコードレビューの準備ができたら、これらの変更セットをこの機能統合ブランチに手動でマージします。その後、関心のあるすべての開発者は、その統合ブランチから他の依存サブタスクブランチにプルできます。これにより、コードレビューに合格するために依存しているブランチを誰も待つことができなくなります。 これは必ずしもGitの問題ではないことを知っています。これは、独自の作業プロセスと文化が混在する、複数のブランチで相互依存するコードを操作することに関係しています。開発（厳密な統合ブランチ）のための厳格なコードレビューポリシーがない場合、開発者1は、開発者2が引き出せるように開発にマージできます。もう1つの複雑な点は、QAに機能を渡す前に、コードレビュープロセスの一部としていくつかの予備テストを行う必要があることです。バックエンド開発者2が終了し、プルリクエストがコードレビューに1週間座っている場合、フロントエンド開発者2はコードレビューアができないため、技術的にプルリクエスト/コードレビューを作成できませんバックエンド開発者2 'のためのテスト 結論として、これらのインスタンスでは、どのルートに行くかに応じて、パラレルではなくはるかにシリアルなアプローチで自分自身を見つけており、これを回避するために使用するプロセスを見つけたいと考えています。 最後に言及することは、コードのレビューとファイナライズが完了していないブランチ間でコードを共有することで実現していますが、本質的には他のベータコードを使用しています。ある程度まではそれを避けることはできないと思いますし、ある程度それを受け入れるつもりです。

17 git  workflows  branching  jira  gitflow 

リレーショナルデータベースアプリケーションと「ユーザー」オブジェクトと「メッセージ」オブジェクトがあるとします。次に、このユーザーに未読メッセージの数を表示します。 これをアーカイブする最良の方法は何ですか？ユーザーにフィールドを導入し、ユーザーがメッセージを受信した場合にカウントアップし、メッセージを読んだ場合にカウントを減らしますか？または、毎回クエリを実行して、未読のフラグが付けられたユーザーのメッセージ数を計算しますか？ 最初のアプローチはより複雑でエラーが発生しやすいと思いますが、2番目のアプローチよりもパフォーマンスが向上します。 これは通常どのように行われますか、またはより良いアプローチは何ですか？

17 database  performance 

2つのバージョンを持つゲームプロジェクトがあります。 ゲームのシンプルなバージョン、コア。 ゲームの高度なバージョン。 私は自分の公開リポジトリに最初のバージョンがあり、私だけがそれに取り組んでいます。2番目のバージョンについては、私の2人の友人と私がそれに取り組みます。重要な部分は、2つのバージョンをリポジトリに残すことです。 私はこれにブランチを使用するかもしれないと考えましたが、この質問とその答えを考慮すると、バージョン管理の観点からそうするのは良い習慣ではありません。私が知る限り、自分のリポジトリをフォークすることはできません。 ここで私のオプションは何ですか？リポジトリに両方のバージョンを保持するにはどうすればよいですか？

17 git  github  branching  forking 

私が現在取り組んでいるプロジェクトには問題があります。バグやタスクは、あまりにも新しい人や経験の浅い人に割り当てられることが多く、彼らの仕事は将来的にさらにバグを生み出すことになります。問題は、コードの品質の問題のために、ソフトウェアの一部が他の部分よりも「危険」であるということです。私は、タスクに関連するリスクを推定し、どの開発者にどのタスクが割り当てられるかに細心の注意を払うことで、この問題に対処しようとしています。 JIRAを使用しているため、この推定を追跡するために問題のラベル付けを開始しました。バグ/タスクを分類するためにいくつかのメトリックを使用することになったことに気付きました： それがどれほど明確/単純か。たとえば、多くの設計作業が必要なのか、単純なUIのバグ修正が必要なのかなどです。 コードの影響を受ける領域の保守性。うまく設計されたエリアなのか、泥だらけの大きなボールなのか。 必要な変更の影響を受けると思うプログラムの量。 考えられるカテゴリが何であるかを始めたとき、私は明確な考えを持っていなかったので、私のラベルは少し厄介です。仕事を誰かに割り当てる前に見積もりを要求できるように、新しいフィールド（「リスク」のようなもの）の追加を要求することを考えています。 誰もこのようなことを以前に扱ったことがありますか？

17 project-management  task-organization  jira 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 1970年代、Bill Gatesという男性がBASICのインタープリター、Altair BASICを開発しました。私の理解では、彼はマイクロコンピューター会社の担当者に、彼が販売したすべてのマイクロコンピューターに通訳プログラムを含めるよう説得することができました。どうやらこれはゲイツを幸運にした。私が理解していないのは、プログラミング言語が今日ほど有益ではない理由です。過去にどのような要因が利益を上げたが、今日はそうではないのか？

17 programming-languages  history  microsoft  economics 

そのため、私はいくつかの長いコンパイルを行っている間に、ODeskでC ++の一般的なテストを受けることに決め、この質問に出会いました。 言葉遣い（またはその欠如）を考えると、私が間違っていなければ、これらすべてが真実である可能性があります。 a。 int Foo() { } int Foo(int bar) { } b。 まあ、return void;意味的には間違っていますが、関数は明らかにvoid戻り値の型を持つことができます。 void Foo() { } c。これはインライン関数の定義です、はい。 d。 次の要素の配置について詳しく説明しなくても、 typedef void (*Func)(int); Func functions[2]; void Foo(int bar) { } void Bar(int foo) { } functions[0] = &Foo; functions[1] = &Bar; さらに、ラムダとファンクターを使用していつでもこれを行うことができます。 e。 void Foo(int& bar) { …

17 c++ 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 過去1年間、私はScalaコードを書いてきました（Javaのバックグラウンドから来ています）。vals、caseクラス、map / filter / lambda関数、暗黙的および型推論を使用して、よりシンプルでクリーンなコードを作成できる方法が本当に気に入りました。主にAkkaベースのアプリケーションに使用しました。 今年は、関数型プログラミングが大好きな新しいチームとScalaプロジェクトに参加しています。それらはScalazを頻繁に使用し、コードはあらゆる場所にapplicatives、context bounds、reader / writer / stateモナドで満たされ、メインメソッドもI / Oモナドに「ラップ」されます。彼らの推論は、これによりコンパイラがコードが正しいことを主張する際に「私たちのために働く」ようにし、各関数に副作用がないことです。 それでも、私の観点からすると、この構文はすべてビジネスロジックの邪魔になります。たとえば、「MyBusinessObject」のタイプは問題ありません。「List [MyBusinessObject]」、「Option [MyBusinessObject]」、「Future [MyBusinessObject]」などのタイプも同様です。それらはすべて明確な意味と目的を持っています。一方、次のようなコード： def method[M[_]: Applicative] = { case (a, b) => (ca[M](a) |@| cb[M](b)) { case t @ (ra, rb) => if (ra.result && rb.result) t.right else t.left } } それはプログラムに複雑さを追加しますか、それとも私がこのプログラミング方法に慣れていないのは私だけですか？

17 functional-programming  scala 

サードパーティのコードにいくつかの微調整や修正を加えるのが一般的な方法です（単純な要点でも、ライブラリ全体でも）。しかし、これらのコードの多くには独自のライセンスルールがあり、最終的には著作権情報を含むすべてのファイルにヘッダーが付いていることもよくあります。 これらの変更を行った後、次に行うべきことは何ですか？ライセンス情報を変更できないようにする@authorか、自分自身や@revisionタグなどで更新しようとしますか？ もう1つの一般的な問題は、サードパーティの名前空間/パッケージをプロジェクトの規則に合わせて変更することです。一部のライセンスタイプでは、ライセンスブロックにこの種の情報が含まれていますが、自由に変更できますか？ 私はこれらの質問に対する答えが各ライセンスの種類に依存することを知っているので、私の質問をより具体的にするため... 一般的なライセンスルールを考慮すると（通常、それらはマイナーな側面で異なりますよね？）、倫理上の（または少なくとも許可されている）私の変更に関する情報をライセンスブロックに自由に追加し、おそらくコードでそれを参照する方法も変更します（例：YACorp.YALibとして使用Utils.YALib）？

17 licensing  language-agnostic 

一般的に言えば、webappのデータベースにユーザーが作成したフィールドを許可することは悪い習慣と見なされますか？ たとえば、妻用のホームインベントリwebappを作成していますが、妻はさまざまなアイテム用に独自のフィールドを定義したいと考えています。私は彼女がアイテムのカテゴリを作成し、それらのカテゴリに「機能」を追加できるようにすることを計画していました。機能は、文字列として保存されたキー/値になります。たとえば、「オーディオCD」というカテゴリがある場合、「アーティスト」、「トラック」などの機能を追加できますが、「家具」などの別のカテゴリでは、「素材」などの機能を追加できます「（木材、プラスチックなど）。次に、任意のアイテムを1つ（または多数）のカテゴリに属し、それらの機能をアイテムに追加します。 これらの機能による検索には文字列の比較が必要であり、データの検証が必要ないなどの問題を見ることができます。アジャイル方法論に従って、新しいカテゴリと属性を考え出すことをお勧めします。私たちが行くように。私の例では、それは小さなユーザーベース（2人）であり、作成されるレコードの量は少ないので、それほど悪くはありません。 しかし一般的に言えば、人々は「現実の生活」でこのようなことをどのように処理しますか？

17 web-applications  database-design  patterns-and-practices