7

私たちは4人の開発者がいて、少し自由な時間があります（約3〜4週間話します）。

コードベース全体で、さまざまなプロジェクトに対して、開始する新しいプロジェクトごとに書き直されるフレームワークyタイプのコードがいくつかあります。手元に空きがあるので、次のようなすべてのプロジェクトで再利用できる「標準」のライブラリセットを作成中です。

  1. キャッシング
  2. ロギング

上記の2つは、Enterprise Libraryなどのライブラリに依存しますが、新しいプロジェクトごとに独自のラッパーなどを作成するため、これらすべてのコードを統合しています。

多くのプロジェクトで共有されている、社内で構築した標準ライブラリに関する提案を探しています。

コンテキストを提供するために、LOB内部アプリと公開Webサイトを構築します。つまり、シュリンクラップを販売するソフトウェアハウスではないため、ライセンスモジュールのようなものは必要ありません。

どんな考えでも大歓迎です-私たちの開発者はいくつかのコードを書くことを切望しています、そして私は彼らに長期的に組織に利益をもたらす何かを与えることをとても望んでいます。

乾杯

4

6 に答える 6

6
  • ユニットテストインフラストラクチャ-すべてのユニットテストを簡単に実行できますか？ユニットテストはありますか？
  • ビルドプロセス-1つまたは2つのコマンドだけで、アプリを最初からビルド/デプロイできますか？
于 2010-07-05T23:35:59.430 に答える
3

わかりました、最も重要なのは、車輪の再発明をしないでください！

簡単に活用できるライブラリの調査に時間を費やしてください。

  • ロギングには、Log4Netを強くお勧めします。
  • nUnitのテスト用
  • 嘲笑するために、Rhino。

また、制御の反転を見てください。CastleWindsorをお勧めします。

  • インデックス作成には、（Luceneの上に）Solrをお勧めします。

次に、いくつかのラッパーを記述します。

これらは、APIのエントリポイントである必要があります（共通ライブラリですが、APIと考えてください）。

APIの内部で使用するすべてのライブラリの抽象化に重点を置くため、Log4NetやCastle Windsorを使用したくない場合は、適切に構造化された抽象化を記述し、緩く結合されたデザインパターンに集中することができます。

ドメイン駆動開発を採用する：

APIは、一般的なデータアクセスライブラリのような他の一般的なAPIを内部的に使用するドメインおよびモジュラー抽象化と考えてください。

提案：

まず、非常に柔軟な一般的なDALライブラリから始めます。これにより、あらゆるタイプのデータや複数のストレージメディアに非常に簡単にアクセスできます。

リレーショナルDBにはFluentnHibernateを使用します。また、ac＃言語機能であるため、データアクセスへのすべてのメソッド呼び出しでLINQを実装します。

LINQを使用してDB、インデックス、ファイル、xmlなどをクエリします。

于 2010-07-06T01:03:16.027 に答える
3

私たちが行う主なことのいくつか：

  • ロギング（TraceSourceの周りにいくつかのラッパーを使用）
  • シリアル化ラッパー（1行のコードでシリアル化/逆シリアル化できるようにするため）
  • 圧縮（.NET機能のラッパー。1行のコードでこれを実行できるようにします）
  • 暗号化（同じことですが、.NET Framework機能のラッパーなので、開発者は常にbyte []で作業する必要はありません）
  • コンテキスト-スタックトレースをウォークして、現在の呼び出しに関するすべての情報（アセンブリ、クラス、メンバー、メンバータイプ、ファイル名、行番号など）を含むデータ構造を返すクラス。
  • などなど...

お役に立てば幸い

于 2010-07-06T00:40:19.913 に答える
1

これが、すべての開発者を1か月間忙しくさせることができる1つのことです。

  1. コードカバレッジ（nUnitまたはVSコードカバレッジ）を備えたプロファイラーでアプリの単体テストを実行します。
  2. さらにテストが必要な領域を特定します。
  3. それらのサブシステムの単体テストを作成します。

現在、システムがTDDを使用して作成されていない場合、システムは非常にモノリシックであり、テストサーフェスを導入するために大幅なリファクタリングが必要になる可能性があります。うまくいけば、それの終わりにあなたはよりモジュール化された、より緊密に結合されていないことになります。よりテスト可能なシステム。

于 2010-07-06T00:47:30.613 に答える
0

ビジネスが次のバージョンを整理しているときに、前のジョブで少しダウンタイムが発生しました。私たちが助けたことがいくつかありました

  • .netreotingからWCFに移行しました
  • すべての開発者が作業してリファクタリングするのが嫌いなコード内の問題点を検索しました
  • 単体テストを実行し、失敗したビルドの電子メールを送信する、優れた自動ビルドシステムを導入します。また、QAが取得できるように、そのバージョンをパッケージ化して共有ディレクトリに配置します。
  • DBのスクリプトを作成して、他の開発者が遊んでいる無関係なデータで汚染された古いコピーを強制的に取得するのではなく、データベースを簡単にアップグレードできるようにしました。
  • 適切なバグ追跡とトリアージプロセスを導入
  • winformsからwpfに移行する方法を調査しました
  • CAB（複合アプリケーション）またはプラグインフレームワークを調べたので、構成が簡単になります。（当時、セットアップと構成は非常に長い時間でした）

私が今する他のことは

  • Postsharpを見て、ロギング、例外処理、またはコードが何度も繰り返される場所を簡素化する横断的関心事を織り込みます
  • Automapperを見て、あるタイプから別のタイプへの変換が、多くの場所でコードを変更するのではなく、構成によって駆動されるようにします。
  • TDD（実行しない場合）またはBDDスタイルの単体テストに関する教育を見てください。
  • 自動統合テストの合理化に時間を費やします。（これは手動でセットアップおよび構成するのが難しいため、SDLC内にドロップされる傾向があります）
  • Resharperなどの開発ツールの実行可能性を見てください

HTH

于 2010-07-06T00:33:54.693 に答える
0

私の態度は、標準ライブラリを書くことはほとんどないということです。代わりに、既存の機能するコードをリファクタリングして、重複を取り除き、使いやすさとテストのしやすさを向上させる必要があります。

結果は「標準ライブラリ」と非常によく似ていますが、動作することがわかり（変更のたびに単体テストを再実行しますか？）、すでに使用されているため、使用されることがわかります。使用されています。そうしないと、使用されておらず、使用されても機能しないすばらしい標準ライブラリを作成するリスクがあります。

于 2010-07-06T00:38:14.567 に答える