ソフトウェア工学

価値の観点から、私は実際にユニットテストの2つのグループを見ています： 自明でないロジックをテストするテスト。それらを（実装前または実装後のいずれかで）記述すると、いくつかの問題/潜在的なバグが明らかになり、将来ロジックが変更された場合に備えて自信を持てるようになります。 非常に簡単なロジックをテストするテスト。これらのテストは、テストよりもドキュメントコード（通常はモックを使用）に似ています。これらのテストのメンテナンスワークフローは、「一部のロジックが変更され、テストが赤になりました-このテストを作成した神に感謝します」ではなく、「一部の些細なコードが変更され、テストが偽陰性になりました-利益を得ることなくテストを維持（書き換え）する必要があります」 。ほとんどの場合、これらのテストは維持する価値がありません（宗教上の理由を除く）。そして、多くのシステムでの私の経験によると、これらのテストはすべてのテストの80％に相当します。 私は他の人が値によるユニットテストの分離のトピックでどう思うか、それが私の分離にどのように対応するかを見つけようとしています。しかし、私が主に目にしているのは、フルタイムのTDDプロパガンダか、テストは役に立たず、ただ書くだけのコードプロパガンダです。途中で何かに興味があります。あなた自身の考えや記事/論文/本への言及を歓迎します。

13 unit-testing  tdd 

UXデザイナーは通常、開発者がSprint X + 1で実装するSprint Xのストーリーを持っています（UXデザイナーと開発者/テスターは1つのチームに所属しています）。これは理にかなっていると思います。スクリーンモックアップと明確な仕様がなければ、スプリントプランニング中に作業を実際に見積もることができないからです。 ただし、スクラムでは、ユーザーに価値を提供するユーザーストーリーのみが想定されています。私たちの場合、UXデザインストーリーはそのような価値を提供しません（バックロググルーミングアクティビティに似ています）。また、通常、スクラムのコーチは、スプリントの開始前に完全な仕様を持つことを推奨しません。 それで、私たちのアプローチには欠点がありますか？うまくいくように思えますが、スクラムの原則にいくらか反しています。

13 scrum  user-experience 

私はプロジェクトに取り組んでいます。ある時点で、データベースに、すべてのレコードが使用するわけではない複数の列を持つ単一のテーブル、または複製されたスキーマを持つ複数のテーブルが必要かどうかを決定する必要がありました。 複数のスポーツを処理できるスポーツ情報アプリケーションを作成しています。たとえば、NBA、NHL、MLB、NFLを処理できます。各スポーツには、チーム、スケジュール、怪我、選手情報など、非常に似た概念があります。 もちろん、データソースは同じスキーマ内の各データを提供しません。各スポーツには、ベンダーからデータを受け取る異なるスキーマがあります。 共通性を判断するためにデータフィードの事前分析を行うのに十分な時間（クライアントの要求）がなかったため、賭けをヘッジし、「安全な賭け」を行い、すべてのテーブルのセットの代わりに、スポーツごとに個別のテーブルを作成しました使用されるスポーツ。 その結果、いくつかのテーブルでスキーマが複製され、データベースへのインターフェイス（ストアドプロシージャなど）も複製されます。NBA_Game、NFL_Game、NBA_Team、NFL_Teamなどがあります。各テーブルには、他のテーブルにはないプロパティがいくつかあり、いくつかのプロパティは共有されています。4〜5回のスポーツで5〜10個のテーブルが続きます。これが完全に悪いことであるかどうかはまだわかりません。すべてのスポーツが使用するわけではないプロパティを持つテーブルの単一セットを持つ代替案は、それ自体も扱いにくいかもしれません。 これを行った人は、この種の設計の落とし穴にぶつかり、ここで自分の経験を共有できますか？将来の困難な方法を学ぶのではなく、今私が知るのに役立つかもしれないことは何ですか？すべてのレコードが使用するわけではない列を使用して、1つの大きなテーブル/テーブルのセットを使用して、別の方法でそれを実行しましたか？どんな落とし穴に遭遇しましたか？ 過去に使用したテーブル継承など、より適切に機能する代替手段はありますか？ ありがとう

