当前位置： 文江博客话题详情

如何标记一些在生产前必须删除的代码？

发布于 2024-07-25 09:48:51 字数 487 浏览 7 评论 0原文

有时出于测试/开发目的，我们会对代码进行一些更改，这些更改必须在生产版本中删除。 我想知道是否有一种简单的方法来标记这些块，以便只要它们存在，生产构建就会失败，或者至少它会在构建过程中以某种方式警告您。

简单的 "//TODO:" 并没有真正起作用，因为它经常被遗忘并与大量其他待办事项混合在一起。 有什么更强的吗？

或者，即使我可以创建一些外部 txt 文件，并在其中放置有关在生产之前做什么的说明，并且该 ant 会检查该文件是否存在，然后取消构建。

我们正在使用 Eclipse/Ant（以及 java + Spring）。

更新：我的意思并不是说本地和生产中有大量不同的代码。 事实上所有代码都是相同的并且应该是相同的。 假设我注释掉了一些代码行以在开发过程中节省大量时间，但忘记取消注释或类似的内容。 我只是希望能够以某种方式标记该项目，表明某些事情需要注意，并且生产构建将失败或显示警告。

原文

Sometimes for testing/developing purposes we make some changes in the code that must be removed in a production build. I wonder if there is an easy way of marking such blocks so that production build would fail as long as they are present or at least it will warn you during the build somehow.

Simple "//TODO:" doesn't really work because it is ofter forgotten and mixed with tons of other todos. Is there anything stronger?

Or maybe even if I can create some external txt file and put there instructions on what to do before production, and that ant would check if that file is present then cancel build.

We are using Eclipse/Ant (and java + Spring).

Update: I don't mean that there are big chunks of code that are different in local and production. In fact all code is the same and should be the same. Just lets say I comment out some line of code to save lot of time during development and forget to uncomment it or something along those lines. I just want to be able to flag the project somehow that something needs an attention and that production build would fail or show a warning.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（19）

独行侠 2024-08-01 09:48:51

避免必要性。 如果您将代码放入生产中不应存在的类中，请弄清楚如何以不同的方式进行操作。 例如，提供一个钩子，以便测试代码可以执行其需要的操作，但将测试代码留在类之外。 或者使用子类进行测试，或者使用依赖注入，或者任何其他技术，使您的代码对生产有效且安全，同时仍然可测试。 许多此类技术在 Michael Feathers 的精彩著作有效处理遗留代码。

Avoid the necessity. If you're placing code into a class that shouldn't be there in production, figure out how to do it differently. Provide a hook, say, so that the testing code can do what it needs to, but leave the testing code outside the class. Or subclass for testing, or use Dependency Injection, or any other technique that leaves your code valid and safe for production, while still testable. Many such techniques are well-documented in Michael Feathers' fantastic book, Working Effectively with Legacy Code.

回复 原文
呆橘 2024-08-01 09:48:51

您还可以定义更强的任务注释标记：FIXME（高优先级）和XXX（普通优先级）是Eclipse中的标准，并且您可以定义更多任务标签（Eclipse Properties -> Java -> Compiler -> Task Tags）

如果您想让构建失败，您可以使用 Ant (1.7) contains< /a> 文件选择器来查找包含指定文本的文件：

<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 中查看之外）？

You could also just define stronger task comment markers: FIXME (high priority) and XXX (normal priority) are standard in Eclipse, and you could define more task tags (Eclipse Properties -> Java -> Compiler -> Task Tags)

If you want to fail your build, you could use the Ant (1.7) contains file selector to look for files containing specified text:

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

Obviously, change ${pom.build.sourceDirectory} to your source directory, and FIXME to the comment that you want to search for.

Does anyone know a nice way to print out the files found in this fileset in the build file (other than just looking in Eclipse again)?

回复 原文
眼眸 2024-08-01 09:48:51

添加一个单元测试，如果该块存在，则该单元测试会失败。 也许该块设置了单元测试检查的全局变量CODE_BLOCK_IS_NOT_DELETED = true;。

然而，您更大的问题是您使用生产中不需要或不需要的代码进行测试/开发。 这听起来不对。

Add a unit test that fails if the block is present. Maybe the block sets a global variable CODE_BLOCK_IS_NOT_DELETED = true; that the unit test checks for.

However, your bigger problem is that you test/develop with code that you don't need or use in production. That doesn't sound right.

回复 原文
初懵 2024-08-01 09:48:51

一个不知何故肮脏的建议是创建一个带有静态方法的类

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

，然后用标记你想要的地方

Prod.uction();

然后在生产之前只需删除该类，你将在需要的地方得到编译器错误：D

One somehow dirty suggestion would be to create a class with a static method lets say

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

and then mark the places you want with

Prod.uction();

Then before production simply delete the class and you will get compiler errors where needed :D

回复 原文
私藏温柔 2024-08-01 09:48:51

无论您从技术上解决这个问题，我建议您以相反的方式进行：不要为生产构建做一些特殊的事情，而是以这样的方式构建您的代码和构建环境，以便在生产过程中发生神奇的事情。开发构建。 生产版本应该尽可能万无一失（或墨菲证明）。

