识天地本心、教生民立命、为往圣传道学、为万世谋太平。
但是，读着读着，味道就不对了，准确的说是从这一句开始：“拥有创造力，意味着你人生中遇到的最大障碍不再是技术的难题，而是人类的愚蠢。你人生最大的错误，是低估了这种愚蠢的力量。”
接下来，王垠的文章完全可以说是“夫子自道”，却未必是创造力的真正含义了。
其实王垠的经历相当“坎坷”，而这些坎坷经过他的自我化解，全部变成“源于智慧与愚蠢之间的鸿沟”了。
说一句稍微不恰当的话：“其实我很能够理解他，因为我也经历过那样一个阶段。”
后来，我才渐渐的体会到，创造力，不仅仅是产生新想法的能力，还包括实现新想法的能力。不仅仅是单打独斗的能力，还包括与人协作的能力。人与人之间的沟通协作，向来不容易。而最大的困难，就是将相互不理解，归结为对方的愚蠢。
创造力，说到底还是结果导向的。没有成果，你的创造力就仅仅是空想而已。
每个行当，都有自己的「行话」，同行之间交流，会有很多的省略。比如咱们这些软件开发人员，经常会这样交流：「最近在做什么项目呀？」、「我们那个项目压力好大啊！」
「项目」在软件开发领域，是最常出现的一个词。这个词背后，通常包含以下假设：有一个总的项目目标，这个目标会被层层分解为一个一个具体的任务，然后这些任务将会被逐步完成，最后项目结束。
其他的工程领域，倒真是这样，但是在将工程概念移植过来，变成软件工程以后。有些情况，就发生变化了。
1. 研究与开发协作并进的探索历程
很多时候，我们会下意识的使用「研发部门」、「研发人员」这样的词。但是我们在使用的时候，往往会忘记「研发，其实是研究(Research)与开发(Development)」的缩略语。
软件开发这个年轻的领域，还存在太多需要研究的东西。甚至不能简单的认为这是一个「研究–>开发–>研究」的交替过程。
我们会在研究的阶段，采用各种开发的实践来做辅助；也会在开发的阶段，进行多种研究：那种方案是否可行？有没有更好的选择？那种实现是否存在漏洞？需求真的是这样吗？
我们以为的研发循环；
可能比上图所示，更加复杂的研发循环。
2. 开放性与变动性无处不在
软件工程，有一个很神奇的封闭性(稳定性)假设：稳定的需求+稳定的团队+稳定的技术+稳定的外部环境==>稳定的结果。
然后，一切与这个封闭性假设不符的情况，都被打包归入（风险）的范畴。而所有的风险，只有两个办法来对付：预防、规避。
但是，这个假设本身就是错的。需求在变化，团队在流动，技术在发展，环境在改变，这一切不能仅仅视之为风险了事。不能老想这躲避、或者阻止。
敏捷宣言当年的一声大吼：拥抱变化！实在是振聋发聩！但是，仅仅拥抱变化，也是不够的。
3. 所谓「精益」
最有一个词，开始流行「精益（Lean）」，为何这个词开始流行？为何我们又开始信奉新的「银弹」了呢？
这个图，看起来是不是很神奇呢？其实，如果是科研人员，会觉得毫不新奇。大多数「日夜探索未知」的科研人员，他们的研究方法，通常都是这样的：有了一个创意，先做一些原型，然后验证并修正自己的假设。
这并非特别了不起的创新，只是大家越来越意识到：
<未完待续>
在知乎，我常常会感受到某种“满满的恶意”。虽然，我还远远不是直接被恶意击中的那些人。
戾气越来越重，粗鄙越来越浓，认真越来越少，长篇大论的争吵倒是随处可见！
所谓的应对办法，我想有三个，都是从知乎官方的角度出发的，因为个人其实无能为力。
@黄继新，你们看靠谱不？
已经有那么多人聊过了，在我的朋友之中，都已经有@Fenng@池建强@范凯三位大牛聊过了~~ 是不是太晚了？
其实不晚，这么有趣的话题，现在聊还不算晚。先看两则新闻
在这两则新闻的前后，是铺天盖地的两类文章：
当然还有贬的：
各位看官，晕了吗？说说我的观点吧：
基于人际关系，能够产生多少合法与非法的金钱往来啊！想想我都觉得激动！
我在这里恶意的猜想一下，那些所谓的负面批评，只怕是腾讯公关找人放出来麻痹马云的吧？要是阿里和支付宝真的觉得微信红包没啥威胁，那就等着1~2年后哭去吧！
软 件工程这个名词，背后的「工程学隐喻」，是错误的。我现在更愿意直接称之为「研发」—— R&D 。研究与开发纠缠在一起的研发管理，较之普通的工程管理、项目管理，复杂了千百倍，也因此异常困难。从传统项目管理、工程管理中生搬硬套过来的各种方法 论，往往对于研发管理利害参半。只有在对研发活动进行深入研究的基础上，分析研发活动的本质模型，才有可能接近「真相」，才有可能找到真正的规律与适合的 方法论。
过去常说的软件项目铁三角：Time（时间）、Scope（范围）、Cost（成本），应该进化为研发管理的铁三 角：Schedule（调度）、Requirement（需求）、Profit（利润）。区别在于：我们应该从企业级的角度，而非一个孤立无援的项目组的 角度，来分析研发行为。
而所谓研发管理铁三角：并非简单的非此即彼的困难选择，而是在需要做出选择时，研发企业的取舍能力。
错误的研发实践，会因为片面追求某个目标，导致对其他目标的损害。简单举两个例子：过度追求创新，可能损害项目的调度控制能力。过度追求研发速度，可能会损害项目满足需求的能力。依此类推，以上的六个方面的错误追求，都会产生种种恶果，这也是研发铁三角的另一种表现形式。
从一个整体来考虑企业的研发管理，应该注重建立一个良性的循环：
过去的软件开发方法论，往往只是注重了研发管理中的一、两个方面，缺乏整体视角。而且期望以一套方法论包打天下。事实上，真实情况下的研发管理，需要至少三套方法论：
研发企业应该建立的一个评估、改进、调整的大循环。评估：关键在于标准的建立，包括量化的标准与非量化的标准。改进：以符合标准的方式，不断改进。调整：再次评估改进的效果，并调整评估前制定的标准是否合理。
以上就是我的这篇大文章的核心观点，我将尽快把这篇文章完成，敬请期待。
以下是我的回答：
人的时间是有限的，用于思考的时间更加有限。
遇到困难，用于解决困难的时间，当然也是越短越好。
因为资料难找，没有网络的年代，人们还要骑自行车去图书馆借书。
在没有图书馆的年代，人们还要四处打听，找人借书。
在没有印刷术的年代，人们借到书以后，还要尽可能抄写下来。
抄写能够练习书法
借书能够联络感情
骑自行车能够锻炼身体
通过google一时间搜不到资料，我们还可以“学到10个以前根本不知道的新知识，而这些新知识将会促成下一个拉风的项目”
这些都是“副作用”，因为效率低下我们付出了额外的代价，当然难免会有额外的收获。
在解决困难的时候，能够迎难而上，甚至乐在其中，自然是乐观主义的体现。
但是，反过来说：太方便了，让我变懒了，让我变蠢了。这样不好吧~~
要解决问题，就快速解决问题。StackOverflow是个好地方。
要学习新知识，就去学习新知识。可汗学院这样的网站是个好地方。
网络时代给我们带来那么多好东西，善加利用就是，反而还要抱怨岂不是太奇怪了？
这个标题，各位看官一看，只怕就会有所体会吧：又是一篇无主题变奏型散文了。
好吧，我承认自己因为各种所见所闻，各种联想与思考，打算写一篇形散神不散的文章。
昨天在路上开车，正好听到交通广播电台的主持人，在介绍自动驾驶汽车，然后介绍这个创新背后的三大支撑：智能导航软件，移动互联网，大数据分析。
我听着觉得很有道理，于是联想到了最近了解到的关于DevOps的一些内容：尽一切可能自动化，Everything as Code，持续交付，虚拟化与云计算。
再进一步，又联想到了之前听到的关于SDN（Software-Defined Network）甚至是更夸张的SDE（Software-Defined Everything）。这背后的技术依然是：虚拟化，云计算，Evertything as Code。
当信息技术的大潮席卷全球的时候，我们在各种创新的背后，都发现了一组似曾相识的身影。
拿这四种技术去分析：医疗（基于云计算与大数据分析的医疗）！教育（基于云计算与大数据分析的互联网教育）！开源硬件的创新大潮（基于可编程组件与移动互联网的硬件）！
值得一提的领域还有很多，但无非是这四种技术的排列组合罢了。那么，用这个视角来分析IT研发领域本身呢？
DevOps自然是应用了其中的（Everything as Code、Cloud），比如Vagrant、Puppet、Chef之类的工具可以作为代表。但是：
从以上的分析来看，给全人类带来福音的信息技术，还没有足够好的造福自己。值得创新的领域，还很多很多！
从Linus抨击Github说起：托瓦兹抨击GitHub：某些功能很垃圾
开源，是一个很神奇的事情，Linus在开发Linux的时候，受到的最大的指责，就是质量控制不力。但是，Linus对此并不太在乎，还发明了一个Linus定理：“足够多的眼睛，就可让所有问题浮现”（given enough eyeballs, all bugs are shallow）；
开源的精神本质，可以认为是一场不收门票的盛宴，任何人都有机会参与进来。当然，质量因此而下降，也是必须解决的问题。
从集中式代码管理，到分布式代码管理，是再一次的降低门槛。开发者不依赖于主库，就可以创建自己的分支。我的代码就算原来项目的人不接受，我也可以继续搞下去。分布式的核心，是去中心化。去中心化的本质，是否定权威。不过，去中心化导致的，是质量控制更加困难。
当然，Github基于git，将去中心化，几乎做到了极致。将参与开源的门槛，几乎拉到了最低点。从Linus这位发起了两次降低门槛运动的“革命老人”来说，他对于第三次降低门槛的行为，受不了了。
很多时候，我们都会在历史上，看到这样的现象：革命的旗手停下来了，不再继续前进了。他喊道：够了，再这样下去，就是错的了。但是，后来者依然再继续前进，并且走得更远。
回到技术问题的探讨：为了保障质量，回到权威主导的中心化模式，当然是一个办法。但是，有没有更好的办法？
topgit，gitflow，是针对git的功能扩展。
hubflow，是基于github的gitflow。
repo+gerrit，是不依赖github的协作模式创新。
http://gerrithub.io，是基于github的gerrit。
更多的工具，正在层出不穷，更多的创新，还在源源不断的涌现。
我想：向前看，才是合理的方向。
每逢遇到热点问题，总会有无数的人冲上去发表一些这样、那样的观点。例子就不举了，就说这次12306的问题吧。
这已经不知道算是第二季还是第三季了。反正又开始了新的一轮「热议」。
但是，这就12306的问题，究竟是什么样的问题呢？
这是一个民族习俗问题，12306年全年运行，平时几乎从来没人骂，一到春运期间，就会开始有人骂，作为人类历史上最大规模的迁徙运动，在将近40天里，有30多亿人次的人口流动，占世界人口的二分之一。在这种习俗的压力之下，12306被骂，几乎是必然的。
这是一个政府垄断的问题，12306不是一个商业网站，而是铁道部的官方唯一指定网络售票网站。12306体验不好，铁道部就必须挨骂。谁让你是政府，是垄断，是不公开，不透明，暗箱操作。天知道你是怎么开发的，怎么招标的，怎么花钱的？
这 是一个复杂的技术问题，从技术角度来分析讨论12306的文章，已经有无数篇了。大牛、中牛、小牛，以及很多自以为有点心的菜鸟，都跑过来议论纷纷。对 了，还有一个开源项目呢，12306NG，建了一个 BBS和 N 个 QQ 群，一群人在那里群聊，代码倒是没有写多少。
———————以上这些，其实都不必看———————
其实，12306的问题，是一个工程问题。说得高大上一些，是一个复杂的系统工程问题。
在说得直白一些，这种复杂的系统工程问题，根本不可能通过开源项目来解决。
有人说，Linux 复杂吧，人家也是开源项目呀。
但是，Linux 的发展，是被用户百般呵护，万般宽容着的呀！因为是开源，所有各种 bug 都被容忍着，大家以爱的眼光看着 Linux 的茁壮成长，哪怕出再多的问题，都不能允许别人诋毁我们的小企鹅。
12306，能有这种待遇吗？12306ng，就算他真的开发出来了，开始上线运行。只怕第一天，就会被人骂到死！
这是一个错误几乎无法被容忍，甚至会被放大1000倍的项目，这种工程，该怎么做？
一个不允许犯错的项目，该如何尽一切可能保证其质量？中国99.99%的技术人员，都没有任何经验。只有那些当年开发两弹一星，近年来做的众多航空航天项目的工程人员，才算是有经验。
那些上来就「侃侃而谈某种分布式方案」的朋友，我只能呵呵一下了。
一个复杂的系统工程，首先需要考虑的是：质量，其次，需要考虑的是分工。假设给你1000个人，你会如何给他们分配工作？人月神话说：「不要假设一个项目中，工作量的人与月是可以互换的」，那么，出一个问题考考你：「12306的项目，要一年内完成，你需要多少人？」
1000？2000？还是5000？
不要说5000人，一个1000人的项目，如何管理？有哪些可能的问题？他们的协作，应该用什么工具？应该分多少层级？分别找哪些人，把他们安排在什么位置？
那些宣称「只要几十个人，就能够搞定12306」的朋友，我只能再次呵呵一下了。
质量、分工，之后是计划。一个如此复杂的项目，应该划分为几个阶段？每个阶段做哪些事情？如何制定层层分解的项目计划？在这样的一个计划中，哪些是关键节点？哪些是风险节点？如果出现风险，后备计划是什么？应急预案如何做？
那些宣称「可以敏捷迭代，然后就没有具体方案」的朋友，我只能再次呵呵一下了。
———————以下是总结陈词———————
很多人说：「没吃过猪肉，还没见过猪跑吗？」
但是我要说：「只见过猪跑的人，你不要相信他对于猪肉味道的猜想！」
如何评价一年多前沸沸扬扬的12306NG开源项目？现在是失败了吗？如果是失败了，能从中获得什么教训？在以上的这个回答里，我说了一段话：
那个基于 GitLab 二次开发，界面搞得很像 Github 的 CSDN Code，最大的创新，就是在每个项目主页下面，都加了一个评论区，一堆人在那里说：「好厉害啊！」、「加油！」
而原版的 Github，则根本没有这种东西。
我写这篇文章就想仔细聊聊：为何CSDN的「创新」是错误的？
何谓Social Coding？
自从有了Social networking service，似乎任何网站，都想跟社交搭上关系。但是，一个开源项目托管的社区，应该如何社交呢？
Github给出的答案很简单，Social是为了促进Coding。换言之，如果某种社交行为，对于促进更多更好的Coding，没有帮助，那么这种社交行为就是没有价值的。
在Github上，每个Repo上都有一个star，类似于微博的点赞。这对于开源项目的作者，有一定的激励作用，更重要的一点，通过简单的点赞，Github可以统计Repo受欢迎的程度，以方便挑选项目的用户参考。
当你对项目有些疑问，你可以提交一个issue，自然会引起项目成员的关注，然后围绕实质性的问题，展开有效的讨论。
而在CSDN Code，搞了一个类似BBS的评论区，结果呢？一堆对于Coding并无兴趣的人，跑过来喊加油。没有仔细读过代码的人，就来喊看不懂啊，不明觉厉啊。还有遇到问题的家伙，不去提交Issue，也到评论区里来抱怨，不能用啊，怎么办啊？
然后的，点赞的人少得可怜，提交issue的人少得可怜，更不要说fork与pull request了。
这样的热闹与社交，毫无意义，因为对开源项目没有帮助。
对国内做开源托管平台的朋友喊两句：
在国内要做成开源社区，真的很难很难，因为愿意实际为开源项目写代码的人，太少太少了。开源项目托管，注定是慢热的项目，但是还是千万不要去追求热闹，不要去「凑热闹」，更不要去「制造热闹」。
PS：
下面这个地址，有兴趣的朋友也可以点过去看看，小心闪瞎眼：