有一段时间，我完全沉迷于在脑海中想象机械绘图和设计新机型所带来的极致享受，这是我一生中有过的最完美的精神愉悦。创造的灵感像泉水般源 源不断 地涌出，我遇到的唯一困难就是必须设法牢牢抓住它们。对我来说，构思中的设备零件都绝对是真实的，所有细节都触手可及，甚至最细微的标识和磨损状态也是如 此。想象发动机在持续不断地运转，仿佛一道迷人的风景呈现在面前，令我欣喜若狂。
                                                                                                        — 尼古拉. 特斯拉

看完上面这段特斯拉回忆录中的自述后，我们不禁惊叹于特斯拉超乎寻常的大脑构思能力。读完特斯拉的回忆录《被世界遗忘的天才：特斯拉回忆录》后， 我完完全全相信特斯拉是一个不折不扣的“外星人”，就是像克拉克.肯特那样被送到地球的“超人”。不同于超人的是他给地球带来的不是钢铁般的身躯和无比的 正义，而是超级智慧。他的所思所想所做所为完全超越了那个时代，甚至是当今的时代。作为程序员，我们不敢奢望能拥有特斯拉那样的超级构思力，但拥有一个良 好的构思力对于程序员来说还是蛮重要的。

【什么是构思力】

就我自己的认知和经验来说，构思力是一种“在大脑中构造事物的能力”，构造出的事物不是静态的，它在你的构思下不断演化，像是一部电影。日常生活工作中， 绝大部分人都是被动构造，当收到外界的输入时，包括影像、声音、感悟等时，在大脑中应激性的出现一些事物和场景。这种构思的持续时间很短，从长度上来说， 都是微电影，并且很难抓住并转换为现实，价值不大。真正的有价值的构思应该是主动、有意识、有目的地在大脑中构造。因此构思力常用于在创造、创作以及发明 的过程中，各个行业莫不如此。

【构思 vs. 设计】

构思与设计都需要经过脑力完成，甚为相似，难于区分，但个人觉得还是有些许差别。就就像特斯拉回忆录里描述的那种情形，我们称之为构思。构思强调事物从无到有， 都在脑中完成，是一种全脑演算。有时就是一个闪念，瞬间迸发出来，很迅速，并可被快速捕捉到，构思者往往会变得热情高涨，并在短时间内完成主体设计和实 现。构思往往一次成型，多用于整体或全局设计，是真正设计阶段开始的前置条件。构思过程会将事物的全貌在大脑中构造出来；将关键的技术难点在脑中完成突 破，形成思路；会将事物与外围接口在脑中进行对接；会对创造出来的事物在脑中进行初步的验证，证明其正确性。

设计则会将前期构思的事物分解并细化，落于纸面，或画出各种图形，多是渐进和迭代的；有时用作局部优化。

因此可以看出，构思是更高层次的设计。

【程序员与构思】

程序员的日常工作与创造关系紧密，而“创新”则离不开构思。哪些工作属于构思范畴呢？目前看来比例不多，在目前这个网络四通八达发达，搜索引擎智能强大的 时代，你要的解决方案基本都能在Internet上找到，只是将现成的方案挪到你的solution中，我觉得算不上构思，顶多是设计，设计如何将现有的 东西组合起来。

构思的结果是崭新的方案或是基于已有方案的优化改进，是有脑力参与的事物演化。但构思不是必须凭空创造，多是站在巨人的肩膀上，是个借鉴再创新的过程。构思有时候可能有“重新发明轮子的味道“，但重造轮子不一定不好。

构思可大可小，Linus Torvalds设计并实现Git、Matz发明Ruby等属于大构思，你将某个算法的性能提升20%可算作小构思。

在软件开发领域，构思不是技术领域专有的，业务流程或过程的创新都与构思不无关系。

Non-trivial的开源项目多是构思的结果。我个人在开源lcut, cbehave, buildc时也是深有体会的。当大脑中构思演化出目标图景时，人会变得极为亢奋，软件的主体架子在短短几个小时或一两天内就完成了。很多著名的开源项目也是如此。

【影响构思力的几个因素】

构思力高低要看大脑的活力。个人理解影响构思力高低的几个因素：

    * 脑部成像构造能力
      
        就像特斯拉那样，每个人脑部都有一定的事物成像能力，比如提到神舟发射，你脑中会呈现某种画面；再比如提到Google数据中心，你脑中又会出现何种场 景。当然这些例子还都是简单的事物还原能力。当提到让你改进神舟飞船或降低Google数据中心能耗时，你的脑中的画面会有怎样的变化呢？能否变化或能否 沿着对应的问题演化能反映出构思能力的高低。当然这是需要有领域知识、眼光和技能的。改进的神舟飞船与降低了能耗的Google数据中心是不存在的，需要 你使用纯粹的空想构造能力对其进行演进的。训练你的脑部构造能力，要求你日常勤于用脑，勤于思考，经常将各种信号输入（语言、声音、感觉）进行转换，在脑 中尝试成像，减少视觉信号的输入。记得小时候印象最深的一件事就是一边听着单田芳老师的评书，一边在大脑中构造对应的场面、人物形象和情节，我想这对我大 脑的构思成像能力是大有裨益的。

    * 知识与眼光的广博
       
        凭空的构思创造毕竟是少数，而多是站在巨人的肩膀上。这要求你对所属领域甚是是相关领域有一定的了解和认知，这样在构思时，才能如特斯拉那样思如泉涌，思想的碰撞火花四溅。这就像拍摄电影，需要在日常积累各种素材和技法，兼容并序。

    * 对问题域的透彻理解

        构思多是行业领域相关的，构思的结果都是隶属于某个领域或行业的。构思出的方案是为了解决一个明确的问题或满足特定需求，因此是否对问题有透彻的理解将直接影响构思过程和结果，以及你构思力的发挥。

