4

私のチームの継続的なこだわりは、私たちの「共通」ライブラリです。（ここで関連する質問を見ると、「フレームワーク」と言った方が正しいかもしれません）。

これは現在、v1、v2、およびv3で構成されています。v3はすべての新しいアプリに使用されます。これには、複数のWCFサービス、ビジネスオブジェクトを含むクラスライブラリ、およびjs / css/images用の共通のWebディレクトリが含まれています。

特に私たち全員が共通の図書館に積極的に貢献し始めているので、私たちは前進するときに正しいことをしたいと思っています。それは大きな泥だんごに変わり、それを展開することは誰にとっても恐ろしいことです。

私たちの最初の考えは、すべてのコードで単体テストを実行するテストサーバーをセットアップして、何も壊れていないことを確認することです。問題は、すべてのテストを書くのは非常に面倒であり、率直に言って、そのような時間は誰にもありません。また、適切な単体テストを作成することに不慣れです。そうは言っても、それが最善の道であるなら、私たちはそれを成し遂げるでしょう。

その後、私たちはあまりよくわかりません。共通コードは、それを利用して作成するさまざまなアプリケーションが多数あるため、継続的インテグレーション手法を適用する場所と見なしています。

これにより、DLLをローカルにコピーしたり、すべてを1つのサーバーのどこかに置いたりするなどの質問も発生します。私たちはすでにDLL地獄にいるような気がして、出て行きたいと思っています。

このような状況を管理するために（優れた）ソフトウェアショップが使用する戦略は何ですか？

ありとあらゆるアドバイスをいただければ幸いです。さらに情報が必要な場合は、質問してください。喜んで提供させていただきます。

ありがとう！

4

3 に答える 3

8

問題は、すべてのテストを書くのは非常に面倒であり、率直に言って、そのような時間は誰にもありません。

本当の問題は、TDDアプローチなしでコードを記述したことです（テストを最初に記述する必要があります）。現在、テストが焦点となっているプロジェクト（すべてのプロジェクトで行われる必要があります）では、通常、テストの記述に時間がかかるか、同じ時間がかかります。実際のコードを書くこと。なんで？テストを書いているときにTDDをフォローするときは、実際にコードを設計していて、このパターンに従って赤-緑-リファクタリングを行うためです。

あなたは間違いなくあなたのコードのテストを書き始めるべきです、今の問題（そして私はこの仮定を大胆に取っています）はあなたとあなたのチームがテスト可能なコードを書かなかったことです。

このスレッドを確認してくださいhttps://stackoverflow.com/a/10365073/1268570

すべてのコードがテスト可能であるとは限らないと仮定すると、単体テストを作成するのは非常に面倒ですが、何らかの統合テストを作成することはできます。

CIサーバーについては、それを実装する必要があります。実際、CIはすべての深刻なプロジェクトでオプションではありません。

私は実際にCIサーバーとの統合を簡素化するツールを作成しています。これは、すべてのプロジェクトが従う必要のある一般的なタスクを実行するためのサードパーティツールをラップするMSBuildスクリプトのセットで構成されています。まだリリースしていませんが、ドキュメントの作成は完了していません。機能しているので、次を確認できます。

https://github.com/jupaol/NCastor/tree/develop

新しいバージョンをリリースするまでマスターにマージされないので、開発ブランチを確認してください

バージョン管理について、あなたが言うように「dll hell」を残すために、あなたはバージョン管理標準を持っていないと私に思わせます、私はあなたにセマンティックバージョニングモデルをチェックすることをお勧めします：

http://semver.org/

ところで、組織内で新しいコンポーネントバージョンを配布するための良い戦略は、プライベートNugetサーバーをセットアップし、そのサーバーにコンポーネントのNugetパッケージを公開することです。もちろん、これを実現するには、コンポーネントをNugetsとしてパッケージ化する必要がありますが、これは非常に簡単です。

この記事を参考にして、次のことに全力を注いでください。

  • ユニットテストを書くTDDアプローチを使用する

  • クリーンなテスト可能なコードを書く

  • CIサーバーを実装する

http://misko.hevery.com/2008/07/16/top-10-things-i-do-on-every-project/

テストを書くときに使用することをお勧めするツール：

于 2012-05-01T20:50:29.977 に答える
4

自分で2冊の本を手に入れて、必読にします。

  1. MichaelFeathersによる「レガシーコードを効果的に使用する」
  2. ロイ・オシェロフによる「ArtofUnitTesting」

最初の本では、レガシーコードを操作してパターンにリファクタリングするためのベストプラクティスと、コードの周りで意味のある単体テストを取得する方法について説明します。

2冊目の本は、経験豊富なユニットテスターと初心者のユニットテスターの両方にとって優れたリソースです。

最後に、「すべてが非常に退屈で、率直に言って、誰もそのような時間はない」という言い訳/理由を決して許さないでください。良い習慣にたどり着くのを止めてください。意味のある単体テストの1つは、何もないよりはましです。

それをサポートするための単体テストなしで「新しい」コードが書かれないことを標準にします。そして、あなたのルーチンの一部であるコードレビューを入手してください。

頑張って楽しんでね。

于 2012-05-01T20:39:01.197 に答える
4

率直に言って、そのような時間は誰にもありません。

...しかし、事後に「それ」が引き起こす問題を修正する十分な時間がありますか？

どちらかといえば、コア機能を実行する「共通」を消費するアプリのスモークテストを作成して、新しい共通リリース後も機能することを確認します。

その後、いくつかのコードカバレッジツールを調べて、テストしていないものを確認します。次に、チームとして、カバレッジを徐々に構築するプロジェクトを追加できます。

<soapbox>ユニットテストは、特に「一般的な」コードに対して作成
する必要があります。そのコードは、わずかに異なる方法で使用する開発者の気まぐれで変更される可能性があるためです。
</ soapbox>

于 2012-05-01T20:42:24.140 に答える