这是詹姆士·肖尔(James Shore)和谢恩·沃登(Shane Warden)的书《敏捷开发的艺术》中的“十分钟构建”规则,很容易看出为什么这是一个好主意,因为不容易运行的构建既令人沮丧,降低了道德水平,又浪费了项目时间把你公司的钱扔进比喻的熔炉中。
如果构建时间超过10分钟左右,则应注意以下几点。 要考虑的是工具和基础设施,用通俗的英语说真的意味着:您是否拥有专用的构建机器,并且使用的工具集正确吗? 获得专用的构建机器应该不会太难,因为这样做具有成本优势:开发人员的时间花费了虚拟或真实盒子的成本,而您需要的许多工具都是开源的:Maven,CruiseControl / Hudson ,GIT / Subversion等。
如果您已经拥有专用的构建机器并且正在使用所有正确的工具,那么接下来要看的就是单元测试。 包含大量“端到端”或集成测试的构建通常是罪魁祸首。 端到端测试很有用,因为它们可以证明您的班级可以一起工作,但是您的主要测试重点应该是班级的全套隔离单元测试,涵盖所有必要的情况和边缘条件。
这是因为端到端测试通常涉及设置和拆除某些外部服务,例如数据库。 有人说,您实际上并不需要任何端到端测试,但是我认为您需要这样做,以证明您的类可以一起工作。 那么您应该使用多少个集成测试? 我希望每个场景只瞄准一两个,但前提是每个班级要进行大量的单元测试(例如10-20个),以使我有信心一切正常。
前一段时间,我提到了FIRST首字母缩写 (摘自Bob Martin的Clean Code ),其中测试应该是快速,独立,可重复,自验证和及时的,这是检查单元测试性能的很好的起点。
务实的是,有些应用程序将在10分钟内永远不会生成。 在这种情况下,请考虑按照Maven构建手册的建议将程序分成较小的模块。 问问自己,是否将数据库访问类与业务逻辑或表示代码一起构建到相同的JAR文件中,如果是,请将其拆分。 您可以更进一步,并创建一个分布式并行构建环境,但是要小心,在这里您可能无意间违反了敏捷的“保持简单”规则。
参考: Captain Debug博客上的JCG合作伙伴 《十分钟构建》 。
相关文章 :
翻译自: https://www.javacodegeeks.com/2011/09/ten-minute-build.html