タグ付けされた質問 「legacy」

レガシー言語、コード、またはアプリケーションに関する質問。

1
ユニットテストジェネレーターは、レガシーコードの操作に役立ちましたか?
テストカバレッジが非常に低い小さな(生成されたものを含めて〜70kLOC)C#(.NET 4.0、一部のSilverlight)コードベースを探しています。コード自体は、ユーザー受け入れテストに合格したという点で機能しますが、脆弱で、一部の領域では十分に分解されていません。通常の容疑者(NMock、NUnit、Silverlightビット用のStatLight)を使用して、レガシーコードの周りに強力な単体テストカバレッジを追加したいと思います。 私の通常のアプローチは、コードの状態に満足するまで、プロジェクト、ユニットテスト、リファクタリングを開始することです。私はこれを何度も行ったことがありますが、うまくいきました。 ただし、今回は、テストジェネレーター(特にPex)を使用してテストフレームワークを作成し、手動で具体化することを考えています。 私の質問は、レガシーコードベースでの作業を開始するときに過去にユニットテストジェネレーターを使用したことがありますか? 私の恐れは、生成されたテストがコードベースの意味のニュアンスを見逃し、コードで意図された動作を明確に表現するテストではなく、カバレッジメトリックのためにテストを行うという恐ろしい状況につながることです。

5
レガシープロジェクトで警告に対処する方法
膨大な数の警告を生成するC ++プロジェクトに取り組んでいます。ほとんどの警告は、コードの作成後に表示されました。 当初、プロジェクトはVisual C ++ 8を使用し、間もなく9に切り替えましたが、生成された警告にほとんど違いがありません。警告は修正されるか沈黙されたので、そのとき警告はありませんでした。 次に、64ビットターゲットが追加されました。これは、主に型の不適切な使用(unsignedvsなどsize_t)のために、大量の警告を生成しました。コードが目的に沿って機能した後は、誰もそれらを修正するために悩んだり時間をかけたりすることはありませんでした。 次に、GCCを使用する他のプラットフォームのサポート(4.5および4.6、最初は4.4)が追加されました。GCCはよりうるさいので、より多くの警告を生成しました。再び、誰もそれらを修正するために悩んだり、時間をかけたりしませんでした。これは、GCCが4.5まで特定のコードの警告を沈黙させるプラグマを持っていなかったという事実によってさらに複雑になり、ドキュメントによると、それはまだ必要なものではありません。 その間、いくつかの非推奨の警告がポップアップしました。 これで、何千もの警告を生成するプロジェクトができました。また.cpp、さまざまなコンパイラーによってファイルが数回コンパイルされ、ヘッダーの警告が何度も出力されるため、どのくらいの数の場所であるかさえわかりません。 そのようなものをクリーンアップするためのベストプラクティスはありますか?それともそれを扱った少なくともいくつかの肯定的な経験ですか?