如果开发版本中出现问题：那又怎样。

生产构建中出现的任何问题都会造成更大的伤害。

However you technically solve this, I would recommend to do it the other way round: do not do something special for the production build but structure your code and build environment in such a way that the magic happens during the development build. The production build should be as foolproof (or Murphy proof) as possible.

If something goes wrong in the development build: so what.

Anything going wrong in the production build will hurt much more.

回复 原文
月亮邮递员 2024-08-01 09:48:51

[编辑：] 适用于 C++...:-)

使用这些预处理器定义，您的所有问题都将得到解决：

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

不确定语法是否完全正确，但您明白了。

[edit:] Works for C++... :-)

Use these preprocessor defintions and all your problems will be solved:

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

Not sure if the syntax is entirely correct, but you get the idea.

回复 原文
蓝礼 2024-08-01 09:48:51

我们添加了一个触发器来阻止 \\NOCOMMIT: 您的构建脚本在允许构建之前会查找 \\NODEPLOY: 标记。

We added a trigger to subversion that blocks \\NOCOMMIT: You could have a \\NODEPLOY: tag that your build script would look for before allowing a build.

回复 原文
孤君无依 2024-08-01 09:48:51

TDD 和依赖倒置概念可能会对您有所帮助。 通过将不同的代码放入实现接口的类中，您可以控制该代码的测试版本何时运行以及产品版本何时运行。

然后你就有了一个文件，明确命名为用于测试，你可以将其从构建中删除。

TDD and Dependency Inversion concepts might help you here. By putting the code that varies into a class that implements an interface, you can control when the Test version of that code runs and when the prod version runs.

Then you have a file, clearly named as being for testing, that you can leave out of your build.

回复 原文
清晨说晚安 2024-08-01 09:48:51

在我从事的项目中，我有各种代码花絮，可以在开发过程中轻松进行测试。 我将它们包装在检查最终布尔值的 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 变量 = true，则构建文件的生产目标可以检查并失败。

In projects I've worked on, I've had various tidbits of code that are in place to enable easy testing during development. I wrap these in an if block that checks a final boolean. When the boolean is true, the code can be accessed. When the boolean is false, I depend on the compiler removing the code from the resulting .class files as an optimization. For instance:

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

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

Typically, I manage these variables on my own, using them during development and setting TESTABLE to false when I'm done. A development team could easily agree to a convention for variable names, like TESTABLE, and the build file's production target could check for and fail if any source files had a TESTABLE variable = true.

回复 原文
薯片软お妹 2024-08-01 09:48:51

除了上述所有建议（所有手动垃圾和向代码中添加垃圾是怎么回事？自动化人们的事情......），我注意到您正在使用 Eclipse、Spring 和 ANT。 Eclipse 支持多个源文件夹 - 将代码分离到“源”和“测试”文件夹中，将用于生产的所有内容放入源文件夹中，并将所有“非生产”内容放入测试文件夹中。 Spring 允许您拥有引用不同实现的多个配置 - 因此您可以拥有仅在生产中引用类的生产配置，以及与测试代码一起运行的测试配置。 让 ANT 脚本构建应用程序的生产和测试版本 - 为了测试，将“testing”文件夹添加到您的编译路径，对于生产，将其保留。 如果一个类引用了生产中的测试类，您将收到编译错误 - 如果生产 Spring 配置引用了生产中测试的类，则一旦尝试加载它就会失败。

