ソフトウェア工学

C ++ 11にはstd::sto@文字列からints / floats / longsを簡単にアンパックするための関数ファミリーがあることに気がつきました。しかし、その反対が実装されていないことに驚いています。なぜ標準化委員会には、std::itosints / floats / whatever（back）から文字列に戻るための関数ファミリーが含まれていないのですか？

37 c++  parsing  strings  c++11 

基幹業務ソフトウェアを使用すると、ユーザーは特定のデータをCSVとして保存できます。野生ではさまざまなフォーマット（すべて「CSV」と呼ばれる）が使用されているため、「デフォルトのフォーマット」がどのように見えるかを決めようとしています。 行/フィールドの区切りとエスケープについては、使用できる標準があります：RFC 4180。 テキストエンコーディングに関して、UTF-8は過去10年で「デフォルトのテキストファイル形式」として登場したようです。そのため、これを使用します。 残っている質問は、最初にBOMを追加するかどうかです。一般にBOMの使用に関する複数の意見と賛否両論を読んでいますが、CSVファイルでのBOMの使用に関する「公式」の推奨事項または少なくとも何らかのコミュニティコンセンサスはありますか？

37 standards  unicode  csv  file-formats 

新しいサービスに取り組んでいます。このサービスは、ユーザーのデバイス上のアプリケーションから直接呼び出される可能性があります。これらのアプリケーションは、提供するデータに応じて、組織全体の複数の開発チームによって開発およびサポートされます。 使用パターンと責任のある開発者を特定できるように、どのアプリケーションがどのリクエストを送信しているかを特定したいと考えています。（疑念を避けるため、ユーザー認証は個別に処理されます。） 私たちのソリューションは、アプリケーションごとに1つのAPIキーを必要とすることです。その後、開発チームの連絡先の詳細を取得します。 APIキーを摩擦の原因にしたくはありませんが、開発者がそれらを他のチームの同僚と共有するのではないかと心配しています。つまり、1つのアプリケーションだけのトラフィックを識別できなくなります。 APIキーを内部で共有しないように開発者にインセンティブを与えるにはどうすればよいですか？

37 api  enterprise-development 

私は、多くの問題に苦しんでいる非常に貧弱に設計されたソフトウェアプロジェクトへの変更を提案しています。高レベルでは、プロジェクトはフロントエンドでAngularを利用し、さまざまなREST APIを使用します。それはすべて素晴らしいことです（私たちの技術やツールを変更する必要はありません）。問題は、コードベースがUIでサーバー側のAPIよりも不均衡に大きいことです。ビジネスロジックの多くはUIに存在し、REST APIはUIレイヤーへの単純なCRUDデータベースインターフェイスです。 たとえば、顧客へのPOSTは顧客レコードを作成し、PUTはその顧客を変更します。それ以上でもそれ以下でもありません。ただし、ビジネスロジックはそれよりも要求が厳しくなります。顧客を作成する一般的なプロセスは、1つのデータベースレコードを挿入するだけではありません。他の必要なテーブルにデータをプロビジョニングし、特定の検証と計算などを実行します。この動作のすべてをカプセル化する単一のPOST / PUT呼び出しを行い、消費クライアントの負荷を軽減します。 したがって、私の視点では、この包括的なオーケストレーションはUIではなくサーバー（フルコントロール、ログなど）上に存在する必要がありますが、1つの反論は、このアプローチはRESTfulではなくなるということです。したがって、既存の技術スタックを継続することを推奨するが、コードが属する場所で基本的なシフトを実装することが推奨される場合、このアプローチをどのように説明するのが最適かはわかりません。

37 rest  api-design  enterprise-architecture 

特定のフレームワークで使用する予定のシステムまたはアプリケーションを開発する場合、フレームワークを考慮せずにシステムを設計するのがベストプラクティスですか、それとも「フレームワークを使いやすい時間で」という考え方でシステムを設計することをお勧めしますこれとともに"。

37 development-process  systems 

コンストラクターで「新しい」を使用すること（単純な値オブジェクト以外のオブジェクト）を使用すると、単体テストが不可能になるため（これらのコラボレーターも作成する必要があり、モックできないため）悪い習慣であると読みました。ユニットテストの経験があまりないため、最初に学習するいくつかのルールを収集しようとしています。また、これは使用されている言語に関係なく、一般的に有効なルールですか？

