02 | 架构设计的历史背景

2018年5月1日心得 在古代的狼人传说中，只有用银质子弹（银弹）才能制服这些异常凶残的怪兽。在软件开发活动中，“银弹”特指人们渴望找到用于制服软件项目这头难缠的“怪兽”的“万能钥匙”。 软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。从IT技术的发展历程来看，先辈们在上述不同的环节中提出过很多在当时看来很先进的方法与理念。但是，这些方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点：我们可以通过诸多方式去接近“银弹”，但很遗憾，软件活动中没有“银弹”。 布鲁克斯发表《人月神话》三十年后，又写了《设计原本》。他认为一个成功的软件项目的最重要因素就是设计，架构师、设计师需要在业务需求和IT技术中寻找到一个平衡点。个人觉得，对这个平衡点的把握，就是架构设计中的取舍问题。而这种决策大部分是靠技术，但是一定程度上也依赖于架构师的“艺术”，技术可以依靠新工具、方法论、管理模式去提升，但是“艺术”无法量化 ，是一种权衡。 软件设计过程中，模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论，软件架构是一种对软件的“组织”方法论。一分一合，其目的是为了软件研发过程中的成本、进度、质量得到有效控制。但是，一个成功的软件设计是要适应并满足业务需求，同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”，这就决定了这是一个动态活动，出现新问题，解决新问题，没有所谓的“一招鲜”。 以上只是针对设计领域的银弹讨论，放眼到软件全生命周期，银弹问题会更加突出。 小到一个软件开发团队，大到一个行业，没有银弹，但是“行业最佳实践”可以作为指路明灯，这个可以有。

软件开发最本质的挑战有两个:复杂和变更，而软件的价值是保证业务的响应力，而与之相对的是开发资源的有限，而各种的软件开发方法论，也都是在研究有限的资源下，如何应对着两个挑战，寻找平衡点，实现业务目标，因为是在寻找平衡点，就说明是有取舍的，所以就没有所谓的银弹的存在

变化才是唯一的不变，所以银弹不会存在

作者这个问题是否在考验，读者认真看了这篇文章没有？我认为文章的软件发展历史正是答案，软件工程归根结底是为各行各业的需求服务的，而随着需求的复杂度越来越高，用户的要求越来越高，软件也越复杂，形态也在不断变化，所以没有一种方法论能称得上是银弹，只能说某一种方法论适合某一种需求。这也正是架构师存在的意义，去选择合适的技术，如果有银弹，还要架构师干嘛！以上只是个人见解！

软件开发的结果在于人，而不在于方法论，面向对象，设计模式，架构，这些概念的推出距离现在，好几十年了吧，可真正理解透彻的能有多少呢，就算有像作者这样理解透彻的，还在一线开发的能有多少……阿里的p9难道还在一线写代码嘛……最终写代码的人还是理解不到位的我们，技术强的，写的项目能多撑两年，但是复杂到一定程度，没有良好关系架构指导，都是坑

“No Silver Bullet”的原文是：“没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。”之所以这样说，是因为软件的根本困难（Essence，包括复杂度、一致性、可变性、不可见性) 复杂度:规模上, 软件实体可能比任何由人类创造的其他实体更复杂, 因为没有任何两个软 件部分是相同的 一致性:软件的变化必须遵循一系列接口标准规范,有些情况下它的变化就是要兼容； 可变性:一般有如下几种情况: 1.当客户喜欢用某个功能或者某个功能能解决他的某些问题时,他会针对这方面提出很多优化该功能的需求点 2.硬件或者其他配件的升级变化 必须升级现有软件平台 不可见性:软件不存在一种空间形态 可以通过一张图 或者其他载体来可视化展示 ,不能通过地图 电路设计图等来全面展示. 由于这几个点的变化，导致系统越来越臃肿,从而导致管理成本上升,沟通困难,可靠性逐年下降等等；而结构化 面向对象等主要是来提高生产率 可靠性和简洁性

软件本身的复杂度难以度量，随时间和规模发展，原有的解决方案很快难适应，人们就不断总结经验模式和设计解决新困难的办法，但是不管什么样的架构设计都是在尽量满足适应我们可能遇到的问题的解决方案，不是解决问题方案。生活中我们的应用从单体到主备再到集群、分布式、微服务最后到最新的Service Mesh，这些其实都是解决和改善、完善、优化我们在软件开发遇到的问题。There is no silver bullet.

作者的用心令人敬佩。 为什么现在我们在谈“架构”，他不是平白无故产生的，他是在一定的背景下产生的。更好地理解他产生的原因，会在具体解决问题的时候做到有的放矢。 直到现在才看明白，what，why，how。这真是一个认清事物最本质的三步。👍👍👍

感觉作者对整个软件行业有比较深入的了解。就是内容太少。还没看就没了。希望后面的文章多来一点干货。让我这种小白能够学习到一点实质的东西。能够解决项目问题的一些东西。希望大神能够把自己的功力展现60%就行。

一个答案解决所有问题：“因为熵增定律”。 而熵增的表现其实就是变化。 那如何克服这一变化？ 同样是一句话概括：“生命以负熵为食”。 即在生物界，生命通过已知的信息完成外界能量到自身的转移，这个过程虽然逃不过熵增定律，但通过加速外界的熵增实现了生命自身熵的不变，生物因此得以维持自身状态不变(即活着，没死) 文章说到的架构的历史，其实就是一个对抗熵增的生命演化史。软件本身没有生命，所以要依靠人来实现自身状态维持。 即如果我们将软件和人看成一个整体，那么其状态即是可维持的，所以这就是银弹。而如果将人从这个整体中剥离出去，软件就失去了生命力，无法永远维持自身状态，再牛逼的设计也不可能成为银弹，除非让其拥有对抗熵增的能力，那样的话软件也是有生命的。从这点来看，人工智能极有可能成为一个新生物，届时再也不需要程序员了，恩，人也不需要了，哈哈，细思极恐。