以上关于构思力的论述感觉还不够系统成熟，仅是一些主观心得体会罢了，供参考并欢迎交流。

本文翻译自Dr. Dobb’s杂志主编Andrew Binstock的"Putting Absolutely Everything in Version Control"一文。

持续交付(Continuous Delivery)的一个关键原则就是将所有东西都放入版本控制系统中。这解决了一些重大问题，但也引入了一些其他问题。

持续交付是持续集成(CI)的一个自然扩展。后者旨在每次代码签入后运行构建并为开发者提供即时的反馈，而持续交付的目标则涵盖更广。它谋求在每 次代码签入后进行构建、测试以及最终可执行程序的部署（这里的部署针对的是测试环境，而不是生产环境）。这个想法保证了一个工程在任何时候都拥有 一个已知部署安全的可交付的应用。这个应用也许不是功能完备的，但却是可以运行起来的。

在一些拥抱敏捷开发的地方，持续交付正逐渐追上了持续集成的脚步，因为它在许多领域促进了最佳实践的使用，并消除了在部署过程中发现意外缺陷的问 题。它还使得团队熟知部署，让依靠传统手段进行部署所带来的那令人屏息的时刻成为历史。

把所有东西都放入版本控制系统(Version Control System, VCS)是对持续交付很重要的一个最佳实践。是所有东西，我说的的确是所有东西。这里引用一段对持续交付有着重要意义的文字：“当然，开发者应该使用版本 控制系统管理源码，但是也应该将其用于测试、数据库脚本、构建和部署脚本、文档、库以及你的应用的配置、你的编译 器和工具集等等。这样一个刚进入团队的新成员便可以从头开始工作了”。

这是一种激进的状态 — 我们中有多少人会把编译器放入版本控制系统中呢？但是，它解决了一个重要的问题：重建旧版本的软件，虽然这种情况很少见，但一旦出现，可能会给你带来很大困难。大 多数从事过编程维护工作的人都有无法重现一个缺陷的经验，因为任意一个工具的改变都会导致原先的二进制程序无法被复制出来。这种方法还给我们提供 了另外一个好处：可以保证每个团队成员在开发中使用相同的文档和工具。无需再担心海外的团队成员获取到不同的需求或使用一个更新版本的编译器等问 题了。团队中的每个人都是从同一口井里取水的。

然而，完成这一任务并非易事。最近在波士顿举行的Citcon(译者注：CITCON, the Continuous Integration and Testing Conference)上，这个话题就在一个CI爱好者的会议上被提出讨论。第一个问题是许多开发工具不只是一个简单的二进制程序和一些动态库，相反，他 们依赖OS库并且必须安装后才能正确的运行起来（尤其是在Windows上）。这个问题在某种程度上可以通过使用虚拟机来补救。在虚拟机上安装OS以及用 于自动化构建的工具，接下来将整个虚拟机签入到版本控制系统中。这种方式工作起来很好，不过它也需要你在虚拟机中构建你的产品，否则你需要建立两套独立的 环境，他们难免会不同步。（Linux和Unix受这个问题影响较小，因为它们没有注册表。上帝请保佑那些将二进制文件和配置文件放在同一个目录下的产品 的工具制造者吧！）

一个更隐蔽的问题是并不是所有的版本控制系统都能很好地支持二进制文件。例如，Git被设计成一个纯粹的SCM（而不是VCS， 译注：SCM，Software Configuration Management，软件配置管理系统），在处理规模较大的工程或具有大量二进制文件的工程时十分困难。（如果你将工具和虚拟机签入，从SCM角度来 说，你的项目将自动变大）。在这个领域，商业产品更加擅长。尤其是Perforce，它在快速处理二进制文件，尤其是大工程上面下了大量功夫。

另一个挑战是脚本中存在的密码。持续交付中的部署针对的是非生产环境，将密码留在非生产环境（即测试环境）下风险可能很小，这可部分抵消这个问题的影响面。对其它组织而言，对密码进行加密是可以提供的另外一个解决方案。

最后，我应该注意到即便上面提到的那本书（译注：指的是《持续交付》这本书）也是不推荐将构建产生的二进制文件放入VCS中的，这是有道理的。毕竟二进制 文件很大并且样式繁多。而将所有东西都放入VCS的重点只是为了能够在未来的某个时间点上重建出那些相同的二进制文件。

就个人而言，我不认为可能将每个项目的所有东西都放入SCM中。基于Linux的使用开源工具的工程最有希望达成这一目标。然而，我相信为了尽可能地接近 这个目标而付出的努力是值得的。它赋予你一种安全感：可以在任一时刻，回到过去重建旧版本的产品，并且所有人都基于同一个工具源上工作。在我看来，这些益 处要远大于其他原则引入的弊端。