ソフトウェア工学

システム開発ライフサイクル内で働く専門家、学者、学生向けのQ&A

6
パフォーマンスと再利用性
パフォーマンスを犠牲にすることなく再利用可能な関数を作成するにはどうすればよいですか?関数を再利用可能にする方法で関数を記述したい(たとえば、データ環境について仮定しない)状況に繰り返し直面していますが、プログラムの全体的な流れを知っているので、最も効率的ではありません。方法。たとえば、株式コードを検証するが再利用可能な関数を記述したい場合、レコードセットが開いているとは限りません。ただし、関数が呼び出されるたびにレコードセットを開いたり閉じたりすると、数千行をループするときにパフォーマンスに大きな影響が出る可能性があります。 だからパフォーマンスのために私は持っているかもしれません: Function IsValidStockRef(strStockRef, rstStockRecords) rstStockRecords.Find ("stockref='" & strStockRef & "'") IsValidStockRef = Not rstStockRecords.EOF End Function しかし、再利用性のためには、次のようなものが必要になります。 Function IsValidStockRef(strStockRef) Dim rstStockRecords As ADODB.Recordset Set rstStockRecords = New ADODB.Recordset rstStockRecords.Open strTable, gconnADO rstStockRecords.Find ("stockref='" & strStockRef & "'") IsValidStockRef = Not rstStockRecords.EOF rstStockRecords.Close Set rstStockRecords = Nothing End Function 数千行/レコードにわたるループ内から呼び出されたときに、そのレコードセットを開いたり閉じたりするパフォーマンスへの影響は深刻ですが、最初の方法を使用すると、関数の再利用性が低下するのではないかと心配です。 …


4
クラスの単体テストを分離することは悪い習慣ですか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私のクラスは通常、最大で約5〜20のメソッドを持っています。これは、単体テストを持つクラスがメソッドの約2倍(counting dataProviders、setUpなど)を持っていることを意味します 私は、テストを2〜3つのクラスに分けようと考えました。単一の責任の原則に従っても、20のメソッドではなく、それぞれ10のメソッドを持つ2つのテストクラスを好むからです。 それは悪い習慣ですか?テストクラスは垂直に成長しますが、クラスのすべてのテストを1つだけにするとよいですか?

7
whileループとforループの証明可能性
私にはこの先生がいます、彼はとても賢いです(時々、ハハ)彼は良いプログラマーがwhileループの代わりにforループを使用しようとすると言いました。彼がこの理由を挙げたのは、whileループは証明できるためです。たとえば、whileループで何が起こるかを完全に説明できるのに、ループではそれを行うことができないからですfor。彼はまた、NASAプログラマーがwhileループのみを使用していforて、これが原因でループを実行できないことについても述べています。 私はこれを理解するのにかなり苦労しています。両方のループについて、それらがどのように機能するかを詳細に説明できますか?両方のためにあなたはいつも何が起こるかを知っていますか? 誰かがwhileループを証明できる理由を私に説明できますか(そのため、for少なくとも場合によってはループよりも優れている可能性があります)。 編集: 多分彼は次のように言っていました: 2:すべてのループには上限が固定されている必要があります。チェックツールが、ループの反復回数の事前設定された上限を超えてはならないことを静的に証明することは、自明である必要があります。ループ境界が静的に証明できない場合、ルールは違反していると見なされます。 ただし、これでも、whileループとforループの違いについては何も言われていません。
8 loops 

2
要求仕様を関数型プログラミングの述語ロジックに変換することは一般的な方法ですか?
最近、Haskellで実装されている小さなプロジェクトに取り組むよう割り当てられました。オブジェクト指向/命令的な背景から来て、コーディングの前に要件/ユーザーストーリーをユースケースとシーケンス図に変換することに慣れています。 しかし、私が割り当てられているHaskellプロジェクトでは、チームはユーザーの要件を述語論理命題/ステートメントに変換することを好みます。セーフティクリティカルなシステムやソフトウェアエンジニアリングの正式な方法でロジックが使用されていることは知っていましたが、日常のプログラミングではそれほどではありませんでした。これはFPレルムで一般的な方法ですか?これについてどこでもっと知ることができますか? 要件を「モデル化」し、述語から「関数」を導き、関数が操作するために必要な型仕様を書き留めるのは自然な方法のようです。しかし、それは実際にどのように行われる/推奨されるのですか、それとも私のチームに固有のものですか? (ここでこの質問をする前に徹底的に検索してみました。「関数型プログラミングの要件仕様」(および異なるキーワードの同義語と組み合わせ)を検索しても、意味のあるものは何もありません。)

