拥有(或重构)构建器

Own (and Refactor) the Build

在一个团队里,纪律严明地开展编程实践而忽视构建脚本的情况并不罕见,他们认为那些只不过是无关紧要的细节或者害怕其中的复杂度,倾向于让狂热的版本发行工程师去做此事。而那些带有重复和错误的构建脚本所导致的问题,与那些糟糕的代码一样需要严重。

为什么要自律的原因是,熟练的开发者会把构建器作为他们的第二要务。另一个原因就是构建不算是真正的“代码”。还有些现实情况要面对,大部分开发者喜欢学习新语言,而构建器是用来给开发者生成可执行文件的,以及终端用户用来测试和运行的。没有经过构建的代码毫无用处,构建器被定义为应用程序的组件架构。构建是开发过程中必要的一环,并决定了构建过程中能够制造的代码,以及更简单的编程。

用错误的方法编写的构建脚本难以维护,所以更重要的是,它需要被完善。花点时间去理解正确的方法以做出改变是非常有价值的。Bug会在应用程序采用错误的版本以来构建或错误的构建时间配置时浮现出来。

传统上,测试总是留给“质保”团队的事情。而现在我们意识到,边写代码边测试有很必要的,可传递出预测价值。因此,构建过程需要被开发团队掌握。

理解构建(原理)可以使整个开发生命周期变得简单并降低成本。一个易于执行的构建起也能让一个开发新人快速轻松地上手。构建中的自动配置也可以实现多人协同项目时结果的一致性,从而避免了“它在我电脑上运行正常”的尬聊。很多构建工具都可以让你得到一份代码质量报告,让你更快地感知到潜在问题。所以,花点时间了解一下如果制作个你自己的构建起,帮助你的同时也帮助了团队里的每个人。你也可以专注功能开发,让相关利益者受益,让工作更愉快。

充分学习你的构建过程,明白何时以及如何做出改变。构建脚本是代码。它们太重要了以至于必不可少。在被构建之前,应用都不算开发完成。在我们交付软件工作之前,编程任务就不算结束。

0%