java - 本番前に削除する必要があるコードをマークするにはどうすればよいですか?

Question

テスト/開発の目的で、製品ビルドで削除する必要があるコードに変更を加えることがあります。そのようなブロックをマークして、それらが存在する限り製品ビルドが失敗するか、少なくともビルド中に何らかの形で警告する簡単な方法があるのではないかと思います。

シンプル"//TODO:"は、しばしば忘れられたり、他のたくさんの仕事と混ざり合ったりするため、実際には機能しません。もっと強いものはありますか？

または、外部のtxtファイルを作成して、本番前に何をすべきかについての指示をそこに置くことができたとしても、そのアリはそのファイルが存在するかどうかを確認してからビルドをキャンセルします。

Eclipse/Ant (および Java + Spring) を使用しています。

更新:ローカルと実稼働で異なるコードの大きな塊があるという意味ではありません。実際、すべてのコードは同じであり、同じである必要があります。開発中に多くの時間を節約するためにコードの一部の行をコメントアウトし、その行に沿ってコメントを外すのを忘れるとしましょう。何か注意が必要で、製品ビルドが失敗するか、警告が表示されることをプロジェクトに何らかの形でフラグ付けできるようにしたいだけです。

score 13 · Accepted Answer

必要性を避けてください。本番環境に存在してはならないクラスにコードを配置する場合は、別の方法でコードを配置する方法を考えてください。たとえば、フックを提供して、テストコードが必要なことを実行できるようにしますが、テストコードはクラスの外に残します。または、テスト用のサブクラスを使用するか、依存性注入、またはテスト可能でありながらコードを本番環境で有効かつ安全に保つその他の手法を使用します。そのようなテクニックの多くは、MichaelFeathersの素晴らしい本「WorkingEffectivelywithLegacyCode」に詳しく記載されています。

score 12 · Accepted Answer

より強力なタスクコメントマーカーを定義することもできます。Eclipse では FIXME (高優先度) と XXX (通常優先度) が標準であり、さらに多くのタスクタグを定義できます (Eclipse プロパティ -> Java -> コンパイラ -> タスクタグ)。

ビルドを失敗させたい場合は、Ant (1.7) のcontainsファイルセレクターを使用して、指定したテキストを含むファイルを探すことができます。

<target name="fixmeCheck">
  <fail message="Fixmes found">
    <condition>
      <not>
        <resourcecount count="0">
          <fileset dir="${pom.build.sourceDirectory}"
                   includes="**/*.java">
             <contains text="FIXME" casesensitive="yes"/>
          </fileset>
        </resourcecount>
      </not>
    </condition>
  </fail>
</target>

<target name="compile" depends="fixmeCheck">

明らかに、${pom.build.sourceDirectory}ソースディレクトリにFIXME移動し、検索したいコメントに移動します。

このファイルセットで見つかったファイルをビルドファイルに出力する良い方法を知っている人はいますか (Eclipse をもう一度見るだけではありません)。

score 7 · Accepted Answer

ブロックが存在する場合に失敗する単体テストを追加します。おそらく、ブロックはCODE_BLOCK_IS_NOT_DELETED = true;単体テストがチェックするグローバル変数を設定します。

ただし、より大きな問題は、本番環境で必要または使用しないコードでテスト/開発することです。それは正しく聞こえません。

score 3 · Accepted Answer

どういうわけか汚い提案の1つは、静的メソッドでクラスを作成することです

class Prod {
   public static void uction(){
   }
}

次に、必要な場所に印を付けます

Prod.uction();

次に、本番前にクラスを削除するだけで、必要に応じてコンパイラエラーが発生します:D

score 2 · Accepted Answer

ただし、技術的にこれを解決する場合は、逆の方法で行うことをお勧めします。本番ビルドに特別なことをするのではなく、開発ビルド中に魔法が発生するようにコードとビルド環境を構造化します。本番ビルドは、可能な限り絶対確実（またはマーフィープルーフ）にする必要があります。

開発ビルドで問題が発生した場合：だから何。

本番ビルドで問題が発生すると、さらに問題が発生します。

score 2 · Accepted Answer

[編集：]C++で動作します...:-)

これらのプリプロセッサ定義を使用すると、すべての問題が解決されます。

#ifdef _DEBUG
#define COMMENT (code)  /* code */
#else
#define COMMENT (code) #error "Commented out code in release!"
#endif

構文が完全に正しいかどうかはわかりませんが、理解できます。

score 2 · Accepted Answer

ブロックするsubversionにトリガーを追加しました。ビルドを許可する前に、ビルドスクリプトが検索するタグを設定\\NOCOMMIT: できます。\\NODEPLOY:

score 1 · Accepted Answer

TDDと依存性逆転の概念がここで役立つかもしれません。さまざまなコードをインターフェイスを実装するクラスに配置することで、そのコードのTestバージョンが実行されるタイミングとprodバージョンが実行されるタイミングを制御できます。

次に、テスト用として明確に名前が付けられたファイルがあり、ビルドから除外できます。

score 1 · Accepted Answer