3
レガシーコード(わかりません)の単体テストを作成するにはどうすればよいですか?
進む この質問をする前に、SEに関する多くの関連する質問を含め、多くのことを読みました。 (ソフトウェアエンジニアリングSE)目的がわからないコードのテストを書く (ソフトウェアエンジニアリングSE)ユニットテスト初心者チームはユニットテストが必要 (ソフトウェアエンジニアリングSE)レガシーコードを自動テストで改造するためのベストプラクティス (ソフトウェアエンジニアリングSE)大規模なレガシーシステムを単体テストする方法 (ブログ投稿)単体テスト環境をモックアップする方法 しかし、助けを求めて読んだ後、かゆみはまだ引っかかれていないと感じざるを得ません。 TL; DR 実行、シミュレーション、読み取り、または簡単に理解できないレガシーコードの単体テストを作成するにはどうすればよいですか?おそらく意図したとおりに機能するコンポーネントに役立つ回帰テストは何ですか? 全体像 私は大学院に移行しているので、再び夏の帰国研修生です。私の仕事には次の要件が含まれます。 特定の製品について、ソフトウェアチームが既存のプロジェクトとの互換性を失うことなくIDEおよびJUnitバージョンをアップグレードできるかどうかを評価します。 既存のJavaコード(主にJavaではない)の一部のコンポーネントの単体テストを開発します。ユニットテストとTDDは、使用する必要がある非常に貴重なツールであることをソフトウェアチームに納得させたいと思います。(現在、0%のコードカバレッジがあります。) どういうわけか、重要なシステムのカウボーイコーディングの時代を終わらせてください。 ソースコードのコピーを入手した後、この製品の機能と動作を理解できるように、ビルドして実行しようとしました。できませんでした。私は上司に自分のやり方を尋ね、実際に機能するビルドスクリプトを含む、それをビルドできる新しいスタンドアロンマシンを発行されました。彼らの予想通り、製品コードは設計された組み込みシステムでのみ実行されるため、それも機能しませんでした。しかし、彼らはこの目的のためにシミュレーターを持っているので、彼らはシミュレーターを手に入れ、このマシンにそれを置いてくれました。シミュレータも機能しませんでした。代わりに、私は最終的に特定の画面のGUIのプリントアウトを受け取りました。また、700,000以上のJava LOC内のどこにもコードコメントがないため、把握がさらに困難になります。さらに、彼らのプロジェクトが新しいIDEと互換性があるかどうかを評価する問題がありました。特に、彼らのコードは、彼らが使用しているまさにそのIDEバージョンに適切にロードされませんでした。 私の在庫は次のようになっています: NetBeans 8、9、10、11 JUnit 4、5 特定の製品のソースコード(700,000以上のJava LOCを含む) 実質的にコードコメントはありません(場合によっては署名) 既存のテストはありません GUIウィンドウの物理的な写真 画像内のコンポーネントについて説明していないソフトウェア設計ドキュメント(109ページ) 少なくとも理論的には実行可能なテストを書くのに十分です。そこで、このコンポーネントについて基本的な単体テストを試しました。しかし、モデル、マネージャー、DB接続など、依存関係として持つオブジェクトを初期化できませんでした。基本的な単体テスト以外にJUnitの経験はあまりないので、次のセクションに進んでください。 私の読書から学んだこと モッキング:単体テストを作成する場合、本番環境での依存関係のために、モック変数を用意する必要がありますsetUp。 ここの誰もがマイケルフェザーズの著書「レガシーコードを効果的に使用する」を寛大に提案しています。 回帰テストは、おそらく開始するのに適しています。統合テストを試すのに十分な兵器がないと思います。回帰テストは、ソフトウェアチームにすぐに満足感を与えるでしょう。ただし、私は彼らの既知のバグにアクセスできません。しかし、私はたぶん尋ねることができました。 そして今、私がまだ疑問として持っている不確実性を明確にする試み。基本的に、私はこれらのテストを作成する方法の一部を理解していません。(おそらく)上司からこれ以上のガイダンスを受け取らないと想定すると、このコンポーネントの機能を理解するだけでなく、どのテストが回帰テストとして実際に役立つかを判断するのは私の球場です。 このようなプロジェクトに携わってきた専門家として、このような状況で単体テストを作成する方法について何かアドバイスはありますか?

3
社内スクリプト言語を廃止するための移行戦略
社内で多くのことに使用するスクリプト言語があります。これは、動的ラベルがシステム全体に普及しているチューリング完全言語になるための単純な評価ステートメントとして始まりました。 問題は、このために設計されたことはなく、それが表示されることです。開発環境は貧弱であり、作成されたスクリプトはテスト可能ではなく、現在でも言語の正式な定義はありません。 言語のユーザーの間で高まる感情は、それが仕事を終え、手放す時が来たと感じていますが、既存のコードベースを新しいソリューションに考案することに移行するという困難な課題に直面しています。この議論は、移行の考えに反して使用されます。 同様の状況に直面したことがありますか?もしそうなら、古いものの使用を止めて新しいものを宣伝するためにどのような戦略を使いましたか? 最後に1つ(Moronsに感謝)、これらのスクリプトの多くは文書化されておらず、まだアクティブに使用されていますが、元の目的は失われています。スクリプトは顧客サイトでもシステムをカスタマイズするために使用されるため、文字通り数千のこれらのスクリプトがあり、その大部分はソース管理またはバージョン管理メカニズムの対象ではありません。 受け入れられた答え。 これは難しい選択です。モロンとオリバーのハイブリッドのいくらかが最良であると私は思うが、すべての答えは良いと健全なアドバイスでした。 私は結局オリバーズを受け入れることになりました。なぜなら、それがより高く受け入れられる最も良いチャンスである(ha!政治!)古いスクリプト環境を、新しい環境に統合できる呼び出し可能なステートメントにパッケージ化すると、迅速で簡単なアップグレードパスが得られます。 完了したら、警告を表示したり、古いスクリプトの編集や作成を禁止したりして、新しいスクリプトの作成を制御し、新しい言語に強制的に移行させることができます。 入力ありがとうございます!
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.