タグ付けされた質問 「patterns-and-practices」

ソフトウェアエンジニアリングの設計パターン(よく発生する問題の再現可能なソリューション)とベストプラクティス

4
古いコミットで検出された脆弱性を修正する必要がありますか?
GitHub上の私のプロジェクトの1つが、この場合は中程度の重大度の脆弱性アラートを受け取りました。 この脆弱性は、古いバージョンのコードの依存関係で検出されました。現在のバージョンでは、この依存関係は使用されなくなりました。それでもなお、古いコミットがチェックアウトされて実行される可能性があり、アプリケーションを開いて脆弱性を悪用する可能性があります。 ソフトウェアエンジニアリングの観点から、以前のコミットに戻って変更することをお勧めします。つまり、現在使用されていない依存関係を脆弱性の修正を含む新しいバージョンに更新しますか?または、コミット履歴をそのままにしておく方が良いですか?

3
設計:データベースの変更が原因で下位互換性が失われないようにする方法
これは私のシナリオです、私はこのインターフェースを持っています: public interface hitTheDataBase { public void insertMe(String [] values); public void modifyMe(String [] values); public DataTable selectMe(); } そして、私はインターフェースを実装するこれらの2つのクラスを持っています: public Class hitSqlServer implements hitTheDatabase { public void insertMe(String [] values) { executes insert into table_in_sqlServerBD (col1, col2) values(values[0], values[1]) } public void modifyMe(String [] values) { executes update table_in_sqlServerBD …

7
クラスがロジックのない情報のコレクションのみであることが適切ですか?
私はクラス持っていると言うPersonのインスタンス変数を持っているage、weightとheight、と別のクラスFruitのインスタンス変数を持っているsugarContentとしますtexture。Person一方、クラスは、セッターとゲッター保存メソッドを持たないFruitクラスは、セッターとゲッターの両方があるとのようなロジック・メソッドをcalculateSweetness。Fruitクラスは、クラスよりも実践的なクラスのタイプですPerson。つまり、Personクラスはあまり目的を持っていないようです。Fruitクラスはデータを整理し、実際にはロジックのメソッドを含みますが、データを整理するためだけに存在します。

2
IRepositoryからIQueryableを返す
リポジトリパターンを使用して、一般的な使用のために、データセット(テーブル)のIQueryableを返すことは適切ですか? これは多くの場合に非常に便利です。特に、そのインターフェイスを利用する外部ライブラリ、たとえば、UI要素をソート/フィルタリングしてバインドするプラグインを使用する場合に便利です。 ただし、IQueryableを公開すると、デザインにエラーが発生しやすくなる場合があります。これと遅延読み込みの誤った使用を組み合わせると、パフォーマンスが大幅に低下する可能性があります。 一方、使用方法ごとにアクセスメソッドを用意することは冗長であり、多くの作業(ユニットテストなど)も必要です。

2
C#でのシリアル化されたオブジェクトの保存と保守
C#でシリアル化されたオブジェクトを格納および維持するためのベストプラクティスは何ですか?適用できる戦略やパターンはありますか? 私がこれまで信じてきたのはこれです: スペースと速度の両方の点でXMLよりもJsonを優先しますが、大きなデータセットの場合、XMLはLINQ to XMLを介してデータをクエリ/マイニングする方が簡単です。 すべてのプロパティについて、シリアル化された名前に明示的にマップします。将来、プロパティの名前を変更する必要がある場合、シリアル化されたデータは壊れません。属性はこれに役立ちます。 将来データを大量に移行する必要がある場合に備えて、シリアル化されたオブジェクトにある種のバージョン情報を保存します 更新:(難しい方法を見つけた) アプリケーション全体およびすべてのバージョンで、すべての日時を統一された方法で保存します。フォーマットとタイムゾーンの両方について。

6
プロジェクトを切り替える/プロジェクトに頻繁に戻る場合のベストプラクティスは何ですか?
私の仕事の本質は、数週間ごとにプロジェクトを切り替えなければならないことです。私の生産性に対する最大の障害の1つは、関連するすべてのコードを一定期間表示しなかった後、再び「頭の中で」元に戻すための立ち上げ時間であることがわかりました。これは、より短い休憩/より長い休憩では、より小さな範囲で発生します。 明らかに、優れた設計、ドキュメント、コメント、および物理構造がすべてこれに役立ちます(プロジェクトの切り替えをできるだけ頻繁に行うことは言うまでもありません)。しかし、私が見逃している可能性のあるプラクティス/ツールがあるかどうか疑問に思っています。これを改善するための具体的な方法は何ですか?

2
大量のデータを処理する低カップリング
通常、それらの間でリスト、セット、およびマップを交換するクラスを作成することにより、低結合を実現します。現在、Javaバッチアプリケーションを開発していますが、十分なメモリがないため、すべてのデータをデータ構造内に配置できません。データの1つのチャンクを読み取って処理し、次のチャンクに進む必要があります。したがって、読み取るデータがまだあるかどうかなどをどこかで確認する必要があるため、カップリングを低くすることははるかに困難です。 私が今使っているのは: ソース->プロセス->持続 処理するクラスは、読み込む行がまだあるかどうかをソースクラスに問い合わせる必要があります。 そのような状況でのベストプラクティスや有用なパターンは何ですか? 私に言わなければ、自分自身を説明しているといいのですが。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.