在过去的四年中,我一直在使用Eclipse(对于Java)和Visual Studio Express(对于C#)进行编程。提到的IDE似乎总是提供程序员可能要求的所有功能(当然,与编程有关)。
最近,我一直在听说一种叫做“构建工具”的东西。我听说它们几乎用于各种现实世界的开发中。他们到底是什么?他们打算解决什么问题?在过去的四年中,我为什么从来不需要它们?它们是命令行精简的IDE吗?
在过去的四年中,我一直在使用Eclipse(对于Java)和Visual Studio Express(对于C#)进行编程。提到的IDE似乎总是提供程序员可能要求的所有功能(当然,与编程有关)。
最近,我一直在听说一种叫做“构建工具”的东西。我听说它们几乎用于各种现实世界的开发中。他们到底是什么?他们打算解决什么问题?在过去的四年中,我为什么从来不需要它们?它们是命令行精简的IDE吗?
Answers:
什么是构建工具?
生成工具是可以从源代码自动创建可执行应用程序的程序(例如,适用于Android应用程序的.apk)。构建将编译,链接和打包代码合并为可用或可执行的形式。
基本上,构建自动化是脚本化或自动化软件开发人员在日常活动中执行的各种任务的行为,例如:
- 下载依赖项。
- 将源代码编译为二进制代码。
- 打包该二进制代码。
- 运行测试。
- 部署到生产系统。
为什么我们使用构建工具或构建自动化?
在小型项目中,开发人员通常会手动调用构建过程。对于大型项目而言,这是不切实际的,因为在大型项目中,很难跟踪需要构建的内容,构建过程中的顺序和依赖关系。使用自动化工具可以使构建过程更加一致。
各种构建工具可用(仅命名几个):
- 对于Java-Ant,Maven,Gradle。
- 对于.NET Framework-NAnt
- C#-MsBuild。
要进一步阅读,您可以参考以下链接:
1. 构建自动化
2. 构建自动化软件列表
谢谢。
生成工具通常在IDE内部或完全独立于命令行上运行。
这个想法是将编译和打包代码的工作与创建,调试等分开。
可以在命令或IDE内运行构建工具,两者均由您触发。在将代码从存储库中检出并清理到干净的构建机器上之后,连续集成工具也可以使用它们。
make是* nix环境中用于构建C / C ++的早期命令工具。
作为Java开发人员,最受欢迎的构建工具是Ant和Maven。两者都可以在IntelliJ或Eclipse或NetBeans等IDE中运行。巡航集成或Hudson等连续集成工具也可以使用它们。
构建工具通常用于将源代码转换成二进制文件-它组织源代码,设置编译标志,管理依赖项...其中一些还与运行的单元测试,进行静态分析以及生成文档集成在一起。
Eclipse或Visual Studio也是构建系统(但更多的是IDE),对于Visual Studio而言,它是底层的MSBuild,可用来解析Visual Studio项目文件。
所有构建系统的起源似乎都是著名的“ make”。
有用于不同语言的构建系统:
通常,使用专有域特定语言(make,cmake)或xml(ant,maven,msbuild)来构建系统以指定构建。当前的趋势是使用一种真正的脚本语言来编写构建脚本,例如lua进行预制,并使用groovy进行gradle,使用脚本的优势在于它更加灵活,并且还允许您提出一套标准。 API(作为DSL版本)。
生成过程是使用某些生成工具编译源代码以查找任何错误并创建生成(这是项目的可执行版本)的过程。我们(主要是开发人员)对源代码进行了一些修改,并检入该代码以进行构建过程。在生成过程之后,它给出两个结果:1.生成PASSES,然后您将获得项目的可执行版本(生成已就绪)。2.它失败,并且您得到某些错误,并且未创建构建。
有不同类型的构建过程,例如:1.每晚构建2.门控构建3.持续集成构建等。
构建工具可帮助并自动执行构建过程。
* 因此,简而言之,是开发人员或开发团队使用的预发布格式的软件版本,可通过持续监控其产品并在开发过程中尽早解决任何问题来获得对其产品最终结果的信心。*
这些是可以完成构建的不同类型的过程。
1.持续集成构建:在这种情况下,主要是开发人员签入他们的代码,并且在签入之后立即构建一个用于构建最近更改的构建,因此我们应该知道在签入之后开发人员所做的更改是否已经生效。对于较小的项目或项目的组件,这是首选。如果有多个团队与该项目相关联,或者有很多没有。的开发人员在同一项目上工作,这种情况就变得很难处理,就好像没有“ n”。的签入和构建在某些点失败,要跟踪是否所有破损是由于一个问题还是由于多个问题而发生的,就变得非常困难,因此,如果较旧的问题未得到正确解决,则追查较旧的问题将变得非常困难更改后发生的缺陷。
2.门控的签入构建:在这种类型的签入中,在签入完成后立即将更改保留在一组中就开始了。在这种情况下,如果构建成功而不是搁置集签入将被提交,否则它将不会被提交到Team Foundation Server。由于仅允许成功签入,因此从持续集成构建中可以得到更好的印象。
3.每晚构建:也称为计划构建。在这种情况下,我们计划将构建运行特定的时间以构建更改。在此构建过程中将构建来自上一构建的所有先前未提交的更改。当我们想多次检入但又不想每次签入代码都想要构建时,就会采用这种做法,这样我们就可以有一个固定的时间或期限,在此期间我们可以启动构建以构建签入的代码。
有关这些构建的更多详细信息,请参见以下位置。
“ ...很难跟踪需要构建的内容”-构建工具无助于此。您需要知道要构建什么。(引自Ritesh Gun的回答)
“我听说它们几乎用于各种现实世界的开发中”-由于某种原因,软件开发人员喜欢在大型公司工作。他们似乎对在那里工作的每个人都有更加不清楚的工作指令。
“过去四年来,我为什么永远都不需要它们”。可能是因为您是一位熟练的程序员。
伪元 我认为构建工具根本无法提供任何真正的好处。只是在这里增加了由于不良公司做法,缺乏指导而引起的安全感-不良的软件体系结构领导能力导致不良的项目实际知识。您永远不必在项目中使用构建工具(用于测试)。在缺乏软件项目知识的情况下进行随机测试根本无法提供任何帮助。
永远不要在不知道目的,以及它如何与其他组件一起工作的情况下向项目中添加内容。组件可以在功能上分开,但不能一起工作。(这是我承担的软件架构师的责任)。
如果将4-5个组件添加到项目中该怎么办。您添加第六个组件。与第一个添加的组件一起使用,可能会破坏所有内容。没有自动方法可以帮助检测到这一点。
除了思考,没有其他捷径。
然后是从存储库自动下载。你为什么要这么做?您需要知道下载的内容,添加到项目的内容。您如何检测版本库中的更改?你得知道。您不能“自动”执行任何操作。
如果我们要测试自行车和婴儿运输工具,然后用棍子将其蒙住眼睛,然后随机将其撞到附近,该怎么办?这似乎是构建工具测试的想法。
抱歉,没有捷径 https://en.wikipedia.org/wiki/Scientific_method 和 https://en.wikipedia.org/wiki/Analysis