构建一个持续交付是容易还是难？
如果从这个系列的第一篇看起，直至这一篇为止，我相信一个共识应该是：在技术上实现它非常简单
那一个简单又高效的方式，理论上是不是应该普遍存在才对，就好像我们想像下，今天的工业流程，有哪个厂家会拒绝简单高效有价值的流水线方式，回归到原始的全程人工操作？
除了极少数手工制作带有艺术及其它价值在内的以外，大多数都不会拒绝一个简单高效的方式。
那在编程行业，也就是我们行业，它是一个普遍的行为么？
或者这么问：
包括持续交付在内的好的工程实践，是普遍被接受并实施的么
答案显然是：不是，至少在国内不算是
本篇，从零到一，构建你的持续交付的最终篇，本系列其它文章为：
- 从零到一，构建你的持续交付流程（一）：一个持续交付流程的构思
- 从零到一，构建你的持续交付流程（二）：好的工程实践是必要的前提
- 从零到一，构建你的持续交付流程（三）：搭建基于Jenkins Docker的持续交付环境
- 从零到一，构建你的持续交付流程（四）：利用Docker，将服务容器化
- 从零到一，构建你的持续交付流程（五）：使用Jenkins Pipeline，让交付流程与自动化
- 从零到一，构建你的持续交付流程（六）：让你的持续交付闭环
易
从持续交付这个实践来说，技术上，它实际一点都不难。
这并不是一个特例。
事实上，自有编程这个行当以来，发展至令也有约近70-80年左右，从最开始的卡带编程到如今的现代语言，从少数精英才能完成的事情到如今虽有一定门槛，但只要稍加学习，基本没人不能用现代语言来编程的地步。
整个行业的发展是实实在在的突飞猛进。
这当然包括了各种理论及实践。
就拿持续交付来说，今天一个程序员来做这个事，可能和十年前，二十年前来做相比，简单太多了。我们现在有开源的Jenkins，它专门就是做持续交付，做自动化的，还是开源免费的产品与工具，你甚至都不需要花钱来购买这个工具。
以此类推，在技术行业，开源已发展到如今这种规模与地步，各种语言的生态，开源的工具及框架，应有尽有。
一个显而易见的事实是：
今天，在技术上推行一个好的工程实践，不存在任何阻碍
如果从这个技术角度来说，今天，几乎任何一个好的工程实践，从零到一，易。
难
但就如我所思考的，包括持续交付在内的好的工程实践，是普遍的行为么？
应该不是普遍的行为。
这个基本上大家也能感受到，举例说明，TDD测试驱动开发这个，就国内环境而言，有多少程序员是自觉的去这样做的?
Robert C.Martin在它的书中在说到TDD时，第一句话是：关于TDD，此事已有定论，无须争议
持续交付也是如此，它当然是有价值的，做这么个东西也不难，为什么没有成为普遍得到大家认可的？
在国内，我认为好的工程实践得到普遍认可与尝试的可能就是敏捷软件管理方式，虽然可能实施上不一定对，也很可能走偏，但至少大家都认可这个方法论，就是敏捷软件方式显然是好于过往的瀑布模型下的管理方式等
至于其它的，则基本没有与此相同的待遇。
比如测试驱动开发，代码审查，持续交付等类似的，不仅仅是在管理方面存在争论，甚至这其中很多在程序员群体中本身都存在较大争议。
推行类似的做法，在国内非常具有挑战性，其一不一定能得到管理人员的认可，光是写单元测试会影响一个功能的时间这个事在管理人员那就很难得到认可。虽然事实上，写单元测试最终可以大大减少时间，提升效率。其二，这些事情本身开发人员都不一定愿意接受。
无论是从管理文化，还是技术文化上，推行类似的做法可能都具有一定的挑战与难度。
所以，如果从现实的角度来看，从零到一，难。
触动
在这一点上，最触动我的是我在读敏捷整洁之道这本书时，Robert C.Martin讲到敏捷整洁之道是怎么来的过程。
在敏捷软件开发之前，流行的是瀑布软件开发模式，也就是先尽可能做非常完美细致的设计，最后才写代码，写代码一定要按照事先设计的来，不能随意变动。当然，这是一个非常糟糕的方式，至少对编程来说。
因为发现行业存在的困境，老是开发不出好的软件，于是在2001年，十七名软件开发人员在犹他州的雪鸟度假村会面，讨论一个议题：
为什么编程如果糟糕，怎么才能改进
最终 ，这群人经过讨论，得出了一个宣言，这就是敏捷软件宣言。
- 个体与互动，高于流程与工具
- 可以工作的软件，高于面面俱到的文档
- 客户合作，高于合同谈判
- 响应变化，高于遵守计划
也就是右边很重要，但左边更重要。
这就是敏捷软件开发的来源，今天，这个方法论已经可以说成为大多数软件开发的标准方式。
这个事对我的触动非常大，从文字中都能感受到他们是在真正直面问题并讨论解决方案。
而如果我们认真观察，今天几乎在技术上的基础理念，方法论，语言，框架几乎绝大多数都是国外程序员努力的结果。
在这一点上，我们的确相差太多。
我们
国内互联网行业经过数十年野蛮发展，那种不管三七二十一，不管好坏，先出东西，抢占市场，做大估值的方式，我认为在过往的确非常有效，在过去国内互联这种环境下，可能谁跑的快，谁就赢了。
但我个人认为，在行业发展到今天，野蛮发展的阶段可能已经接近尾声，是时候到了开始重视好的工程实践及如何更好的提升编码的质量与效率这个事情上，而不是像过往一个依靠大量的程序员及大量的延长工作时间来解决问题。
这可能是我们这一代程序员的责任。
当然，我们也不需要自大到这种地步，觉得自己一个人可以改变什么。所以，我个人原则就是:
立足自我，影响周围，辐射远方
先从自我做起，自己坚持好的做法，这样就足够了。通过自已来影响周边的人，如果能写点文章，传播的更远一些，自然就更好了，但这些并不需要强求 ，能做到就能做到，不能就不能，没有关系，只要自己能做到，就问心无愧了。
这就是微言码道的初心所在。
努力让更多的程序员都受到启发，并不是让大家做跟随着，而是希望大家能受到启发，自我思考与尝试好的方式并形成经验与价值，而后又能将自己好的做法传播开来，这就是微言码道的初心。
所以，微言码道的口号是:
用我们微小的力量传播编码之道
