Manchmal machen wir zum Testen / Entwickeln einige Änderungen im Code, die in einem Produktions-Build entfernt werden müssen. Ich frage mich, ob es eine einfache Möglichkeit gibt, solche Blöcke zu markieren, so dass der Build der Produktion scheitern würde, solange sie vorhanden sind, oder zumindest wird er Sie während des Builds irgendwie warnen.
Simple "//TODO:" funktioniert nicht wirklich, weil es oft vergessen und mit vielen anderen Todos gemischt wird. Gibt es etwas Stärkeres?
Oder vielleicht, auch wenn ich eine externe TXT-Datei erstellen kann und dort Anweisungen dazu gebe, was vor der Produktion zu tun ist, und diese Ameise würde prüfen, ob diese Datei vorhanden ist, dann baue abbrechen.
Wir verwenden Eclipse / Ant (und Java + Spring).
Update: Ich meine nicht, dass es große Code-Abschnitte gibt, die in der lokalen und der Produktion anders sind. In der Tat ist der gesamte Code der gleiche und sollte der gleiche sein. Lassen Sie mich nur sagen, dass ich eine Codezeile auskommentiere, um während der Entwicklung viel Zeit zu sparen, und vergessen Sie, sie oder etwas in dieser Richtung zu entfernen. Ich möchte nur das Projekt irgendwie kennzeichnen können, dass etwas Aufmerksamkeit benötigt und dass der Produktionsaufbau fehlschlagen oder eine Warnung anzeigen würde.
Sie können auch einfachere Aufgabenkommentarmarker definieren: FIXME (hohe Priorität) und XXX (normale Priorität) sind Standard in Eclipse, und Sie könnten weitere Aufgaben-Tags definieren (Eclipse-Eigenschaften - & gt; Java - & gt; Compiler - & gt; Aufgaben-Tags)
Wenn Sie den Build nicht ausführen möchten, können Sie die Ant (1.7) contains verwenden Dateiauswahl, um nach Dateien zu suchen, die den angegebenen Text enthalten:
%Vor% Offensichtlich ändern Sie ${pom.build.sourceDirectory} in Ihr Quellverzeichnis und FIXME in den Kommentar, nach dem Sie suchen möchten.
Kennt jemand eine nette Möglichkeit, die in dieser Dateigruppe in der Erstellungsdatei gefundenen Dateien auszudrucken (anders als nur in Eclipse zu suchen)?
Vermeiden Sie die Notwendigkeit. Wenn Sie Code in eine Klasse einfügen, die in der Produktion nicht vorhanden sein sollte, sollten Sie herausfinden, wie Sie das anders machen können. Stellen Sie beispielsweise einen Hook bereit, damit der Testcode das tun kann, was er benötigt, aber lassen Sie den Testcode außerhalb der Klasse. Oder Unterklasse zum Testen, oder verwenden Sie Dependency Injection oder eine andere Technik, die Ihren Code für die Produktion gültig und sicher lässt, während er noch testbar ist. Viele dieser Techniken sind in Michael Feathers fantastischem Buch effektiv mit Legacy-Code dokumentiert.
Fügen Sie einen Komponententest hinzu, der fehlschlägt, wenn der Block vorhanden ist. Möglicherweise legt der Block eine globale Variable CODE_BLOCK_IS_NOT_DELETED = true; fest, nach der der Komponententest sucht.
Ihr größtes Problem ist jedoch, dass Sie mit Code testen / entwickeln, den Sie nicht benötigen oder in der Produktion verwenden. Das klingt nicht richtig.
Ein irgendwie dreckiger Vorschlag wäre, eine Klasse mit einer statischen Methode zu erstellen, sagen wir
%Vor%und markieren Sie dann die gewünschten Orte mit
%Vor%Dann vor der Produktion löschen Sie einfach die Klasse und Sie erhalten Compilerfehler, wo benötigt: D
Wie auch immer du das technisch löst, würde ich empfehlen, es andersherum zu machen: tu nicht etwas für den Produktions-Build, sondern baue deinen Code und baue die Umgebung so, dass die Magie entsteht passiert während der Entwicklung Build. Der Produktionsaufbau sollte so idiotensicher (oder Murphy Proof) wie möglich sein.
Wenn bei der Entwicklung etwas schief geht: na und?
Alles, was bei der Produktion falsch läuft, wird viel mehr schaden.
TDD und Dependency Inversion-Konzepte könnten Ihnen hier helfen. Indem Sie den Code, der variiert, in eine Klasse einfügen, die eine Schnittstelle implementiert, können Sie steuern, wann die Testversion dieses Codes ausgeführt wird und wann die Produktversion ausgeführt wird.
Dann haben Sie eine Datei, die eindeutig zum Testen benannt ist und die Sie aus Ihrem Build herauslassen können.
In Projekten, an denen ich gearbeitet habe, hatte ich verschiedene Leckerbissen an Code, die vorhanden sind, um ein einfaches Testen während der Entwicklung zu ermöglichen. Ich verpacke diese in einen if-Block, der einen finalen Booleschen Wert überprüft. Wenn der Boolesche Wert wahr ist, kann auf den Code zugegriffen werden. Wenn der Boolesche Wert falsch ist, bin ich davon abhängig, dass der Compiler den Code aus den resultierenden .class-Dateien als Optimierung entfernt. Zum Beispiel:
%Vor%Normalerweise verwalte ich diese Variablen selbst, benutze sie während der Entwicklung und setze TESTABLE auf false, wenn ich fertig bin. Ein Entwicklungsteam könnte leicht einer Konvention für Variablennamen wie TESTABLE zustimmen, und das Produktionsziel der Erstelldatei könnte prüfen und fehlschlagen, wenn Quelldateien eine TESTABLE-Variable = true enthielten.
Zusätzlich zu all den oben genannten Vorschlägen (was ist mit all dem manuellen Mist und Hinzufügen von Gruft zum Code? automatisieren Dinge Leute ...), merke ich, dass Sie Eclipse, Spring und ANT verwenden. Eclipse unterstützt mehrere Quellordner - trennen Sie Ihren Code in einen "Quell" - und "Test" -Ordner, legen Sie alles für die Produktion in den Quellordner und legen Sie alles "Nicht-Produktion" in den Testordner. Mit Spring können Sie mehrere Konfigurationen verwenden, die auf verschiedene Implementierungen verweisen. So können Sie eine Produktionskonfiguration erstellen, die Klassen nur in der Produktion referenziert und Konfigurationen testet, die mit Ihrem Testcode ausgeführt werden. Lassen Sie das ANT-Skript die Produktions- und Testversionen Ihrer App erstellen - zum Testen fügen Sie den "test" -Ordner zu Ihrem Kompilierpfad hinzu, für die Produktion lassen Sie es ab. Wenn eine Klasse eine Testklasse aus der Produktion referenziert, erhalten Sie einen Kompilierungsfehler - wenn eine Spring-Produktionskonfiguration auf eine Klasse aus Tests in der Produktion verweist, wird sie fehlschlagen, sobald sie versucht, sie zu laden.
Für unsere Produktionsumgebungen haben wir ein paar einfache C-Tools zum Ausschneiden von Abschnitten mit einem ganz besonderen Kommentar. /*#BEGIN_SKIP*/ und /*#END_SKIP*/ . Halten Sie sich an die Standard-C-Laufzeit und Sie können in jeder Umgebung kompilieren.
Sie können den gesamten Erstellungszyklus ändern, um den Quellcode zu replizieren, zu transformieren und zu kompilieren.
Ich würde versuchen, das so weit wie möglich zu vermeiden. - Ein alternativer Ansatz wäre, die Abhängigkeitsinjektion zu verwenden, um verschiedene Implementierungen zum Testen zu injizieren.
Oder ...
Fügt den Objekten ein boolesches inTest-Feld hinzu und umschließt den optionalen Code in einer if-Anweisung.
%Vor%Sie können dieses vboolean mit Abhängigkeitsinjektion festlegen oder es aus einer übergebenen Systemeigenschaft (-DinTest = true)
lesenHoffe, das hilft.
Sie können einen Java-Präprozessor verwenden. Für j2me-Anwendungen verwende ich einen Antennen-Preprozessor. Der Code sieht so aus
%Vor%Füge einfach ein paar // TODO hinzu: - dann mache ein c # -Skript (cs-script.net), das in deinem Code nach // TODO sucht und zeigt sie an. Sie können dieses Skript dann zu Ihren automatisierten Builds hinzufügen (wenn Sie das tun), so können Sie bei jedem Build sehen, was zu tun ist. Überprüfen Sie die Aufgabenliste Ihres Codes vor der Bereitstellung.
Alternativ zum Schreiben Ihres eigenen Skripts gibt es einige Anweisungen, wie Sie vstudio mit einem Tool integrieren, das auch Ihre Todo-Zeilen hervorhebt: Ссылка
Allerdings scheint mir die Einrichtung dieses Tools schmerzhafter als das Schreiben eines einfachen C # -Skripts mit einem Regex.
Meine Lösung besteht darin, an zwei getrennten Codezweigen zu arbeiten. Ein Produktionszweig, der nur sauberen Code ohne Debugging-Code bekommt und ein anderer (manchmal habe ich sogar mehrere) zum Testen, Debuggen, Versuchen neuer Strupf etc.
In Eclipse sind dies separate Projekte (oder Gruppen von Projekten).
Mercurial ist ein nettes VCS für diese Art von Arbeit, aber CVS und Subversion sind auch gut.
Der einfachste Weg, dies zu lösen, ist ein Komponententest, der nur auf dem Build ausgeführt wird, der die Dateien für die Produktion erstellen soll (oder prüft, ob der aktuelle Build für die Produktion ausgerichtet ist und den Test ausführt) Scheitern Sie den Build, wenn der Test fehlschlägt.
Du wirst es nie vergessen. In Bezug auf welche Art von Test, im Idealfall würde es tatsächlich überprüfen, was auch immer der Code tut. Wenn das nicht möglich ist, dann wäre ein globales Statik wie Terry Lorber viel besser als das, was Sie jetzt haben.