配置管理之构建管理(4)

怎么能提高研发的效率呢？快速的编译构建出产品绝对是最有效的措施之一。

急速的构建速度

再快的构建速度研发人员都不嫌快的。我现在代码写好了，想验证下是否修复了昨天的 bug，所以想把产品编译出来，部署上，看看效果，结果编译一遍让我等上几个小时？你说还怎么让我干活。提交两行代码，构建两次这一天就过去了。

研发人员可以忍受的构建时间是多久？有的说是1分钟，有的说是10分钟。我觉得绝对不会超过15分钟。

怎么才能做到急速

• 奢华的构建环境。
  能用硬件解决的问题绝对是最省钱的。买能承受得起的最高配服务器。
  当下应该可以做到48core 256G Mem 8T HDD。甚至把硬盘换成 SSD。看到有些公司还在用研发人员使用过的台式机构建产品，我就着急。改代码、编译、验证、有问题再改代码，这是一个闭环的过程。对于研发人员这个闭环，一天之内不知道要跑多少次。如果每次可以为研发人员节省10分钟，一天按照6次来算就是1小时。我们知道虽说工作时间一天是八小时，但是一人能干6个小时就已经相当高效了，毕竟人不是机器。那么一个月下来能为公司节省了多少成本呢？相当于提高了1/6的工作效率。
  • 一个月21.5天
  • 工资假设为 Salary
  • 节约的成本为 Salary/21.5 *（1/6）
    对于北京的研发工程师来说，月薪 1w 绝对不是高薪。我们以月薪 1w 来计算，人力成本大概是 2w/月，每个月就能节省 3300。这还仅仅是一个工程师，公司那么多的研发都算进来就可以意识到我们是多么应该换成高配的服务器了。

优化网络拓扑。把所有构建所需的资源都直连到最快的网络上，最好在同一个机房。能把构建环境放到1G 的网络环境中，就不要塞到千兆网卡的交换机上不要让构建过程请求告诉网络之外的资源。

• 模块化。分而治之的理念绝对是提速的好办法。
• 并行编译。把拆开的很多不互相依赖的模块并行编译，利用好多核。这样构建时间就取决编译最长的那个模块了。
• 缓存。没变化的部分就没必要重新构建了。
• 云构建。本地环境一般都是资源受限的，无论是 CPU、内存、SSD，还是网络速度。但是云构建没这个限制。而且云构建更容易做缓存、资源利用更高效。

小结

能用硬件解决的问题绝对不是最难的问题。如果构建服务器硬件差，就赶紧把公司里的服务器换了吧，换构建服务器绝对是在为公司省钱。当硬件达到一定配置依然无法缩短构建时间的时候，再来细细的优化产品的架构、构建依赖、构建过程等。这些每一步都是细致的活，需要花时间和精力去做，但是这个工作绝对有意义。