持续集成，把时间留给编程

某天上班的时候，我回想起以前工作的经历和看着手头正在做的事情，脑袋里面突然冒出来『持续交付，可靠交付』这八个字（后面经过更加多的思考和阅读书籍，应该是『持续集成，可靠交付』更为准确）。

持续集成

为什么会突然冒出这个想法？因为我现在的工作 iOS 开发，在测试阶段，每天都要花费大量的时间在打包app 和上传 ipa 文件到 iTunes Connect 中。打包的时间长就不说了，特别坑的是公司的 iMac 电脑只要选择上传文件到 iTunes Connect 中，WiFi 就会断掉，导致每次打包上传的时间都是半个小时到一个小时不等，严重的降低了工作效率。

在醒悟的那天，我立马把手头的工作放下，开始寻找iOS自动构建的方法，很幸运的是在我寻找资料的时候，刚好有很好的教程出来，于是按照别人的方法，再结合自己的情况把持续集成的环境搭好了。从此告别繁琐的手动打包过程，能够不被打断的写代码了！一劳永逸！

在以前，我想将 app 提交给测试人员进行测试，通过手动打包和上传的方式将 app 上传到 Testflight 中（还需要忍受 Testflight 可能上传和审核失败的风险），一天操作一次就已经心累。遇上一天测试比较频繁发好几次版本的时候，就不用干活了，直在那里跳脚。现在，测试人员只需要告诉我他的手机的UDID，我只需要将udid加入证书中。在我将代码提交到服务器后，构建服务器会自动进行打包，并将 ipa 文件上传到第三方服务平台 fir.im 上，再通过 BearyChat 通知到开发组的每个成员，整个流程一气呵成。

作为程序员，编程就是为了将繁琐的人工操作交给机器，相比与人来说，机器更加耐的烦和失误少。将繁琐的重复的工作交给机器去执行，一是比人工操作更加准确，二是提高工作效率。于是在编程的过程中，为了更方便的开发，又出现了一系列为编程而生的工具，git就是个例子。

我经常在微博上看到像一些有名的公司可以让用户毫无感觉的一天发布线上代码好多次了，如果让程序员每次手动去发布，应该是一件很难完成的任务。其实持续构建这个概念是很多年前就有提出来的，只不过看团队或者个人的需求或者知识面是不是需要去使用，毕竟会『偷懒』的程序员，工作效率会更高一些。

单元测试

说到持续交付和可靠交付，要保证线上的代码是没有错误的，少不了测试。然而现在很多企业都提倡 DevOps，也就是开发运维一体化，在没有测试的时候，通过单元测试是有效验证代码是否正确的一个很好的方法。但是，在很多公司，并没有写单元测试的习惯，有写单元测试的时间，代码早就写完了。其实这个想法是不太好的，程序员不应该在拿到需求后，没有经过思考就动手敲代码，这是很多人都会犯的错。因为没有思考，机械的写代码并不会带来什么提升，而是会写越来越烂的代码。有时候，给代码写单元测试也是一个思考的过程，会去想一些边缘测试条件，其实是有帮助的，能够更加全面的思考问题，带来更加稳健可靠的代码。

但是，一直非常困扰我的问题就是单元测试的代码该如何写？如何进行单元测试？怎样的单元测试才是有效的？这是我接下来的时间将会去探索的一个问题。

总结

在以后的编码生活中，我将会将一些工作交给机器来执行，而不是靠人力来做，会去探索一些更为有效，工作效率更高的工作方式。