使用 ant 或 nant 等构建工具的投资回报率是多少？
对我来说，这听起来是一个非常愚蠢的问题。
为什么不使用构建工具？
然而，我需要向我的同事解释为什么他应该使用某种构建工具。
他真正开始考虑与更多程序员组成一个团队，但他不了解构建过程中需要更改哪些内容才能与更大的团队合作的更宏观的情况； （即防御性编程/对代码进行单元测试、拥有错误数据库、编程模块化库以及使用 在版本控制中存储模块的子存储库
这是一个相当大的技术堆栈，我需要证明它的投资回报率......所以我想我应该从使用构建工具的投资回报率开始。不仅仅是...说...单击编译。
To me this sounds like a really stupid question.
Why would you not use a build tool?
However, I need to explain my co-worker why he should be using a build tool of some sort.
He's getting really into the idea of working as a team with more programmers, but he isn't understanding the bigger picture of what needs to change in the build process in order to work with a larger team; (i.e. defensive programming/unit testing your code, having a bug database, programming modular libraries, and using sub-repositories to store modules in version control.
This is a rather large stack of technologies that I need to prove the ROI of...so I figured I'd start with the ROI of using a build tool rather than just...say...clicking compile.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为了获得有效的投资回报率，您必须了解投资成本以及投资将带来的节省或增加收入的成本。
对于像 Ant 和 Maven（我会使用 maven）这样的工具，你不需要许可费，但你需要培养这些工具的技能，这可能会花费一些钱。
这些自动化工具的主要好处是：
对于每一个，你都必须贴上价格标签。您可以说，一个好的 IDE 会为您完成构建和测试。但这会因用户而异。假设新开发人员需要 4 小时才能拥有有效的构建环境，并且有人正在提供帮助。这将花费 X，而自动化流程将大大降低成本。再加上修复 bug 的成本（构建过程不会避免所有 bug，但假设 30% 可以避免）。这些东西就是成本。
现在将其与您的同事必须投资多少来学习该工具进行比较（这是使用此类工具的一次性成本）。但我认为困扰你同事的更多是恐惧而不是理智。
当您向他们展示的人同意所使用的价值观时，投资回报率就会增加。因此，请尝试使用您过去的项目成本来执行此操作。在这种情况下，您可以比较时间而不是金钱。人们可能会因为不一致的构建而陷入困境，从而严重延迟项目。
To get a valid ROI you have to have the cost of the investment and the cost of the savings or added revenue that the investments will bring.
For tools like Ant and Maven (I would use maven) you have no license fee, but you need to build skill on the tools, which may cost some money.
The key benefits for these automated tools are:
For each of this you have to put a price tag. You can argue that a good IDE will do the building and testing for you. But this will change from user to user. Lets say it takes 4 hours to get a new developer to have a valid build environment, and someone is helping. That is going to cost X, which would be severely reduced by a automated process. Add to that how much it cost of fix a bug (not all will be avoided by the build process, but let's say 30% are). These things are the cost.
Now compare that to how much your co-worker has to invest to learn the tool (which is the one time cost of using such tools). But I think that it's more fear than reason that bothers your co-worker.
ROI make more since when the person you are showing them to agree with the values being used. So try to use your past project cost to do this. In this case you can compare time instead of money. Projects can be severely delayed by people banging their heads on inconsistent builds.
Ant 不仅仅明显对每个编程商店都有好处。您的构建过程涉及多少集成？您使用什么工具？您选择了哪个 CI 服务器？
简单的答案是，当 Ant 为您节省时间时，投资回报率就会很高，只有有关您的情况的详细信息和经验在决定它能为您节省多少时间时才有意义。
在我们的例子中，我们使用 Nant 来构建数据库，因为这样做涉及许多命令行级步骤。我们不在 .NET 软件上使用 Nant，因为 VS 2010 和 TestDriven.Net 比任何其他构建解决方案提供更多的上下文敏感性，并且我们优秀的 CI 服务器 TeamCity 本身就理解 Visual Studio 构建过程。
Ant isn't just obviously beneficial in every programming shop. How much integration is involved in your build process? What tool(s) are you using? Which CI server have you chosen?
The simple answer is that the ROI is high when Ant saves you time, and only details about and experience with your situation are going to be relevant when deciding how much time it will save you.
In our case, we use Nant to build our databases because numerous command line-level steps are involved with doing so. We do not use Nant on our .NET software because VS 2010 and TestDriven.Net provide far more context-sensitivity than any other build solution and our excellent CI server, TeamCity, natively understands the Visual Studio build process.
我的想法是无论是你自己的生意还是为别人工作。如果该工具至少可以为您节省购买该工具所花费的资金，那么它就是一项值得的投资。请记住，省钱可能与
不要忘记，工具通常需要初始培训/学习，这也是成本。因此，如果该工具是一次性的，您可能需要权衡学习成本是否超过该工具的成本。
回到你的问题的基础...举个例子，如果构建工具的价格是 1000 美元，那么你的时间就是 100 美元/小时。我们将忽略工具培训成本，因为我们打算多次使用构建工具。
如果您需要花费 0.5 小时使用工具来创建最终的构建环境，数学表明
您使用工具的成本 = $1000 + (0.5 x $100) = $1050
如果您需要花费 12 小时来手动设置构建环境
没有工具的成本 = 12 x 100 美元 = 1200 美元
或者，也许是一个更现实的例子，您可以看到 6 个即将进行的项目。使用构建工具设置每个项目需要 0.5 小时，如果不使用构建工具则需要 3 小时。
您的工具成本 = 1000 美元 + (6 x (0.5 x 100)) = 1300 美元
没有工具的成本 = 6 x (3 x 100) = 1800 美元
看来，在这些场景中构建工具将被视为一项值得的投资。
希望这有帮助...
The way I think about it whether it is your own business or working for someone else. If the tool can save you at least the money that was spent to acquire the tool, then it is a worthwhile investment. Keeping in mind that saving money can be related to time spent for
Don't forget that a tool generally requires initial training / learning that is a cost also. So if the tool is a once off, you may need to weigh up whether the cost of learning outweighs the cost of the tool.
Getting back to the basis for your question... As an example, if a build tool was $1000, your time is $100/hr. We will disregard tool training cost as we intend to use the build tool multiple times.
If you need to spend 0.5 hours with a tool to create a final build environment the maths says
Your cost with a tool = $1000 + (0.5 x $100) = $1050
If you need to spend say 12 hours to do set up the build environment manually
Your cost without a tool = 12 x $100 = $1200
Or, maybe an example that is a little more realistic, you can see 6 upcoming projects. Each project will take 0.5 hours to set up with a build tool, or 3 hours without.
Your cost with tool = $1000 + (6 x (0.5 x 100)) = $1300
Your cost without tool = 6 x (3 x 100) = $1800
It seems that the build tool in these scenarios would be seen as a worthwhile investment.
Hope this helps...
首先，构建不仅仅意味着编译，而且通常涉及编译代码、编译测试、运行测试、运行质量检查、打包代码、组装部件等步骤 其次，对
我来说，很明显，从长远来看，自动化构建总是比手动执行上述步骤具有更好的投资回报率（更不用说人类会犯错误，你可能不想依赖于 IDE，您可能希望在另一个平台（可能是无头平台等）上运行构建。
第三，无论如何，构建自动化是持续集成的绝对要求，这被认为是每个人都应该遵循的最佳实践（您希望尽快得到反馈，您不想让问题进一步进入系统，直到出现问题为止）。大爆炸集成）。
所以对我来说，问题甚至不是投资回报率，而是理智。为了以防万一，这里有一个小引用（另请参见三击自动化）：
First of all, build means a lot more than just compiling and typically involves steps like compiling code, compiling tests, running tests, running quality checks, packaging the code, assembling parts together, sometimes deploying, etc.
Secondly, it seems obvious to me that an automated build will always have a better ROI than doing the above steps manually on the long term (not even to mention that humans make mistakes, that you may not want to be dependent on the IDE, that you may want to run the build on another, possibly headless, platform, etc).
Thirdly, build automation is anyway an absolute requirement for continuous integration which is known to be a best-practice that everybody should follow (you want feedback as soon as possible, you don't want to let a problem go further into the system until the big-bang integration).
So for me, the question is not even about ROI, it's about sanity. Just in case, here is a little quote (see also Three Strikes And You Automate):