13 database  database-design  relational-database 

データモデル/データベースのプレゼンテーションレイヤーとエンティティフレームワークにJSONを使用したMVCを活用するWebサイトの作成を実験しています。私の問題は、ModelオブジェクトをJSONにシリアル化することに関係しています。 私は自分のデータベースを作成するためにコードファーストの方法を使用しています。コードファーストの方法を実行するとき、1対多の関係（親/子）では、子が親への参照を持つ必要があります。（サンプルコードはタイプミスかもしれませんが、写真を取得します） class parent { public List<child> Children{get;set;} public int Id{get;set;} } class child { public int ParentId{get;set;} [ForeignKey("ParentId")] public parent MyParent{get;set;} public string name{get;set;} } JsonResultを介して「親」オブジェクトを返す場合、「子」にはクラス親のプロパティがあるため、循環参照エラーがスローされます。 ScriptIgnore属性を試しましたが、子オブジェクトを見ることができません。ある時点で、親子ビューに情報を表示する必要があります。 循環参照を持たない親と子の両方の基本クラスを作成しようとしました。残念ながら、baseParentとbaseChildを送信しようとすると、これらは派生クラスとしてJSONパーサーによって読み取られます（この概念が私を逃れていると確信しています）。 Base.baseParent basep = (Base.baseParent)parent; return Json(basep, JsonRequestBehavior.AllowGet); 私が思いついた1つの解決策は、「ビュー」モデルを作成することです。親クラスへの参照を含まないシンプルなバージョンのデータベースモデルを作成します。これらのビューモデルにはそれぞれ、データベースバージョンを返すメソッドと、データベースモデルをパラメーターとして取得するコンストラクターがあります（viewmodel.name = databasemodel.name）。この方法は機能しますが、強制されているようです。 注：ここで投稿しているのは、これがより議論に値すると思うからです。別のデザインパターンを活用してこの問題を克服することも、モデルで別の属性を使用するのと同じくらい簡単にすることもできます。私の検索では、この問題を克服する良い方法を見ていません。 私の最終目標は、サーバーと通信してデータを表示するためにJSONを大幅に活用する素晴らしいMVCアプリケーションを持つことです。レイヤー全体で一貫したモデルを維持しながら（または、私が思いつく限り）。

13 asp.net-mvc  entity-framework  orm  json 

私は組織のQA /テストマネージャーであり、今日までソフトウェアの品質を確認しました（テストの作成と実行、バグの修正）。誰がスクラムでこれを検証しますか？チームがすべての適切なテストを作成して実行したことをどのようにして知ることができますか？一方、私が検証を続けた場合、チームは十分な権限を与えられているとは感じないでしょう。しかし、「完了」が実際に「完了」であるという検証プロセスが必要です。何を指示してるんですか？

13 scrum 