2
Java Systemクラスの実装
Java Systemクラスには、さまざまなデータメンバーとそこに存在するのに最適なメソッドが含まれています。例えば: System.in (variable) System.err (variable) System.out (variable) System.exit(int) System.gc() System.getSecurityManager() など、しかし、私がそこにいることを理解していない方法があります: System.arraycopy(Object, int, Object, int int) 1つの配列を別の配列にコピーすると、Arraysクラスに属しているように感じます。ドキュメントから以下: このクラスには、配列を操作するためのさまざまなメソッド(ソートや検索など)が含まれています。このクラスには、配列をリストとして表示できる静的ファクトリーも含まれています。 配列を操作する方法は、この結論を私に指摘するものです。ある配列を別の配列にコピーすることは、確かに配列操作ですよね? 私の質問はそう:なぜあるarraycopy()でSystem? 初期のJava Systemクラス実装の遺物ですか?このメソッドは非推奨としてマークされていないため、少し迷っています。さらに、JavaのcamelCase標準に準拠していないため、初期のライブラリ設計の遺物であるという考えに立ち返ります。
8 java  design 

4
小さなクラスにリファクタリングする前に大きなクラスを分析する最良の方法は?
序文 大規模なスパゲッティコードクラスをリファクタリングする方法を探しているのではありません。そのトピックは他の質問で取り上げられています。 質問 4000行を超え、2000行を超える単一の巨大な更新メソッドを持つ別の同僚が作成したクラスファイルを理解するための手法を探しています。 結局、私はこのクラスのユニットテストを構築し、DRYと単一責任原則に従う多くの小さなクラスにリファクタリングしたいと考えています。 このタスクをどのように管理およびアプローチできますか?最終的には、クラス内で発生するイベントの図を描き、次に抽象化機能に進むことができるようになりたいのですが、クラスの責任と依存関係が何であるかをトップダウンで把握するのに苦労しています。 編集:人々が入力パラメーターに関連するトピックをすでにカバーしている回答では、この情報は初心者向けです。 この場合、クラスのメインメソッドには入力パラメーターがなく、停止するように指示されるまでwhileループが実行されます。コンストラクターもパラメーターを取りません。 これにより、クラス、その要件、および依存関係の混乱が増します。クラスは、静的メソッド、シングルトンを介して他のクラスへの参照を取得し、すでに参照しているクラスを介して到達します。

1
遅延コレクションが不要になったときに、データベースコンテキストが適切に破棄されることをどのように保証しますか?
ここでベストプラクティスの種類の答えを探しています。 実装するクラスと対話するためのベストプラクティスIDisposableは次のUsingステートメントによるものであることを考えると、MVCでEFレイジーロードを使用するためのベストプラクティスは何ですか? コントローラーメソッドの例: <HttpGet> Public Function Schedule(ByVal id As Int64) As ActionResult Dim model As Schedule = Nothing Using database As dataContext = New dataContext model = (From s In database.Schedules Where s.ScheduleID = id Select s).FirstOrDefault End Using Return View(theSchedule) End Function この例では、モデルがビューに到着するまでにデータベース[dataContext]が破棄されるため、遅延読み込みが機能しなくなります。 だから私は質問だと思います: MVCで遅延読み込みを使用するためのベストプラクティスは何ですか?データベースコンテキストが適切に破棄され、メモリリークが発生しないことをどのように保証しますか?

2
REST APIのグループ化とネスト
私の質問は、REST APIを集約またはグループ化するベストプラクティスについてです。多くの異なるベンダー、データソースなどがあるシナリオがあり、REST APIをグループ化することは、システムを保守可能に保つために非常に意味があると思います。 他のシステムで同じエンティティを作成するために、他の多くの(類似した)API呼び出しをトリガーする単一のAPI呼び出しがある多くのシナリオがあります。たとえば、エンティティ "user"の例: フロントエンドがREST APIを呼び出す:PUT ... / user 私が想定しているのは、上記のAPIをリッスンするコードが複数のREST PUT呼び出しを行って、ベンダーA /ユーザー、ベンダーB /ユーザー、ベンダーC /ユーザー、内部システムA /ユーザー、内部システムB /ユーザーなどを呼び出すことです。 このような: +-------------------+ +--------+ PUT +-----------+ CALL | Vendor A API | | | +-------> | user +--------> | | | | | +-----------+ +-------------------+ | | | | Front | PUT +--------++ PUT …

