Wie einige Codes zu markieren, die vor der Produktion entfernt werden müssen?

Question

Manchmal für die Prüfung / Entwicklung Zwecke stellen wir einige Änderungen in dem Code, der in einer Produktions Build entfernt werden muß. Ich frage mich, ob es eine einfache Möglichkeit ist eine solche Blöcke der Markierung, so dass die Produktion bauen würde so lange nicht, wie sie vorhanden sind, oder zumindest wird es Ihnen während des Build warnen irgendwie.

Einfacher "//TODO:" funktioniert nicht wirklich, weil es ofter vergessen und mit Tonnen von anderen todos gemischt. Gibt es etwas stärker?

Oder vielleicht auch wenn ich einige externe txt-Datei erstellen und Anweisungen setzen auf das, was vor der Produktion zu tun, und dass Ameise würde überprüfen, ob die Datei Build dann abbrechen vorhanden ist.

Wir sind mit Eclipse / Ant (und Java + Frühling).

Update: Ich will damit nicht sagen, dass es große Teile des Codes, die in der lokalen und Produktion unterschiedlich sind. In der Tat ist der gesamte Code gleich und sollten gleich sein. Nur können sagen, dass ich einige Code-Zeile kommentieren Sie viel Zeit während der Entwicklung zu sparen und vergessen oder etwas in diese Richtung Kommentar-. Ich möchte nur irgendwie das Projekt Flagge der Lage sein, dass eine Aufmerksamkeit etwas braucht und dass die Produktion bauen würde fehlschlagen oder eine Warnung.

Answer 1

Sie können auch definieren, nur stärker Aufgabe Kommentarzeichen: FIXME (hohe Priorität) und XXX (normale Priorität) ist Standard in Eclipse, und man kann mehr Aufgabe Tags definieren (Eclipse-Eigenschaften -> Java -> Compiler -> Task-Tags)

Wenn Sie Ihr Build fehlschlagen mögen, können Sie den Ant verwenden (1.7) enthält Dateiauswahl für Dateien mit bestimmtem Text suchen:

<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">

Offensichtlich ändern ${pom.build.sourceDirectory} zu Ihrem Quellverzeichnis und FIXME auf den Kommentar, die Sie suchen möchten.

Kennt jemand eine gute Möglichkeit, die Dateien in dieser Dateigruppe in der Build-Datei (andere als nur auf der Suche in Eclipse wieder) gefunden zu drucken?

Answer 2

Vermeiden Sie die Notwendigkeit. Wenn Sie Code in einer Klasse sind platzieren, die es nicht in der Produktion sein sollte, herauszufinden, wie es anders zu machen. Geben Sie einen Haken, sagen, so dass der Code-Tests kann das tun, was es braucht, aber die Prüfung Code außerhalb der Klasse verlassen. Oder Unterklasse für die Prüfung, oder Dependency Injection verwenden, oder jede andere Technik, die Ihren Code gültig und sicher lässt für die Produktion, während noch prüfbar. Viele solche Techniken sind in Michael Feathers' fantastischen Buch gut dokumentiert, Effektives Arbeiten mit Legacy-Code .

Answer 3

einen Komponententest hinzufügen, die schlägt fehl, wenn der Block vorhanden ist. Vielleicht setzt der Baustein eine globale Variable CODE_BLOCK_IS_NOT_DELETED = true;, dass die Einheit Test überprüft.

Allerdings ist Ihr größeres Problem ist, dass Sie mit Code testen / entwickeln, die Sie in der Produktion benötigen oder nicht verwenden. Das klingt nicht richtig.

Answer 4

Ein irgendwie schmutzig Vorschlag wäre, eine Klasse zu erstellen, mit einer statischen Methode kann sagen,

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

und dann markieren die Orte, die Sie wollen mit

Prod.uction();

Dann, bevor die Produktion einfach die Klasse löschen und Sie werden Compiler-Fehler erhalten, wo erforderlich: D