バックグラウンド 会社がサーバーを保守するのを手伝う契約をしています。私はいくつかのマイナーなPHPプロジェクトに取り組んでいますが、パフォーマンスの問題を調べ、最近ではハッカーのログをスキャンしています。 これらの人々はしばらくの間サーバーを実行しており、その最後の部分にレガシーアプリケーションと呼ぶものがあります。マジッククオート、グローバル変数（で$id上書き可能$_GET['id']）を使用し、.htaccessを唯一のセキュリティとして使用する場合があります。セキュリティとプログラミングの悪夢。 私たちは過去に、主にSQLインジェクションでハッキングされました。SQLインジェクションはSLEEP(99999999)コマンドを実行し、DOS攻撃として機能します。幸いなことに、彼らは「小さなボビーテーブル」を実行しませんでした。 XKCD：http ://xkcd.com/327/ そのため、脆弱なSQLステートメントをmysql_query()（mysqliではなく）PDOトランザクションに書き直しました。私はまたのためのクエリを分析していますSLEEPとUNION、我々が使用しないが、注射は持っています。ここまでは順調ですね。 最新号 最近、電子メールアドレスがスパマーによって作成されたと思われるものに変更されるなど、ユーザーのDBのレコードが変更されていると言われています。 彼らの列には列がないことに気づいたlast_modifiedので、誰が言うまでもなく、いつ変更されたかさえ知ることができませんでした。私はそのコラムを追加しましたが、それはかろうじて最初のステップです。 このテーブルを見ると、パスワードがソルト化されておらず、ハッシュ化されておらず、プレーンテキストとして保存されていることがわかりました。 クライアント通信 請負業者として、狂人のように腕を振り回すことなく、状況全体についてどのようにアプローチできますか？何かアドバイス？私は穏やかなアプローチを考えていました、 問題＃1 あらすじ これが問題である理由 これが修正されない場合に何が起こるか 修正案 問題＃2 あらすじ これが問題である理由 これが修正されない場合に何が起こるか 修正案

13 php  apache  security  mysql 