2
リストよりもPythonジェネレーターを優先する必要がありますか?
Pythonイテレータはメモリ効率が非常に高くなります。リストだけでなく、常にジェネレータを使用した方がよいですか?どのような場合に、単純な配列を使用すべきですか? たとえば、これの代わりに: emails = [user.email for user in users] 私はこれを好むべきですか?: emails = (user.email for user in users) 注:「イテレータ」ではなく「ジェネレータ」を意味します。

2
大量のデザインを再試行
メッセージングにActiveMQを使用するJavaシステムがあります。また、システムは1秒間に約400から600のトランザクションを処理し、すべてがスムーズに実行されていても問題はありません。システムは、これらのトランザクションを外部システムに送信する必要もあります。 外部システムが長時間(たとえば1〜2時間)ダウンしている場合、私たちが行うことは、キューの停止中に外部システムに正常に送信されなかった失敗したメッセージ(再試行キューと呼ばれるもの)をドロップすることです。 。 これらのメッセージをタイムリーに処理して、外部システムに回復する十分な時間を与える必要があります。 私たちはいくつかのアプローチを試みましたが、どれも完全に機能するようには見えません。それらのほとんどは、処理するメッセージの数が少ない場合に機能します。 アプローチ#1: JMSヘッダーにタイムスタンプを設定するActiveMQ遅延を使用しました(詳細については、こちらをご覧ください:http : //activemq.apache.org/delay-and-schedule-message-delivery.html)。キューには数百または数千のメッセージがあります。 50万件以上のメッセージがあると、メッセージが失われることがわかりました。 たとえば、2万通のメッセージでもメッセージが消えたことがわかります。 メッセージが1時間に最大12回試行されるように、遅延を5分に設定しました。外部システムが1時間ダウンしたとき、すべての20kメッセージが少なくとも12回再試行されると予想しました。 5分ごとに消費すると、次のことがわかりました。 試行1:20kメッセージ試行2:20kメッセージ 試行7:19987メッセージ試行10:19960メッセージ試行12:19957メッセージ 時々、すべての2万通のメッセージが処理されましたが、テスト結果に一貫性がありませんでした。 アプローチ#2: ActiveMQの再配信ポリシーを使用しました。接続ファクトリレベルでポリシーを設定し、セッションを処理し、外部システムがダウンしているときに例外をスローするため、ブローカーは再配信ポリシーの設定に基づいてメッセージを再配信し続けます。このアプローチも、停止がより長く続く場合にはうまく機能せず、ノンブロッキングのコンシューマーを用意する必要はありません。ディスパッチキューレベル自体で機能し、着信トランザクションが多い場合はキューに負担をかけます。 アプローチ#3: X分ごとに起動するQuartzスケジューラーを使用して接続を作成し、コンシューマーが再試行キューからメッセージを取得してさらに処理を試み、外部システムがまだダウンしている場合は、失敗したメッセージをキューの後ろに置きます。このアプローチには多くの問題があり、接続や消費者などを管理する必要がありました。 たとえば、キュ​​ーにメッセージが2つある場合、メッセージの数よりも多くのコンシューマーがあると、メッセージがコンシューマーによってピックアップされ、同じコンシューマーがメッセージを再試行にドロップします(外部システムはまだダウンしています)、別のコンシューマーがそれをピックアップしているため、コンシューマーとブローカーの間でメッセージが行き来します。 アプローチ#4: 失敗したメッセージのDBへの保存を試み、QスケジューラーをX分ごとに実行して、DBからメッセージを取得しました。 これは最適化されていないだけでなく、複数のノードで実行されているDBコンシューマとDBの間の多くのトランザクションチェックが含まれます。 私の環境は、Java、JBoss、ActiveMQ 5.9、MySQL 5.6およびSpring 3.2です。 再試行テンプレート(Springから)やJava 7/8での非同期再試行パターンなど、他のいくつかのアプローチを実行しました この問題についての私の見解は、ほとんどのソリューションは最小の負荷がかかっているときに機能し、停止が長く続くか、メッセージの量が本当に多いときに壊れるように見えるということです。 失敗したメッセージを保存して転送できる場所を探しています。400 TPSシステムの場合、1時間で144万のメッセージが届く可能性があります。 外部システムがダウンしている場合は、これらの144万のメッセージをどのように処理するかによって、メッセージやパフォーマンスを失うことなく、各メッセージが再試行される機会が均等になります。 私が持っている環境の範囲内で解決策を探しています。
8 java 