In addition to all the above suggestions (what's with all the manual crap and adding cruft to the code? automate things people...), I notice that you're using Eclipse, Spring, and ANT. Eclipse supports multiple source folders - separate your code out into a "source" and "testing" folder, put anything for production in the source folder and put anything "not production" in the testing folder. Spring allows you to have multiple configurations that reference different implementations - so you can have a production configuration that references classes only in production, and testing configuration(s) to run with your testing code. Have the ANT script build the production and testing versions of your app - for testing add the "testing" folder to your compile path, for production leave it off. If a class references a testing class from production you'll get a compile error - if a production Spring configuration references a class from testing in production, it will fail as soon as it tries to load it.

回复 原文
仅此而已 2024-08-01 09:48:51

也许如果您将这些类/方法标记为已弃用，那么它们会在编译时被标记？

Maybe if you mark those classes/methods as depricated, then they would be flagged during compilation time?

回复 原文
别闹i 2024-08-01 09:48:51

对于我们的生产环境，我们有几个简单的 C 工具，可以使用非常特殊的注释来删除部分。 /*#BEGIN_SKIP*/ 和 /*#END_SKIP*/。 坚持标准 C 运行时，您可以在任何环境上进行编译。

您可以更改整个构建周期来复制源代码、转换它并编译它。

For our production environments, we have a couple of simple C tools for stripping out sections using a very special comments. /*#BEGIN_SKIP*/ and /*#END_SKIP*/. Stick to standard C run-time, and you can compile on any environment.

You can change your entire build cycle to replicate the source code, transform it, and compile it.

回复 原文
画尸师 2024-08-01 09:48:51

我会尽量避免这种情况。 - 另一种方法是使用依赖注入来注入不同的实现以进行测试。

或者...

向对象添加一个 inTest 布尔字段，并将可选代码包装在 if 语句中。

if(inTest) {
testMethod();
}

您可以使用依赖项注入来设置此 vboolean 或从传入的系统属性中读取它（-DinTest=true）

希望这会有所帮助。

I would try to avoid this as far as possible. - An alternative approach would be to use dependency injection to inject different implementations for testing.

Or...

Add an inTest boolean field to the objects and wrap the optional code in an if statement.

if(inTest) {
testMethod();
}

You could set this vboolean with dependency injection or read it from a passed in system property (-DinTest=true)

Hope this helps.

回复 原文
谁与争疯 2024-08-01 09:48:51

您可以使用 java 预处理器。 对于 j2me 应用程序，我使用天线预处理器。 代码看起来像这样

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

You can use a java preprocessor. For j2me applications I use antenna preprocessor. The code looks like this

public void someMethod() {
    //#ifdef DEBUG
    doDebugStuff();
    //#endif     
}
回复 原文
笑咖 2024-08-01 09:48:51

Eclipse 允许使用其他标记，而不仅仅是 //TODO，例如，您可以添加 //TOBEREMOVED 并给它一个高优先级，因此它会显示在所有其他 TODO 标记之前。

Eclipse allows for other markers than just //TODO, you can add, for example, //TOBEREMOVED and give it a high priority, so it shows up before all the other TODO markers.

回复 原文
瑶笙 2024-08-01 09:48:51

只需添加一些 //TODO: -- 然后制作 ac# 脚本 (cs-script.net) 在代码中查找 //TODO 并显示它们。 然后，您可以将此脚本添加到自动构建中（如果您正在这样做），因此每次进行构建时，您都可以看到要执行的操作。 在部署之前检查代码的待办事项列表。

除了编写自己的脚本之外，还有一些关于如何将 vstudio 与某些工具集成的说明，这些工具也指出了您的待办事项：http://predicatet.blogspot.com/2006/12/show-all-tasks-in-visual-studion-2005-c .html

然而，在我看来，设置该工具比使用正则表达式编写简单的 C# 脚本更痛苦。

Just add some //TODO: -- then make a c# script (cs-script.net) which looks for //TODO in your code and displays them. You can then add this script to your automated builds (if you're doing that), so each time you do a build, you can see what there is to do. Review your code's todo list before deploying.

Alternatively to writing your own script, there's some instructions on how to integrate vstudio with some tool that points out your todo lines as well: http://predicatet.blogspot.com/2006/12/show-all-tasks-in-visual-studion-2005-c.html

However, it seems to me, setting up that tool is more of a pain than writing a simple C# script with a regex.

回复 原文
我最亲爱的 2024-08-01 09:48:51

我使用 Eclipse 在任务视图中显示的 //FIXME 关键字以及 //TODO（您可以过滤在其上看到的内容）。
如果周围有一些//FIXME，你就不应该投入生产:)

I use the //FIXME keyword that eclipse displays, together with //TODO, in the Tasks View (you can filter what to see on it).
You shouldn't go out to production if there is some //FIXME around :)

回复 原文
愛上了 2024-08-01 09:48:51

我的解决方案是处理两个独立的代码分支。 一个生产分支只获得干净的代码，没有任何调试代码，另一个（有时我什至有几个）用于测试、调试、尝试新的东西等。

在 Eclipse 中，这些是单独的项目（或项目组）。

对于此类工作来说，Mercurial 是一个不错的 VCS，但 CVS 和 subversion 也很好。

My solution is to work on two seperate branches of code. One production branch which only gets clean code without any debugging code and another (Sometimes I even have several of these) for testing, debugging, trying new struff etc.

In eclipse these are separate projects (or groups of projects).

Mercurial is a nice VCS for this type of work but CVS and subversion are good too.

回复 原文
人│生佛魔见 2024-08-01 09:48:51

解决这个问题的明显方法是进行一个单元测试，该测试仅在旨在构建生产文件的构建上运行（或检查当前构建是否针对生产，如果是则运行测试）并使构建失败如果测试失败。

你永远不会忘记。 就哪种测试而言，理想情况下它会实际检查代码的功能。 如果这是不可能的，那么特里·洛伯（Terry Lorber）建议的全局静态会比你现在拥有的要好得多。

The obvious way to solve this is to have a unit test that only runs on the build that is intended to build the files for production (or checks if the current build is targeted for production and runs the test if it is) and fail the build if the test fails.

You won't ever forget. In terms of what kind of test, ideally it would actually check for whatever the code does. If this is not possible, then a global static as Terry Lorber suggested would be a lot better than what you have now.

回复 原文
~没有更多了~

关于作者

小…楫夜泊

暂无简介

0 文章
0 评论
22 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

留蓝

文章 0 评论 0

18790681156

文章 0 评论 0

zach7772

文章 0 评论 0

Wini

文章 0 评论 0

ayeshaaroy

文章 0 评论 0

初雪

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文