Answer 5

Jedoch Sie dies technisch lösen, würde ich empfehlen, es in die andere Richtung zu tun Runde: do nicht etwas Besonderes für die Produktion zu bauen, sondern strukturieren Sie den Code und baut Umgebung so, dass die Magie geschieht während der Entwicklung bauen. Die Produktion bauen sollte als narrensicher (oder Murphy fest) wie möglich sein.

Wenn etwas in der Entwicklung baut schief geht. So was

geht Alles falsch in der Produktion Build wird weh tut viel mehr.

Answer 6

[edit:] Werke für C ++ ...: -)

Verwenden Sie diese Präprozessor defintions und alle Probleme gelöst werden:

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

Nicht sicher, ob die Syntax ganz korrekt ist, aber Sie bekommen die Idee.

Answer 7

Wir haben einen Trigger zu Subversion, die Blöcke \\NOCOMMIT: Sie könnten einen \\NODEPLOY:-Tag haben, dass Ihr Build-Skript für bevor ermöglicht einen Build aussehen würde.

Answer 8

TDD und Dependency Inversion Konzepte könnten Ihnen dabei helfen. Indem Sie den Code, in eine Klasse variiert die eine Schnittstelle implementiert, können Sie steuern, wenn der Test-Version dieser Code ausgeführt wird, und wenn die prod Version ausgeführt wird.

Dann haben Sie eine Datei eindeutig als für den Test genannt, dass Sie aus Ihrem Build verlassen können.

Answer 9

In Projekte, die ich gearbeitet habe, habe ich verschiedene Leckerbissen der Code hatte, die vorhanden sind, während der Entwicklung einfache Prüfung zu ermöglichen. Ich wickle diese in einem Block, wenn die eine endgültige boolean prüft. Wenn die boolean true ist, kann der Code zugegriffen werden. Wenn die boolean false ist, hänge ich auf dem Compiler den Code aus den resultierenden .class-Dateien als Optimierungs entfernen. Zum Beispiel:

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

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

Normalerweise verwalten, ich diese Variablen auf eigene Faust, so dass sie während der Entwicklung mit und Einstellung testbar falsch, wenn ich fertig bin. Ein Entwicklungsteam könnte leicht zu einer Konvention für Variablennamen übereinstimmen, wie prüfbar, und das Produktionsziel der Build-Datei für könnte überprüfen und fehlschlagen, wenn alle Quelldateien eine prüfbare Variable haben = true.

Answer 10

Zusätzlich zu allen oben genannten Vorschlägen (was mit all dem manuellen Mist ist und das Hinzufügen von cruft zum Code? Automatisieren Dinge, die Menschen ...), merke ich, dass Sie Eclipse Frühling verwenden und ANT. Eclipse unterstützt mehrere Quellordner - Code trennen in eine „Quelle“ und „Test“ Ordner, in dem Quellordner setzen alles für die Produktion und setzen alles „nicht-Produktion“ in den Testordner. Frühling können Sie mehrere Konfigurationen haben, die verschiedene Implementierungen verweisen - so können Sie eine Produktionskonfiguration haben, die Klassen nur in der Produktion verweist, und Testkonfiguration (en) mit Ihrem Test Code auszuführen. Lassen Sie den ANT-Skript die Produktion und Testversionen Ihrer App bauen - für den Test fügen Sie den „Test“ Ordner auf Ihrem Kompilierung Pfad, für die Produktion es wegzulassen. Wenn eine Klasse eine Testklasse von der Produktion verweist werden Sie einen Compiler-Fehler erhalten -. Wenn eine Produktion Spring-Konfiguration eine Klasse von Tests in der Produktion verweist, wird es so schnell nicht, wie es um sie zu laden versucht,

Answer 11

Vielleicht als depricated, wenn Sie diese Klassen / Methoden markieren, dann würden sie während der Kompilierung gekennzeichnet werden?

Answer 12