37 unit-testing  constructors 

現在のプロジェクトのユニットテストをいくつか書き始めました。私は実際にそれを経験していません。最初に完全に「取得」したいので、現在IoCフレームワークもモックライブラリも使用していません。 ユニットテストでオブジェクトのコンストラクターにnull引数を提供することに何か問題があるのではないかと思っていました。サンプルコードを提供します。 public class CarRadio {...} public class Motor { public void SetSpeed(float speed){...} } public class Car { public Car(CarRadio carRadio, Motor motor){...} } public class SpeedLimit { public bool IsViolatedBy(Car car){...} } さらに別のCar Code Example（TM）は、質問にとって重要な部分のみに縮小されました。次のようなテストを作成しました。 public class SpeedLimitTest { public void TestSpeedLimit() { Motor motor = new Motor(); …

37 unit-testing 

データベース内の従業員データを更新する方法があります。Employee「更新」オブジェクト手段は、実際に新しいオブジェクトをインスタンス化するためのクラスは、不変です。 UpdateメソッドにEmployee更新されたデータを含む新しいインスタンスを返すようにしたいのですが、メソッドの責任は従業員データを更新し、データベースから新しいオブジェクトを取得Employeeすることであると言えますが、単一責任原則に違反しますか？ DBレコード自体が更新されます。次に、このレコードを表す新しいオブジェクトがインスタンス化されます。

37 single-responsibility 

たとえば、{現在は比較的小さいが、将来的には大きくなる可能性がある}プロジェクトで、非常に小さなチームで作業を始めたばかりだとしましょう。これは、実際の世界の他の開発者が使用することを目的とした実際のプロジェクトであり、学期の終わりに廃棄されることを意図した学術プロジェクトではないことに注意してください。 ただし、コードはまだ他の人にリリースされていないため、まだ決定が確定していません。 方法論 コーディングを開始して、すべてのコンポーネントがどのように正確に相互作用するかを明確に理解する前に、ピースを一緒に合わせることが好きです（ボトムアップ設計）。もう1人は、最初に設計全体を行い、ソリューションをコーディングする前にすべてのコンポーネントと通信の詳細を特定することを好みます。 既存のシステムを模倣するのではなく、新しいシステムで作業しているため、適切な最終設計がどのように見えるかが必ずしも明らかではないと想定します。そのため、チームでは、チームメンバーごとに、最終製品にどのような要件が必要であるかについてのアイデアが異なることがあります。 ボトムアップ開発者がいくつかのコードを書くとき、トップダウン開発者は、コードが手元の問題を解決するかもしれないという事実にもかかわらず、設計で想定される潜在的な将来の問題のためにそれを拒否します。問題の解決策をコーディングする前に。 トップダウン開発者がコードを書き始める前に完全な設計と想定される問題を解決しようとすると、ボトムアップ開発者は実際に問題の一部が実際に発生するとは思わないため、ボトムアップ開発者はそれを拒否します、および要件と制約がより明確になったときに、設計を将来変更する必要があるかもしれないと考えています。 問題 これにより、ボトムアップ開発者は設計上の欠陥のためにボトムアップ開発者が書いたソリューションを廃棄すべきであると頻繁に判断するため、ボトムアップ開発者が時間を無駄にしてしまうという問題があります。 -コードを記述します。 トップダウン開発者は、作業を並列化する代わりに、ボトムアップ開発者と正しい設計を行うために頻繁に座って、2つをより速くなる可能性があるまで直列化するため、時間が無駄になります1人が2人よりも仕事をする。 両方の開発者は協力を続けたいと考えていますが、実際にこの組み合わせが実際にどちらかを支援しているようには見えません。 目標 共通の目標は、明らかにコーディングの効果を最大化する（つまり、時間の浪費を最小化する）ことと、有用なソフトウェアを書くことです。 質問 簡単に言えば、どのようにこの問題を解決し、この状況に対処しますか？ 時間を無駄にしないと考えることができる唯一の効率的なソリューションは、各開発者が自分のデザインのスタイルに従うようにすることです。しかし、これは、コードをレビューして、お互いの変更を実際に承認する必要があるとき、および他の人が使用するための一貫したフレームワークを設計しようとしているときに聞こえるよりも困難です。 もっと良い方法はありますか？

37 design  development-methodologies  methodology 

オープンソースソフトウェアをすぐにリリースすることの道徳的責任は何ですか？たとえば、完全にテストされていない、完成に近い製品です。 プログラマーに期待することは何ですか？完全にテストされるまで待つか、オープンソースにリリースしてから、さらに開発、テスト、および進歩を続けますか？ 恐れは、ソフトウェアがオープンソースであり、潜在的に消費者の問題につながる可能性があるということです。 これは根拠のない恐怖ですか？

37 open-source 

多くの場所で、UIコンポーネントを更新するときにUIスレッド上にいること（具体的には、Javaスイングでは、イベントディスパッチスレッド上にいることを確認することは呼び出し側の責任であることは、標準的な知恵1です） 。 これはなぜですか？イベントディスパッチスレッドは、MVC / MVP / MVVMのビューの問題です。ビュー以外の場所で処理するには、ビューの実装と、そのビューの実装のスレッドモデルとの間に密結合を作成します。 具体的には、Swingを使用するMVC設計のアプリケーションがあるとします。呼び出し元がイベントディスパッチスレッドのコンポーネントの更新を担当している場合、JavaFX実装のSwing View実装を交換しようとすると、代わりにJavaFXアプリケーションスレッドを使用するようにすべてのプレゼンター/コントローラーコードを変更する必要があります。 だから、私は2つの質問があると思う： UIコンポーネントのスレッドの安全性を確保するのは、呼び出し側の責任なのはなぜですか？上記の推論の欠陥はどこにありますか？ これらのスレッド安全性の懸念を疎結合しながら、適切にスレッドセーフであるようにアプリケーションを設計するにはどうすればよいですか？ MCVE Javaコードを追加して、「呼び出し側の責任」が意味することを説明します（ここには、私がやっていませんが、できる限り最小限にするために他の良い習慣があります）。 責任者である発信者： public class Presenter { private final View; void updateViewWithNewData(final Data data) { EventQueue.invokeLater(new Runnable() { public void run() { view.setData(data); } }); } } public class View { void setData(Data data) { component.setText(data.getMessage()); } } …

37 mvc  multithreading  user-interface 

質問に関連するチャットでの質問があり（質問自体はこの質問とは無関係です）、Pythonをまったく知らないかもしれないことが明らかになりました。 私の考えでは、用語は言語によって異なりますが、一般的に機能を次のように分類できます。 [無料]機能 静的メソッド/静的メンバー関数 非静的メソッド/非静的メンバー関数 どうやらPythonには、上記のカテゴリに当てはまらない別の種類の関数があります。それはメソッドですが、「そのクラスを知りません」。 Pythonの「クラスメソッド」と「インスタンスメソッド」とは何ですか？

37 python  terminology 

whileループが本質的に再帰かどうか疑問に思いましたか？ なぜなら、whileループは最後に自分自身を呼び出す関数とみなすことができるからだと思います。再帰ではない場合、違いは何ですか？

37 recursion  loops 

私が取り組んでいるC ++プロジェクトのインクルードをクリーンアップしていますが、特定のファイルで直接使用されるすべてのヘッダーを明示的にインクルードする必要があるのか​​、最低限だけインクルードする必要があるのか​​疑問に思っています。 以下に例を示しEntity.hppます。 #include "RenderObject.hpp" #include "Texture.hpp" struct Entity { Texture texture; RenderObject render(); } （の前方宣言RenderObjectはオプションではないと仮定しましょう。） 今、私はそれがRenderObject.hpp含まれていることを知っていますTexture.hpp-私はそれぞれRenderObjectがTextureメンバーを持っているのでそれを知っています。それでも、私は明示的に含めるTexture.hppにはEntity.hpp、それはそれはに含まれているに依存することをお勧めします場合、私はわからないので、RenderObject.hpp。 だから：それは良い習慣ですか？

37 c++  c  headers  include 

オブジェクト指向プログラムに考えられる設計パターンはありますか？これは、最近、のDoorクラスの実装を見たためですLock。これはテストの一部であり、答えは、コードがNull Objectパターンに従っていることです。 class Lock { public: virtual void close() = 0; virtual void open() = 0; virtual bool is_open() const = 0; virtual ~Lock() { } }; class DummyLock : public Lock { private: DummyLock(); DummyLock(const DummyLock&) = delete; DummyLock& operator=(const DummyLock&) = delete; private: void close() { } void …

37 design  design-patterns  object-oriented  object-oriented-design