次のようなS＃arpアーキテクチャを使用して実装されたCQRSパターンの一部があります。 public class MyCommand { public CustomerId { get; set; } // some other fields } public class MyCommandHandler<MyCommand> : ICommandHandler<MyCommand, CommandResult> { Handle(MyCommand command) { // some code for saving Customer entity return CommandResult.Success; } } なぜCommandデータと処理メソッドの両方を含むクラスを持たないのでしょうか？コマンド処理ロジックをコマンドプロパティとは別にテストする必要がある場合、一種のテスト容易性の利点ですか？または、さまざまな実装で1つのコマンドを処理する必要がある、頻繁なビジネス要件ICommandHandler<MyCommand, CommandResult>ですか？

13 c#  design-patterns  architecture  cqrs 

私は、サードパーティのREST APIからデータをクエリする新しいプロジェクトに取り組んでいます。これはリアルタイムのスポーツデータフィード用であるため、フィードはゲームが実際に行われているときにのみ機能します。 サードパーティは優れたドキュメント（XSDなど）を提供しますが、ゲームの発生をシミュレートする方法がないため、このAPIに対して記述したコードをテストするには、実際のゲームが発生するのを待つ必要があります。 私の唯一の手段は、自分でゲームをシミュレートするコードを書くことですが、多くの作業のように思えます。これにどのようにアプローチしますか？

13 api  rest 

Haskellには、一般的なLispとの明らかな類似性を持つ「汎用関数」という概念があります。Haskellの経験も共通のLispの経験もないため、ここでは非常に近似するかもしれません。これは、to_stringすべてのタイプの文字列表現を定義する汎用機能を定義できることを意味します。もちろん、特別な場合にはto_string機能を定義する必要がありますが、シグネチャがの関数がありますα → string。 OCamlのように、Haskellでもタイプは消去されますか？はいの場合、Haskellでの「ジェネリック関数」の実装は、型が動的であり、したがって消去されない一般的なLispの実装とどのように異なりますか？ 実装の詳細はコンパイラ固有のものであることを理解していますが、おそらく多くまたはすべての実装に共通する規定があります。

13 haskell  type-systems  common-lisp 

私はやや防御的なプログラマーであり、Microsoft Code Contractsの大ファンです。 現在、私は常にC＃を使用できるわけではなく、ほとんどの言語で私が持っている唯一のツールはアサーションです。だから私は通常、このようなコードになります： class { function() { checkInvariants(); assert(/* requirement */); try { /* implementation */ } catch(...) { assert(/* exceptional ensures */); } finally { assert(/* ensures */); checkInvariants(); } } void checkInvariants() { assert(/* invariant */); } } ただし、このパラダイム（または、あなたがそれを呼ぶものは何でも）は、多くのコードを乱雑にします。 私はそれが本当に努力の価値があるかどうか、そして適切な単体テストがすでにこれをカバーするかどうか疑問に思い始めました？

13 testing  code-contracts 

読むアイテムの数が不明なリーダーを繰り返し処理する必要があり、そのための唯一の方法は、最後まで読み続けることです。 これは多くの場合、無限ループが必要な場所です。 ブロック内のどこかに or ステートメントtrueがなければならないことを示すalways があります。breakreturn int offset = 0; while(true) { Record r = Read(offset); if(r == null) { break; } // do work offset++; } あり、二重ループ方式の読み取りが。 Record r = Read(0); for(int offset = 0; r != null; offset++) { r = Read(offset); if(r != null) { // do …

13 c#  code-quality  readability 

Haskellの型クラスとC＃のインターフェイスを比較しようとしています。があるとしFunctorます。 ハスケル： class Functor f where fmap :: (a -> b) -> f a -> f b この型クラスをC＃のインターフェイスとして実装する方法は？ 私が試したもの： interface Functor<A, B> { F<B> fmap(Func<A, B> f, F<A> x); } これは無効な実装であり、実際Fに返されるべきジェネリック型にこだわっていfmapます。どのように定義すべきか、どこで？ FunctorC＃で実装することは不可能ですか？なぜですか？それとも別のアプローチがありますか？

13 c#  haskell 

List（：+）の追加操作の実行時間は、のサイズに比例して増加することを読みましたList。 に追加することListは、かなり一般的な操作のようです。なぜこれを行う慣用的な方法がコンポーネントを前に付けてからリストを逆にする必要があるのですか？実装はいつでも変更される可能性があるため、設計の失敗にもなりません。 私の観点からは、先頭と末尾の両方がO（1）である必要があります。 これには正当な理由がありますか？

13 language-design  scala  list  immutability 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 6年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け付けていません。 私は常に手続き型言語でプログラミングしてきましたが、現在はオブジェクト指向に向かっています。私が直面した主な問題は、効果的な方法でオブジェクトの向きを練習する方法が見つからないことです。私のポイントを説明します。PHPとCを学んだときは、練習するのはとても簡単でした。何かを選択し、そのアルゴリズムを考えるだけでした。 たとえば、PHPでは、座って考えてみるのが問題でした。「実は、製品を追加できる管理領域を備えたアプリケーションを1つ作成してみましょう」。これは非常に簡単でした。ユーザーを登録し、ユーザーをログインし、製品を追加するアルゴリズムを考える必要がありました。これらをPHPの機能と組み合わせて、練習するのに良い方法でした。 さて、オブジェクト指向では、さらに多くのものがあります。アルゴリズムについて考えるだけでなく、要件をより深く分析し、ユースケースを記述し、クラス図、プロパティとメソッドを理解し、依存関係の注入などを設定します。 主なポイントは、私がオブジェクト指向を学習している方法では、良いデザインが重要であるように思えるのに対し、手続き型言語では曖昧なアイデアで十分だったということです。手続き型言語では、設計なしで良いソフトウェアを書くことができると言っているのではなく、それを実践するために実行可能であるだけであり、オブジェクト指向では、実行するためでさえ、適切な設計なしでは行けないようです。 これは問題のようです。練習するたびに多くの要件やユースケースなどを把握する必要がある場合、オブジェクトの向きを改善するのに良い方法ではないようです。練習するたびにアプリのアイデアを1つ持つようにしています。 そのため、オブジェクトの向きを練習する良い方法は何ですか？

13 object-oriented  learning 

/ dev / randomはエントロピーの優れたソースであり、通常使用されるものです-少なくともJavaでGCを読んでいるように、ガベージコレクションデーモンが非決定的に実行されることは受け入れられているようです。これが正しい場合、変数/ dev / randomの代わりに、ガベージコレクションのタイミングをエントロピーのソースとして使用しないのはなぜですか？

13 random  garbage-collection