Für unsere Produktionsumgebungen haben wir ein paar einfachen C-Tools für Abschnitte Strippen sind einen ganz besonderen Kommentar verwenden. /*#BEGIN_SKIP*/ und /*#END_SKIP*/. Halten Sie sich an Standard-C-Laufzeit, und Sie können auf jeder Umgebung kompilieren.

Sie können Ihren gesamten Build-Zyklus ändern, den Quellcode zu replizieren, verwandeln sie, und kompilieren Sie es.

Answer 13

Ich würde versuchen, diese so weit wie möglich zu vermeiden. -. Ein alternativer Ansatz wäre Dependency Injection zu verwenden, um verschiedene Implementierungen zum Testen zu injizieren

oder ...

Fügen Sie ein Intest boolean Feld auf die Objekte und wickeln Sie den Optionscode in einer if-Anweisung.

if(inTest) {
testMethod();
}

Sie können diese vboolean mit Dependency Injection gesetzt oder es von einem in Systemeigenschaft (-DinTest = true)

übergeben lesen

Hope, das hilft.

Answer 14

Sie können einen Java-Präprozessor verwenden. Für J2ME-Anwendungen verwende ich Antenne Präprozessor. Der Code sieht wie folgt aus

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

Answer 15

Eclipse-ermöglicht andere Marker als nur // TODO, die Sie hinzufügen können, zum Beispiel // TOBEREMOVED und geben ihm eine hohe Priorität, so zeigt sich, vor allen anderen ERLEDIGEN Markern.

Answer 16

Fügen Sie einfach einige // TODO: - dann ein c # Skript machen (cs-script.net), die für // TODO im Code aussieht und zeigt sie an. Anschließend können Sie dieses Skript in der automatisierten Builds (wenn Sie tun das), so dass jedes Mal, wenn Sie einen Build tun, können Sie sehen, was zu tun ist. Überprüfen Sie ToDo-Liste Ihres Codes vor der Bereitstellung.

Als Alternative ein eigenes Skript zu schreiben, gibt es einige Anweisungen, wie mit etwas Werkzeug zu integrieren VStudio, die Ihre To-do-Linien betonen auch: http://predicatet.blogspot.com/2006/12/show-all-tasks-in-visual-studion- 2005-c.html

Allerdings scheint es mir, bis Einstellung, dass Werkzeug mehr Schmerzes ist ein einfachen C # Skript mit einem regulären Ausdruck als das Schreiben.

Answer 17

Ich verwende das // FIXME Schlüsselwort, das zeigt Eclipse, zusammen mit // TODO, in der Aufgaben-Ansicht (Sie können auswählen, was es zu sehen). Sie sollten nicht auf die Produktion gehen, wenn es einige // FIXME ist um:)

Answer 18

Meine Lösung ist auf zwei verschiedenen Zweigen des Code zu arbeiten. Ein Produktionszweig, der nur sauberen Code ohne Debugging-Code und ein anderes wird (manchmal auch ich habe mehrere davon) zum Testen, Debuggen, versuchen, neue Struff etc.

In Eclipse diese sind getrennte Projekte (oder Gruppen von Projekten).

Mercurial ist ein schönes VCS für diese Art von Arbeit, aber CVS und Subversion ist auch gut.

Answer 19

Der offensichtliche Weg, dies zu lösen, ist einen Unit-Test haben, die nur auf dem Build ausgeführt wird, der die Dateien für die Produktion bauen sollte (oder überprüft, ob die aktuelle Build ist für die Produktion gezielt und laufen den Test, wenn es ist) und scheitern die Build, wenn der Test nicht bestanden.

Sie werden nicht immer vergessen. In Bezug auf welche Art von Test, ideal wäre es tatsächlich zu überprüfen, was auch immer der Code tut. Wenn dies nicht möglich ist, dann wird eine globale statische als Terry Lorber vorgeschlagen viel besser wäre als das, was Sie jetzt haben.