5
2つのデータベースアーキテクチャ:運用と歴史
私は珍しいデータベース構造について考え、誰かが以前にそれを使用しているのを見たことがあるのではないかと思いました。基本的に2つのデータベースを使用しています。 最初のデータベースは、現在有効なデータのみを保持します 2番目のデータベースは、最初のデータベースで入力、更新、または削除されたすべての履歴を保持します シナリオ 私は、発生するすべてをログに記録する必要があり、データが頻繁に変更されるプロジェクトに取り組んでいます。 例(実際のものではない) サッカーリーグのデータベース設計を行う必要があります。このリーグには選手とチームがあります。プレイヤーはしばしばチームを切り替えます。 最初の要件:データベースは、次の試合をプレイするために必要な情報を保持する必要があります。これは、すべてのプレーヤー、チーム、および各プレーヤーが現在所属しているチームのリストを意味します。 2番目の要件:データベースは、統計の生成に使用する履歴値を保持する必要があります。これは、チームに所属していたすべてのプレーヤーのリスト、またはプレーヤーが参加していたすべてのチームのリストを意味します。 問題 これらの2つの要件は、互いに正反対です。同じデータベースですべてを実行しようとしましたが、意味がありません。最初の要件は「次の試合のプレー」のみを対象とし、2番目の要件は「統計の生成」のみを対象とします。 同じデータベースですべてを行うために、明らかなソフト削除を使用して情報を削除/更新する一種の「挿入のみ」のデータベースを使用しました... 最初は簡単な作業のように見えましたが、プレーヤー、チーム、および各プレーヤーの現在のチームのリストを保持することは、突然、かなり難しくなります。次の一致を再生するために必要なアプリケーションロジックはすでに十分に複雑ですが、データベースは非常に役に立たない設計になり、アプリケーションは次の一致を再生するためにすべてのクエリに「削除済み」チェックを追加する必要があります。 「チームのすべてのプレーヤーが私に来てください」と叫ぶコーチになりたいですか?それから2000人のプレーヤーがあなたのところに来ます。その時点で、おそらく、「このチームで削除されていないすべてのプレイヤーが私のところにやって来ます」と叫ぶでしょう(この愚かなデザインについては誓います)。 私の結論 なぜすべてを同じデータベースに入れる必要があるのか​​不思議に思いました。多くの列(time_created、who_created_it、time_deleted、who_deleted_it)を追加しない限り、ソフト削除はすべてをログに記録するのに不十分なだけでなく、すべてを複雑にします。データベースの設計が複雑になり、アプリケーションの設計も複雑になります。 また、これら2つの要件は、分割できない1つのアプリケーションの一部として受け取りますが、これは2つの完全に異なるアプリケーションであると考え続けています。なぜ一緒にすべてをしようとしているのですか? そのとき、データベースを2つに分割することを考えました。次の試合をプレイするためにのみ使用され、現在有効な情報のみが含まれる運用データベースと、作成、削除、および誰が行ったかについて、これまで存在していたすべての情報を保持する履歴データベース。 目標は、2番目のデータベース(履歴)にできるだけ多くの情報を保持しながら、最初のデータベース(運用)とアプリケーションをできるだけシンプルに保つことです。 ご質問 以前にそのデザインを見たことがありますか?名前はありますか? 私が見逃している明らかな落とし穴はありますか? 編集2015-03-16 現在のアーキテクチャ 基本的に、アーキテクチャ全体を2ステップのプロセスと考えることができます。 ステップ1 : アプリケーションが実行中で、ユーザーがいくつかのアクションを実行しています イベントが発生するたびに、イベントテーブルに自動的に記録されます(監査ソリューション)。 次に、運用データベースの正しい行が更新されます ステップ2 : ジョブがイベントテーブルの最新の挿入を読み取り、この新しいデータを履歴データベースに挿入します。 ユーザーは履歴データベースを照会して、必要な情報を取得します。 イベントテーブルから、いつでも情報を再構築できます。問題は、このイベントテーブルが簡単にクエリできないことです。これは、履歴データベースが機能する場所です。必要なものを正確に取得しやすい方法でデータを提示する。 すべてを同じテーブルに入れるときの追加の問題 各クエリで「削除されている」チェックの複雑さが増すことについては、すでに懸念を表明しています。しかし、別の問題があります:整合性。 外部キーと制約を多用して、データベースのデータがいつでも有効であることを確認しています。 例を見てみましょう: 制約:チームごとにゴールキーパーは1人だけです。 チームごとにゴールキーパーが1人だけかどうかをチェックする一意のインデックスを追加するのは簡単です。しかし、ゴールキーパーを変更するとどうなりますか。以前の1つについての情報を保持する必要がありますが、同じチームに2つのゴールキーパーがいます。1つはアクティブで、もう1つは非アクティブであり、制約と矛盾します。 確かに制約にチェックを追加するのは簡単ですが、管理および検討する必要があるもう1つのことです。

