第一次软件危机
1960前后，软件的第一次危机发生了。大家发现这个新生的婴儿开始不停的患病。症状具体表现有
1，工期延迟
2，费用超支
3，质量堪忧
4，难以维护
所以在1968年，计算机专家齐聚德国，提出了解决软件危机的办法“软件工程”。
软件工程
软件工程是一个非常弘大的主题，当时的计算机专家对软件开发活动进行了整体建模和抽象，从组织学，到管理协调交流，到设计和实施提供了完整的方法论。这个基本框架和很多设计原则，到今天依然有强大的生命力，难以突破。
软件生命周期
任意软件项目研发生命周期应该包含以下过程
需求
分析
设计
开发
测试
角色分工
软件寿命周期中每个过程都应该有一个或者一些列角色来承担
需求提供人员
需求分析设计人员
系统分析设计人员
开发，测试，运维人员等
他们通过开发方法来进行软件开发活动
开发方法论
开发方法是角色之间彼此协作完成软件开发方法的活动和约定，包含以下等方法
1，瀑布式
2，迭代
3，原型
等
交流工具
看起来非常完善了，但是专家们依然没有漏掉一个很细节的部分：沟通。
由于软件活动必然设计到多种角色，他们可能有不同领域知识，难以互相理解对方，软件专家们觉得有必要发明一门统一的语言让他们可以互相“顺畅“的交流。于是定义了UML语言（统一建模语言）来帮助软件开发的各种角色们进行互相交流。
UML传统上分为9中模型图，列举比较重要的有
1，概念图（对象关系图）
2，用例图（描述了概念对其他概念之间的功能）
3，流程图（打通了功能角度的对象关系和逻辑）
4，状态图（描述概念或者功能的过程状态变化）
5，时序图
设计
沟通当然很重要，不过和上帝沟通数千年依然不能产生牛顿，爱因斯坦们，专家们单独提到了设计。
在《人月神话》中，设计已经被提到一个非常重要的地步了。在软件工程中，它同样被认为非常重要。
这里要注意，作为沟通的UML和作为设计的UML是不一样的。因此在沟通阶段，UML关注的是用例，功能，流程。而设计阶段，关注的是概念，关系和状态和流程。
他们的本质差异在于抽象。
在沟通阶段，考虑的是具体的实物，业务。
在设计阶段，应该考虑的是抽象的概念，关系。
设计需要具有一定的通用性，扩展性，灵活性。
语言和工具
以上属于核心层次的问题。次要层次的一些辅助设施也是非常有益的。
比如：
结构化语言c就比汇编具有更高的开发效率（备注：第一次软件危机核心关注不损失性能的情况下，提升开发效率）
提供构建工具能有效降低开发人员机械劳动，提升开发人员时间利用率。
采用好的协作沟通形式也能提升团队效率
附：第一次软件危机和人月神话
在第一次软件危机时，具统计84%的软件开发周期有延迟，30%左右因为进度失控而结束；平均延迟190%左右，延迟数倍亦比较常见；费用自然是超支的，部分甚至超支一个数量级。
OS360是当时一个比较典型性的代表；1961年左右，IBM计划投入60亿美元（之前的曼哈顿计划20亿），软件开发动员了1700个开发人员，产生了5000人年的工作量也没有完成最初的计划。不过它却成为当时最成功的软件项目，可见当时软件开发之困境。
当然另外一个更重要却更不知名的代表是 Multics 。Multics 是64年贝尔实验室一个雄心勃勃的计划，Multics要做一个覆盖所有机型，支持多用户，分时操作，7*24小时可靠运行的操作系统。第一次提出结构化设计，分层设计，动态链接，全部采用高级语言PL等概念。 1969年，因MULTICS计划的工作进度过于缓慢，最后终究遭裁撤的命运 。
《人月神话》是Brooks主持Os360操作系统的踩坑大全和总结。Multics作为另外一个更大的坑所以死掉了，而有幸不为太多的人所知，不过作为Multics的反例的Unix，却从它的反面诠释了《人月神话》的正确性。
Os360用数千人年研发了一个不成功的产品，Multics更是遭遇失败厄运，Unix用几个人却创造了一个传奇——这有力证明了软件工程管理领域的一个基本原则：不能通过堆砌人力数量来进行进度控制。
为什么呢？
1987年Brooks在续作《没有银弹》一书中进一步指出产生人月神话的根本原因——软件的本质
一个相互牵制关联的概念结构，是软件实体必不可少的部分……
如果这是事实，那么软件开发总是非常困难的。天生就没有银弹。
为什么这会导致人月神话呢？作者进一步说
让我们来考虑现代软件系统中这些无法规避的内在特性：复杂度、一致性、可变性和
不可见性
……
我想到这里，聪明的读者脑子里基本已经想到了类似的场景：“链式反应和原子弹”
如果这是事实，那天生就没有银弹！
第二次软件危机
第二次软件危机的背景是计算机行业的快速普及和发展。有两个非常重要的因素：个人电脑和摩尔定义。他们分别对应了两个时代弄潮儿：微软和Intel。
由于硬件的发展导致软件爆炸——软件复杂度，体积，数量，开发人员都爆炸性增长。开发哲学也从更关注性能转变为开发效率，可组合型，产品性等。
每个人桌面上都应该有一个电脑
我们知道，计算机最初是为了破解电报和计算导弹轨道用的。最初的计算机是机械的，计算机像楼房一样庞大。随着晶体管的出现，计算机体积大大缩小，计算能力急剧上升。
但是在80年代以前，他们依然局限在非常小众的市场，当时IBM总裁曾经说过：“我相信全世界只需要5台电脑就够了”。这话在当时简直无比正确。
然而有人不这么想，因为当时用计算机要申请，排队。我们今天绝大多数触网的人简直不能忍受一天没有网络的生活。同样的，这对当时的计算机爱好者们简直难以忍受，于是有一些公司针对这部分消费者设计了所谓的中型机和小型机——盖茨等就是从这个时代第一代接触计算机的程序员。
事实证明计算机成瘾少年们的力量是巨大的。这第一代接触计算机的少年们不约而同开始做同一件事，乔布斯在车库里折腾出了苹果电脑，以一台数千美元的价格风靡了发烧友市场。这让当时计算机巨头IBM大为惶恐，然而衣冠楚楚而老朽的IBM西服们已经难以适应PC机市场牛宅裤少年的快速发展和创新，他们决定采取“驱狼逐虎”之计——设计并公开了PC机组件兼容标准给全世界的厂商，每个厂家只需要做一个零件，保证和标准兼容，然后拼装在一起就可以跑起来，这种机器被业界称为IBM兼容机。
最初的PC机当然和大型机一样是黑乎乎的（终端屏），可是随着（小白）用户的增加，计算机水平不那么高的用户多了起来，他们很难学习cd ls等难以记忆和操作的命令。于是桌面os和软件就流行起来。
兼容机市场的告诉发展，刺激计算机硬件行业高速发展起来。
影响计算机速度的最重要部件CPU，在80年代末有几个重要厂家Intel，AMD， Cyrix，IBM，威盛。当时速度只有几十兆hz，却以每两年翻一番的速度在快速发展。到90年代末，速度已经有几个G了。而内存大小，也从几M快速发展到上G。
PC市场快速发展起来了。
软件爆炸
桌面软件以前，软件体积常常是以K为单位计算的；程序员的大多数时间都在考虑几bit，几K的优化。而随着PC市场快速发展。软件的数量和体积都快速膨胀。
在Windows95时代最著名的《帝国时代》，已经有几百M的容量了（其中一半是动画，但真正的代码依然很可观）。
这个时候，以几个比特和几个k为单位考虑的Dos时代的软件开发模式，已经不能适应要求了，软件开发行业迫切需要低门槛，高生产效率，能规模化的软件开发工具链。
面向对象
组件化开发包含模块化，接口，SOA，面向对象等概念，名词虽然不同目的和原则都是一样——希望达成搭积木一样的开发模式。成功解决软件规模爆炸和生产效率的问题。
同样是面向对象语言，不同语言细节差异颇大，并且有类似原教旨主义一般的拥趸。不过我认为他最成功的特性当属封装和IDE友好。这决定了它的组件化能力和规模协作能力。
这其中最成功的当属Java。因为java是如此简单，可控，适合规模化。
面向对象概念是如此成功，很多语言都以标榜否纯粹OO为荣。但是也有人在反思OO概念是否有一些不足
在GUI图形界面展示领域（css+xml），在数据检索领域（sql），在字符串搜索领域（正则），在数据表达领域（xml/json），XX领域（dsl）……
随着分布式时代的到来，OO似乎展示了它天然一个死穴（也许不只是OO，而是整个冯诺依曼体系）：状态。对象天然就是有状态的——函数式语言头风一时泛起。（备注：大多数函数式语言如果不能解决状态存储问题，那么FP不过是一层语法糖，底层依然是OO。不过仅仅这层糖这已经能解决一部分问题）
这些最多算是宫廷内乱斗罢了，于大局并无影响，展望整个计算机软件市场，在组件化和面向对象技术加持之下，软件市场繁荣起来，各种软件技术不但走上桌面，更走近了企业，各种信息系统，管理系统，ERP系统纷纷成为多数企业的必备品。
等死还是找死
上世界90年代末本世界00年代初，企业ERP市场流传着这样一个让企业家们人心惶惶的谶语：不上ERP是等死，上ERP是找死。
时代潮流很明显——计算机的发展汹涌澎湃势不可挡，行业内势必大量采用计算机技术来提高生产力，这是一个试错的过程——试错了是找死，不试是等死。
使用一个软件就好像结婚一样，肯定不能说no。
但常常的结果就是在辛辛苦苦千挑万选一个心仪的媳妇，满怀美好奔向新生活的时候，发现奔向的是坟墓。当然更多的是本质良好的贤妻良母——可是任何贤妻良母都不可能完全满足我们的幻想，她总有这样那样的毛病；或者宁可说我们自己总有这样那样的毛病。它常常会给你小鞋穿，让你感受它的小性格，让你回忆没有她的自在；它常常限制你如何如何，束缚你不能顺畅自在施展才华；但是你也知道她有这样活着那样的好，不可能没有她，你离不开他。
——绍兴话说：旧社会不算苦，娶了媳妇才算苦。可是换一个媳妇代价高昂啊，谁知道新媳妇会不会更差呢？日志凑合凑合过吧。
弗兰肯斯坦
可是总有怀揣梦想的先生们：为什么我们不能结合各位妻子美好的部分，创造一个完美的妻子？
面对软件用户的痛苦，一些软件生产厂家提出了SOA的概念：每个软件提供的服务应该是开放的，并能通过彼此开放的服务整合起来，变成客户需要的软件。
这里我们必须再回到Java这条线上来。
Java是Sun公司基于嵌入式开发而设计的语言，由于公司市场地位的弱势，他们决定和其他Java市场巨头用户联合成立委员会制定标准的方式来发展Java。并且Java对普通开发人员是完全自由的，免费的。这营造了一个巨大的社区市场——这个社区包含了各种彼此兼容的，包含了大企业解决方案，社区的，学届的……各种各样的解决方案和零件。任何公司都能够通过付费甚至免费的方式从这个大集市中挑选自己喜欢的整体解决方案，甚至可以采取海鲜市场的方式——指定一些海鲜，自己或者由指定大厨烹饪。
在最初的时候，这个体系虽然包含社区但主要的组成部分还是大企业，社区的影响并不大，但是有一个核心的因素是标准和自由。
虽然制定标准的大企业是裁判也是运动员，他们往往会在菜加一点料，让顾客离不开自己；但有趣的是一些顾客也同时是运动员，他们试图做相反的努力，并且只要能符合标准就同时会被其他顾客采纳——这个努力发展到极致的时候，产生了一个Spring的开源胶水框架，他的哲学就是：（在尽量兼容现有标准，不做任何破坏性重建的前提下）能粘合任何东西，又不能被任何东西粘合（包括他自己）。这个框架彻底影响改变了整个Java软件市场——社区甚至普通人成为Java软件开发市场的主力，sourceforge，github等自由软件市场蓬勃发展。
Java最大的对手是微软。Java诞生之初微软就看到了Java的巨大潜力并大力投入到这个市场——当时微软实现的Jre应该是所有厂家里面最快最好的。不过他在这道菜里面加了太多料来保证顾客不能有其他选择，委员会决定开除他。于是微软另起炉灶写了Java的复制版C#。
C#几乎所有特性都比Java好，唯一的缺点就是它是一个完整的单一的体系，而Java是一个类似于弗兰肯斯坦的怪物——它只要立足于自由和组合，立足于社区就必然拥有无穷无尽的可能和力量。在最初Java体系玩家主要是大企业的时候C#尚且能够和Java世界平分秋色，在Java世界因为Spring而彻底改变以后C#就渐行渐远了。
第三次软件危机
第三次软件危机，本世纪初至今。背景是多核CPU，分布式计算，互联网+和物联网和人工智能。
由于硬件发展滞缓，以及软件开发进一步侵入各行各业和新领域，软件开发的复杂度和性能问题重新重要起来。
我们需要一种办法来解决软件的复杂性问题——也是人月神话提出的根本问题。
免费午餐结束了
过去二十年： 价格不变，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。
这意味着你写的程序，20年间没有做任何更改，性能提升1024倍。但是多核时代的到来意味着这种时代结束了。对于大多数的程序如果不做修改他们只能利用一个核。或多或少的，他们都需要通过一些改造来适应多核时代。
不过有什么关系呢？这只是一些技术上的小“乌云”，前线依然在胜利。
扩张！扩张！
00年前后.COM泡沫破灭了，科技股一时人人喊打。可是腐朽中孕育着新生。将来IT行业的巨大几乎都是在这个时期开始了自己的生命：google（1998），腾讯（1998），阿里（1999），facebook（2004）……
这几年企业最初都有点惨。腾讯创业之初曾经被马化腾几次出售，不过因为投资人看好，所以一直砸到手里，被迫成为亿万富翁。
阿里的情形也有点类似，他的竞争对手一直遵守传统的收费商业模式，而阿里坚持免费——这在当时简直颠覆人们的价值观——这样一直亏下去怎么也看不到头，所以少有人看好。
当后来他们砸钱砸死所有竞争对手，彻底垄断整个市场开始大赚特赚的时候——所有人突然之间全部恍然大悟，信奉曾经哪个被他们怀疑的事实——别管赚钱，越亏越好，开始拼命追捧那些传统意义上不被看到的企业——越不被看好越吃香。
“20年前，你错过了腾讯
15年前，你错过了阿里
今天，你不能错过XXXX”
互联网疯狂躁动起来：共享打车，共享单车，共享充电宝，共享雨伞，智能电饭煲，智能路由器，智能XXXX.....
从互联网到移动设备到物联网，从金融到物流到零售，从通勤，旅游，购物，家居……IT一时攻城略地
骑兵！八旗兵！！
为什么IT行业可以所向披靡，像蒙古大军那样看起来势不可挡，征服世界？
两个原因
1，接近零的商品成本和扩张成本
2，高度灵活和协同的组织架构
接近零的商品成本和扩张成本是软件相对于传统商品的固有优势。一旦软件研发成功，它几乎可以以零成本快速扩张，就像骑兵一样横扫一切。老一代以微软为代表的企业以此强势崛起。
这种特性导致在软件领域，不太可能存在太多的供应商——不是你横扫我，就是我横扫你。所以软件巨头们会拼命的扼杀一个个竞争对手于摇篮之中。
然后变化发展是如此之快，快到你可以可以做到起来一个扼杀一个，但是只要一个疏忽，就再也不可能追的回来。雅虎，google反复演绎了这个情节。
而这些新企业之所有能够让巨头们来不及反应，而巨头们也绝对不会因为掌握了“弗兰肯斯坦”的技术奥秘而变得无比灵活强大——一个原因是人和组织——这就是“大公司病”。
所以面对新锐们，提出了“让大象跳舞”的IBM只能选择代理人战争而不可能亲自上阵。情形很明显：一边是生机勃勃的牛仔裤们，一边是整整齐齐的西服职员们；一边看起来是变幻莫测的游击队，一边是组织严谨的正规军……甚至正规军士兵们是如此羡慕游击队们的自由自在的生活，痛恨严谨而机械的大公司流程，纷纷投奔新锐公司门。google，facebook一时压倒巨头微软，苹果。
这些新巨头们相对于旧巨头们，最大的差异是文化，是组织方式——同样是骑兵，前者是等级森严的，类似于传统企业的组织架构；后者更要宽松自由的多。
蒙古骑兵以前就很厉害了，可是部落纷争不能团结；直到铁木真改变了原始的部落组织方式，建立了薛却制度，蒙古骑兵才得爆发出骑兵的真正战斗力，横扫世界；女真人也一直有强大的战斗力，可是却只能为各游牧民族或者南方汉族压制，直到建立了八旗制度，才得以建立庞大的清王朝。共产党虽然比国民党弱小，走三反五反，四清文革，可是他的组织原则却非常先进，错误能快速改正道路更坚定；弱小不怕强大愈战愈强。某种程度而言，对人而言，组织力是第一生产力。
新巨头骑兵们，相对于后巨头，不同的正在于此。
可是不论是哪里的软件巨头，他们都必须克服游牧民族的天然弱点，防范其他骑兵们的猛烈扩张。在软件主战场外的地球另一边，激战更酣。
精疲力尽
“世界上有一种没有脚的鸟，它的一生只能够一直飞翔，飞累了就睡在风中，这种鸟一辈子才会落地一次，那就是死亡来临的时刻。”
——《阿飞正传》
中国的软件业曾经自称C2C行业，美国有什么，我们COPY过来就是了；曾经有一段时间，一些中国人常驻美国抄作业，看到什么就复制到中国，然后等待成功就可以了。
百度C2C谷歌，阿里C2C EBAY，腾讯C2C ICQ，新浪微博C2C Twriter，开心网C2C Facebook。
中国巨头们的成功，相对发源地美国的软件企业，靠的就是拼劲，狠劲。 这成就了BAT们。
于是接下来的战斗更加凶狠，共享汽车，共享单车，外卖……等市场更加残酷。
然而，似乎没有人看到战场已经越来越小了，战斗越来越激烈了。骑兵们发现战斗结束以后不会有休息的空间和时间，其他人看到你的弱点会立即上马冲杀过来。
滴滴和Uber战精疲力尽，他们决定和解，去找消费者找点补给；可是吉利，首汽，美团立即拍马杀到。
美团和大众点评杀的战精疲力尽，想喘一口气，可更凶狠的饿了么快速补位。
OFO和摩拜已经渐渐不支，可是督战队们告诉他们不能松懈，不能和平，不能停止——停止就是示弱，就会有更多秃鹫进场
开辟新战场
在滴滴，摩拜在红海里浴血奋战的时候，很多人已经开始开辟新战争了。
进攻传统行业：互联网+
进攻硬件：物联网+，智能硬件
战场越打越大了，可是我似乎已经看到了战争的终结。
软件的本质
我们之前提到过《人月神话》，并且作者从软件的本质角度论断
如果这是事实，那天生就没有银弹！
果真如此？
未必，如果软件开发的链式概念和变化本质决定了软件工程复杂性爆炸的话，我认为这种复杂性能否得到控制这取决于三个子问题
1，能不能将概念和概念依赖的数量控制到最低
2，能不能隔离依赖的层级，让只在有限范围内传播
3，能不能控制变化不发生，或者对其他概念和依赖关系无影响
如果1有解，问题会极大化简
如果2有解，链式反应的规模会得到控制
如果3有解，即我们将变化转化为不变，软件开发的复杂度将有可能保持在一个常量（至少是可控的）
问题1是有解的，我们可以通过抽象控制概念和关系的数量
问题2是有解的，模块化，OO，接口等技术会帮助我们控制变化的传播
问题3依然是有解的，工厂化，引擎化技术帮助我们化变化为不变
组织熵和工程熵
软件工程将软件开发分为几个关键的部分
1，步骤：软件生命周期模型
2，人和协作：开发步骤，角色，开发方法论
3，指导思想：软件本质和架构
上文《神话的终结》解决的是软件本质的问题。
但是解决软件本质并不是软件开发成功的充分必要项目。在《人月神话》中提到了巴比伦塔这样一个任务
1. 清晰的目标？是的，尽管幼稚得近乎不可能。而且，项目早在遇到这个基本的限制之前，就已经失败了。
2. 人力？非常充足。
3. 材料？在美索不达米亚有着丰富的泥土和柏油沥青。
4. 足够的时间？没有任何时间限制的迹象。
5. 足够的技术？是的，金字塔、锥形的结构本身就是稳定的，可以很好分散压力负载。
对砖石建筑技术，人们有过深刻的研究。同样，项目远在达到技术限制之间，就已经失败了。
那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？
两个方面——交流，以及交流的结果——组织。
越是庞大的问题，越是需要庞大的组织，越是需要交流——问题是有没有一种极端情况：因为一些原因，一个组织的全部能力，都花费在交流上了——那么他们必然不可能在项目上做任何功能。
物理学上将不能参与做工的那部分能量称作熵：我认为软件工程中也存在类似的情况——组织熵和工程熵。
组织熵：组织维持本身存在，不参与做工的那部分组织能量
工程熵：工程是作为解决问题的技术手段，工程手段也会带来一部分无效功，消耗组织总能量。
有没有办法尽量减少组织熵？
精品团队，或者减少组织人数。
有没有办法减少工程熵？
尽量用简单的的解决方案，不要进入过多效益不明显，可疑尤其复杂度难以控制的技术。
何去何从
第三次软件危机我们已经不能再吃免费的午餐了，硬件上发展决定程序员需要掌握更多的技能；另外一方面，主战场也不需要如此多的兵力，需要开拓新的战场。如果新战场容量不够，或者根本不存在新战场呢？
软件行业势必会走减员增效，减少组织熵和工程熵的路线上来。
扩军备战的时候可能已经结束了。
程序员是否能迎来新战场的胜利，或者兔死狗烹的；也许最幸福的是做一个永不落地的风鸟