2

私は現在、いくつかの（私の意見では）アーキテクチャ上の問題を抱えたプロジェクトに取り組んでいます。

たとえば、すべてのオブジェクトが静的メソッドを介してアクセスできる共通のフレームワーク Bean から、必要に応じてすべての依存関係が取得されます。これは事実上、Spring Bean を返す Spring の単なるラッパーです。依存性注入はありません。

エンティティには、リレーショナル データを取得するための DAO への参照があります - エンティティ ゲッターに隠されています。

例外には、エラー メッセージを解析および変換するためのサービスへの参照があります。

すべてのサービスまたは DAO は、独自の依存関係と構成要件を持つ一般的な抽象フレームワーク Bean から継承します。それ以外のことをしようとすると、「フレームワークが初期化されていません」というエラーが発生します。また、フレームワークは誰も触れようとしないブラック ボックスであることにも言及する必要があります。

すべてのテストは、中央の共有データベースへの有効なデータベース接続を必要とするため、実質的に統合テストです。

基本的に、すべてがすべてに接続されている依存関係グラフがあります。

そして、テストはありません。

この環境で単体テストをセットアップするのがどれほど難しいか想像してみてください。実際、すべてのテストは、テスト データを挿入し、それ自体をクリーンアップしようとします - いかなる種類のトランザクションも使用しません。

そして、私はここで表面をなぞっているだけです。

言うまでもなく、コードの品質については少し心配です。プロジェクトは (もちろん) 時間とリソースが不足しており、締め切りが近づいています。

では、機能的なソフトウェアに似たものを提供する希望がある場合、リファクタリングが必要であることを理解している言語で経営陣を納得させるにはどうすればよいでしょうか?

4

4 に答える 4

1

私の意見では、最良のアプローチは次のとおりです。

  1. メトリクス: 現在のアーキテクチャの使用によって引き起こされる問題について、考えられるすべてのデータを収集します。情報を分析し、信頼性、効率、セキュリティ、保守性などの関心のあるトピックに分けます。(見てください:ソフトウェアの品質)

  2. 視覚的: 分析された情報を使用して、美しい棒グラフと円グラフを作成します。

  3. 差分: 結果を標準または理想的な指標と比較します。

これで、プロジェクトの視点を経営陣に提示する準備が整いました。

通常、この作業は、プロジェクト マネージャー、チーム マネージャー、またはチーム リーダーの責任です。

幸運を！

于 2013-02-05T19:41:24.617 に答える
0

依存関係が似ているプロジェクトに取り組んでいます。単体テストは理想的ではありません。各テストで非常に多くのクラスをモックしているため、開発環境で完全なアプリケーションを実行するだけの方が優れたソリューションです。

用途によると思います。私のものは、HTTP リクエストを処理するカスタム Web アプリケーションでした。私はそれをオンにし、あらゆる種類のリクエストを送信して、可能なすべてのパスをたどろうとしました。これは単体テストというよりも機能テストに近いものですが、プロセスがはるかに高速であり、ログ ステートメントは特定のクラスまたはメソッドのバグにつながるほど有益であることがわかりました。

私は自分のコードを書き、dev で機能テストを行いました。その後、時間を見つけて、ゆっくりとクラスに単体テストを追加しました。

アプリケーションの将来、新機能、要件、技術などに影響を与える可能性のある予想される変更について、彼らに相談してください。

機能テストが単体テストの代わりになると言っているのではありません。

于 2013-02-05T21:10:23.007 に答える
0

実際、多くの場合、リファクタリングはビジネスにとって良くないかもしれません。メリットはコストよりも小さいからです。他のケースでは、利益が費用よりも大きいかもしれませんが、費用は今支払うには多すぎます。リファクタリングのメリットとコストをビジネスが $$$ に換算できる単位で見積もるようにしてください。つまり、開発者、テスター、サポート チームの工数、システムが利用できない時間などで、リファクタリングを行う価値があるかどうかをビジネスに判断させます。 、 か否か。そのような決定は、ビジネスが開発者よりも強いところです。

于 2013-02-05T18:42:45.857 に答える