说到软件工程很多人都会想到瀑布模型、敏捷开发、领域驱动。虽然这些名词大家耳熟能详，但如果你去听大牛们的讲座或者查阅相关资料会发现每个人陈述的都不大一样。这让听的人很迷惑，为什么大家讲的不一样但是又都很有道理？
软件工程这门学科发展不过几十年，很多概念还在不断演化，定义也比较模糊。在项目中使用这些方法非常的灵活，比如引入SOA架构，如果完全按照SOA的规范来做不一定适合自己的项目，但是不按规范来做又容易遭到质疑。于是基于SOA修修改改，如果项目结果丰硕，还可以说自己用的是微服务架构。虽然在不同项目中推进软件工程方法的过程不同，但最终的结果大多是好的。
随着互联网的发展，新的软件工程方法论会层出不穷，未来会出现更多新词，但唯一不变的是思维。无论是SOA架构还是微服务架构，都是为了解决软件工程的根本问题『沟通』，下面聊聊软件开发中一些有意思的规律。
一. 沟通成本 = n(n-1)/2
记得在《软件工程》中有一节专门讲了 “软件危机”，说的是软件开发从小作坊式的开发模式转向大团队打造大型项目的过程中暴露出了许多从前没有注意过的问题，而其中最有代表性的就是著名的“OS/360”项目，这个项目被比作一个焦油坑，整个开发团队像一只巨兽在焦油坑中拼命挣扎，然而自己反而越陷越深，无法挣脱。
在这个项目艰难的完成后，负责人Brooks将其中的经验总结下来写出了巨著《人月神话》，尽管距离成书的时间已经四五十年，书中熠熠闪光的智慧依然在给我们启迪，『沟通成本 = n(n-1)/2』公式就是其中之一。
假设计划做一件事两个人沟通需要10分钟，5个人就需要100分钟。15个人需要1050分钟，2天左右。50个人需要12250分钟，25天。随着公司项目参与的人越来越多，公司如果不引入工程化的方法进行沟通架构改进，单单沟通成本就会拖垮公司。
二. 系统架构等同于组织之内的沟通结构
熟悉微服务的人对『康威定律』肯定不陌生，作为微服务架构的理论基础，康伟定律在最近几年被推上了神坛。其中最出名的定律就是『系统架构等同于组织之内的沟通结构』。
用过微信和QQ的人能感受到这是一家公司做出来的产品吗？这两款产品的功能虽然相近但是体验感受差异巨大。用过天猫和淘宝的人会觉得这两款App有差异吗？这两款产品提供的服务并不一样，但用起来体验感受都差不多。从这几款App的设计就能看出腾讯和阿里是以一种什么样的组织架构在运行。比如腾讯是各BG自负盈亏，微信和QQ像是两个完全独立的公司在运营，更注重细节打磨和产品盈利，所以腾讯的2C业务独占鳌头。阿里各BG之间联系紧密，合伙人都需要轮岗，更注重沟通效率和公共服务建设，所以阿里的2B业务做的非常好。
利用康威定律很容易从公司的产品架构分析出系统架构，但康威定律的作用并不是分析公司，而是告诉管理者-要改变系统架构，必须要改变组织的沟通结构。
之前有人做过实验，同样一个研发团队，当办公位置在一起时写的代码会更耦合，没有明显的边界。当办公位置分散时写的代码耦合度更低，并且有明显的边界和文档。物理上的距离会增加沟通成本，研发人员为了减少沟通成本无意识的就会更多的使用文档和接口。合理的利用康威定律，能帮助我们改善代码。
三. 软件的错误是无法避免的
Eric Hollnagel是敏捷开发社区的泰斗之一，对于一个巨复杂的系统，我们永远无法考虑周全，他的解决办法是“破罐子破摔”。Eric曾经被一家航空公司请去做安全咨询顾问，复杂保证飞机飞行系统的稳定性和安全性。Eric认为做到安全有两种方式：
- 常规的安全指的是尽可能多的发现并消除错误的部分，达到绝对安全，这是理想。
- 弹性安全，即使发生错误，只要及时恢复，也能正常工作，这是现实。
对于飞机这样的复杂系统，再厉害的人也无法考虑到漏洞的方方面面，所以Eric建议放弃打造完美系统的想法，而是通过不断的试飞，发现问题，确保问题发生时，系统能自动复原即可，而不追求飞行系统的绝对正确和安全。这不就是持续集成和敏捷开发吗？
微服务架构中最难处理的问题就是"容错"（下一篇文章会讲微服务中最重要的容错设计），大家对待错误的态度已经从不能忍变成了默许。
四. 程序运行时出问题的规律符合墨菲定律
如果听到 "用户绝对不会那样操作"，"这种概率非常低" 往往上线就会出问题。当时阿波罗登月的程序就有个已知的问题"如果宇航员不小心启动了P01的预运行程序，会导致原本还在飞行状态的模拟器瞬间崩溃"。但当时所有人都觉得宇航员受过严格训练，操作是完美的，“绝对不可能出错”。但可怕的事情还是发生了，宇航员Jim Lovell不小心按下了P01程序，导致导航系统崩溃，如果不能修复飞船将无法返航，人类登月的历史也将被改写。最后MIT的一群程序员连夜奋战9个小时才挽救这个bug。
我们无法揣测用户的想法，也无法对随机事件做出准确的预判，所以遇到『发生概率极低』的问题也一定要及时修复。
