云计算恐怕是近些年最被低估了的技术。
周五在办公室听徐昊又提到了他的这个论断。这是我在他的文章里，他在技术雷达峰会上，再一次听他提及类似的观点。
在持续交付中构建流水线，这在如今大一统的敏捷开发中，已经是再显而易见不过的事情。我们却恐怕遗忘了它之所以诞生的前提条件也即约束：虽然区分开发、测试、验收、产品环境很有必要，但建立它们具有繁复的成本。从而借助（机器生产）流水线这个隐喻，异变的代码作为动态的成分，流经固定不变的机器即环境，以达到持续交付的目的。
而云计算的运用，恐怕不应仅仅局限于环境方便被创建和销毁的狭隘认知。
自然可以利用云环境的特点，通过脚本，轻易对环境实现创建和升级（Provisioning），进而实现同一套环境在开发、测试、验收、产品属性之间流转。这时代码无需再像流经流水线上的半成品。代码和所在的环境，因需而发生面貌上的转变。自然，环境的伸缩和复制也不再是问题。
我想，恐怕还顺道解决了我们摇旗呐喊致力于，却从未实现的开发和产品环境一致性的问题。
我个人一时间难以完全照单全收他的想法。毕竟以我的了解，对于在开发的软件，我们不止会有开发者（个人的能力还会有高下之分），还会有业务分析师，测试人员，设计师，客户的区分。单一的环境，必然会和团队分工以及一致性（木桶原理）之间，有说不清道不明的牵扯。
但我想，这也许并不是最重要的事情。重要的是，他对于此类问题推向极致的思考意愿，这才是最难得的部分。以他的被我称之为“极致的理想主义”的推论，对于做为隐喻的流水线，以及建立某种未来的开发和交付流程，都会产生莫可名状的影响。对于这点，我信服。
毕竟，我们不断演化而来的开发流程，都有其存在的合理上下文。在当初的约束受到新的技术冲击，不再具有充分性的时候，变革就是迟早到来的事情。
我喜欢并信任这种追求极致的思考方式。推断、猜测、论证、预言，在这向极致探险的过程中，彼此交叉印证。
如果说敏捷之于个人需要承载并弘扬的部分，不过如此吧。
作为敏捷方法族中众多轻量级方法，为什么XP（极限编程）会少有人问津，而Scrum会显得手到擒来（事实上也只是照虎画猫）？我想我们多数人恐怕并不太情愿做疲惫的推向极致的思考。更多采用一个“差不多就行”的态度，硬件的摩尔定律足以消弭掉算法和流程上的低效。