1
本当にサブドメインとは何ですか?
ドメイン駆動設計(DDD)を研究する際に、サブドメインの概念に出くわしましたが、まだ理解していないと思います。これについて私の最初の理解は、サブドメインがアプリケーションのドメインのサブセットであるということでした。言い換えれば、それは問題空間のパーティションです。サブドメインには3つのタイプがあると読みました。 コアサブドメイン サポートするサブドメイン 汎用サブドメイン。 私の理解はこのようなものでした。アプリケーションのドメインを選択しましたが、それは非常に複雑です。次に、それを見て、それをより単純な部分に分割する方法を見つけます。その一部はコアサブドメインであり、一部はサポートするものであり、その他は一般的なものです。 詳細情報を検索したところ、別のことを言っている人が見つかりました。コアサブドメインが1つだけ存在し、いくつかの汎用サブドメインがあり、サポートサブドメインがまったくないことです。 だから私の質問は: 本当にサブドメインとは何ですか?私の最初の理解は正しいものですか、それとも私が読んだ2番目のものですか? このサブドメインの考え方はどのように役立ちますか? サブドメインを識別するための良い基準は何ですか?このアイデアをより有効に活用するためにサブドメインを決定するとき、何を念頭に置く必要がありますか? 編集:もう少し検索すると、次のことがわかりました: eコマースシステムについて考えてみましょう。最初は、それがショッピングコンテキストのアプリケーションであることがわかります。さらに詳しく見ると、在庫、配送、アカウントなど、他のコンテキストもあることがわかります。 これは、私が最初にサブドメインだと思ったものです。ドメイン(ショッピングドメイン)を選択し、それをより単純なサブドメイン(在庫、配送、アカウントなど)に分割します。しかし、問題のテキストでは、彼らはこれらを文脈と呼んでいます。私の以前の理解はサブドメインではなくコンテキストですか? このサイトで、サブドメインと制限付きコンテキストの違いについて1つの質問を見つけました。答えは、サブドメインは問題空間のパーティションであり、コンテキストは解空間のパーティションであると述べています。ただし、ショッピングコンテキストを在庫、配送、アカウントなどに分離することは、概念的な区分ではありません。つまり、解空間ではなく問題空間にありますか?

4
誰が製品バックログにストーリーを追加することを許可されるべきですか?
バックログが混乱するのを防ぐだけでなく、開発者の生産性を維持するためのベストプラクティスは何ですか 製品バックログにストーリーを追加できるのは誰ですか?また、これらのストーリーが特定の要件を満たしていることをどのように確認しますか? たとえば、Feature Xの開発中にいくつかの小さなcssバグを見つけました。開発者として、バグを説明するストーリーをバックログの下部に追加することを許可する必要がありますか?それとも、製品の所有者と話し合う必要がありますか? すべてのアイデア/バグを製品の所有者に渡すことは、ボトルネックの可能性があるようです。

3
ライブラリに慣れるために、ソースコードを読むよりもjavadocを読む方が望ましいですか。
私は大学の研究室のマニュアルで以下に出くわしました: javadocを生成してクラスのインターフェースを調べる必要があるので、提供される操作を確認できます(コードを自由に見てください。ただし、他の誰かのコードを使用する場合は、ここでは、javadocではなくjavadocから作業する必要があります)可能な限りコード)。 なぜそうなのか理解できません。javadocが古くなっている可能性があるか、コードの機能を不適切に説明している可能性があるためです。確かにソースコードを見て、javadocコメントを読むのが最善でしょうか? javadocのみを読むことが最善の方法である理由、またはその理由はありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.