上記のすべての提案 (すべての手動のがらくたとコードへの粗雑な追加とは何ですか? 自動化の人々...) に加えて、Eclipse、Spring、および ANT を使用していることに気付きました。Eclipse は複数のソースフォルダーをサポートしています。コードを「ソース」フォルダーと「テスト」フォルダーに分け、本番用のものはすべてソースフォルダーに置き、「本番以外」のものはすべてテストフォルダーに置きます。Spring では、異なる実装を参照する複数の構成を使用できます。したがって、本番環境でのみクラスを参照する本番構成と、テストコードで実行するテスト構成を使用できます。ANT スクリプトで、アプリの製品版とテスト版をビルドします。テストの場合は「testing」フォルダーをコンパイルパスに追加し、製品版の場合はそのままにしておきます。

score 1 · Accepted Answer

私が取り組んできたプロジェクトでは、開発中に簡単にテストできるように、さまざまなコードが用意されています。これらを、最終的なブール値をチェックする if ブロックでラップします。ブール値が true の場合、コードにアクセスできます。ブール値が false の場合、最適化として結果の .class ファイルからコードを削除するコンパイラに依存します。例えば：

public class Test {
    public static void main(String[] args) {
        final boolean TESTABLE = true;

        if (TESTABLE) {
            // do something
        }
    }
}

通常、これらの変数は自分で管理し、開発中に使用し、完了したら TESTABLE を false に設定します。開発チームは、TESTABLE などの変数名の規則に簡単に同意することができ、ビルドファイルの運用ターゲットは、ソースファイルに TESTABLE variable = true が含まれているかどうかをチェックして失敗する可能性があります。

score 0 · Accepted Answer

私はこれをできるだけ避けようとします。-別のアプローチは、依存性注入を使用して、テスト用にさまざまな実装を注入することです。

または...

inTestブールフィールドをオブジェクトに追加し、オプションのコードをifステートメントでラップします。

if(inTest) {
testMethod();
}

このvbooleanを依存性注入で設定するか、渡されたシステムプロパティから読み取ることができます（-DinTest = true）

お役に立てれば。

score 0 · Accepted Answer

Javaプリプロセッサを使用できます。j2meアプリケーションの場合、アンテナプリプロセッサを使用します。コードは次のようになります

public void someMethod() {
    //#ifdef DEBUG
    doDebugStuff();
    //#endif     
}

score 0 · Accepted Answer

それらのクラス/メソッドを非推奨としてマークすると、コンパイル時にフラグが立てられるでしょうか?

score 0 · Accepted Answer

Eclipse が表示する //FIXME キーワードを //TODO と共にタスクビューに使用します (表示内容をフィルターできます)。//FIXME が周りにある場合は、本番環境に出るべきではありません :)

score 0 · Accepted Answer

私の解決策は、コードの 2 つの別々のブランチで作業することです。デバッグコードなしでクリーンコードのみを取得する1つの本番ブランチと、テスト、デバッグ、新しいストローの試行などのための別のブランチ(これらのいくつかを持っていることもあります)。

Eclipse では、これらは個別のプロジェクト (またはプロジェクトのグループ) です。

Mercurial はこの種の作業に適した VCS ですが、CVS と subversion も優れています。

score 0 · Accepted Answer

私たちの実稼働環境では、非常に特別なコメントを使用してセクションを削除するための単純な C ツールがいくつかあります。/*#BEGIN_SKIP*/と/*#END_SKIP*/。標準の C ランタイムに固執すれば、どの環境でもコンパイルできます。

ビルドサイクル全体を変更して、ソースコードを複製し、変換し、コンパイルすることができます。

score 0 · Accepted Answer

Eclipse では、//TODO 以外のマーカーを使用できます。たとえば、//TOBEREMOVED を追加して優先度を高くすると、他のすべての TODO マーカーよりも前に表示されます。

score 0 · Accepted Answer

これを解決する明白な方法は、実稼働用のファイルをビルドすることを目的としたビルドでのみ実行される単体テストを用意し (または、現在のビルドが実稼働の対象になっているかどうかを確認し、そうであればテストを実行します)、ビルドに失敗することです。テストが失敗した場合。

あなたは決して忘れません。どのようなテストかというと、コードが何をするかを実際にチェックするのが理想的です。これが不可能な場合は、Terry Lorber が提案したグローバルスタティックの方が、現在のものよりもはるかに優れています。

score 0 · Accepted Answer

//TODO: をいくつか追加するだけです。 -- 次に、コード内で //TODO を検索して表示する ac# スクリプト (cs-script.net) を作成します。その後、このスクリプトを自動ビルドに追加できます (そうしている場合)。これにより、ビルドを実行するたびに、何をすべきかを確認できます。デプロイする前に、コードの todo リストを確認してください。

独自のスクリプトを作成する代わりに、 vstudioをいくつかのツールと統合して、todo ラインも指摘する方法についての説明があります。-studion-2005-c.html

ただし、正規表現を使用して単純な C# スクリプトを作成するよりも、そのツールをセットアップする方が面倒だと私には思えます。

java - 本番前に削除する必要があるコードをマークするにはどうすればよいですか?

19 に答える 19

Related

Reference