[read]系统之美

本文最后更新于2018年5月24日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

整理总结一下最近看的《系统之美》这本书,收获不少,但还需不断重读、思考、实践。

正文:

参考解答:

前言

  • 管理者所遇到的问题通常都不是彼此孤立的,而是相互影响、动态变化的,尤其是在由一系列复杂系统构成的动态情境之中。在这种情况下,管理者不能只是解决问题,而应善于管理混乱的局势。
  • 只要懂得系统原理,就可以在恰当的地方施加干预措施,从而获得期望的转变。
  • 不能只通过了解系统的各个构成部分来认识系统整体的行为。
第一部分 系统的结构和行为
第1章 系统之基础
  • 总体大于部分之和
    • 对于一个系统来说,整体大于部分之和。任何一个系统都包括三种构成要件:要素、连接、功能或目标。它具有适应性、动态性、目的性,并可以自组织、自我保护与演进。
  • 从关注要素到透视游戏规则
  • 理解系统行为的动态性
  • 反馈:系统是如何运作的
  • 自动洄游的鱼:调节回路
第2章 系统大观园
  • 单存量系统
    • 系统1.1:一个存量、两个相互制衡的调节回路的系统
  • 双存量系统
    • 实际会出现哪种结果,取决于两方面:第一,关键转折点是否被突破。一旦关键转折点被突破,资源的种群数量实现再生的能力就会被破坏;第二,在资源逐渐衰减的过程中,抑制投资增长的调节回路的力度。如果该调节回路可以在关键转折点到来之前,快速起作用,控制资本的增长,那么整个系统就能平滑地达到均衡状态;如果该回路速度比较慢,不足够有效,系统就会振荡;如果该回路非常弱,或者起作用的速度很慢,这样一来,即使资源已经降低到难以再生的水平,但资本仍在持续增长,最终的结果是,该资源和产业都将崩溃。
    • 对于所有复杂的系统来说,判断系统未来行为走势的诀窍在于,了解什么样的系统结构包含哪些可能的行为,以及什么状况或条件可以触发这些行为。换句话说,如有可能,我们可以调整系统结构和相关条件,从而减少破坏性行为发生的概率,增加有利行为出现的概率。
第二部分 系统思考与我们
第3章 系统之美:系统的3大特征
  • 适应力
    • 系统之所以会有适应力,是因为系统内部结构存在很多相互影响的反馈回路,正是这些回路相互支撑,即使在系统遭受巨大的扰动时,仍然能够以多种不同的方式使系统恢复至原有状态。
    • 适应力总是有限度的。有适应力的系统可能是经常动态变化的。相反,一直保持恒定的系统恰恰是不具备适应力的。
  • 自组织
    • 系统所具备的这种使其自身结构更为复杂化的能力,被称为“自组织”(self-organization)。
    • 尽管以法律和维持秩序的名义,自组织能被长期压制、残酷打压,但它不可能被彻底消灭,而会顽强地持续下去。
    • 科学本身也是一种自组织系统,它倾向于认为,这个纷繁复杂的大千世界,往往生成自一些简单的规则。当然,究竟是否如此,科学到现在为止仍然未能给出答案。
  • 层次性
    • 在新结构不断产生、复杂性逐渐增加的过程中,自组织系统经常生成一定的层级或层次性。
    • 生命起源于单细胞细菌,而不是一头大象。层次性原本的目的是帮助各个子系统更好地做好其工作,不幸的是,系统的层次越高或越低,越容易忘记这一目的。因此,很多系统因为层次的功能失调,而不能实现并预定的目标。
    • 要想让系统高效地运作,层次结构必须很好地平衡整体系统和各个子系统的福利、自由与责任。这意味着,既要有足够的中央控制,以有效地协调整体系统目标的实现,又要让各个子系统有足够的自主权,以维持子系统的活力、功能和自组织。
第4章 系统之奇:系统的6大障碍
  • 6大障碍:复杂表象、非线性世界、划分系统边界、看清各种限制因素、无所不在的时间延迟、有限理性。
  • 别被表象所迷惑
  • 在非线性的世界里,不要用线性的思维模式
  • 恰当地划定边界
  • 看清各种限制因素
  • 无所不在的时间延迟
  • 有限理性
第5章 系统之危与机:系统的8大陷阱与对策
第三部分 改变系统
第6章 系统之杠杆点:系统的12大变革方式
  • 复杂系统的特征之一是“违反直觉的”,而寻找和撬动杠杆点也通常不能靠直觉。
  • 复杂的系统就是复杂的系统,对其进行一般化的归纳是十分危险的。
  • 12. 数字:包括各种常数和参数
  • 11. 缓冲器:比流量力量更大、更稳定的存量
  • 10. 存量-流量结构:实体系统及其交叉节点
  • 9. 时间延迟:系统对变化做出反应的速度
  • 8. 调节回路:试图修正外界影响的反馈力量
  • 7. 增强回路:驱动收益增长的反馈力量
  • 6. 信息流:谁能获得信息的结构
  • 5. 系统规则:激励、惩罚和限制条件
  • 4. 自组织:系统结构增加、变化或进化的力量
  • 3. 目标:系统的目的或功能
  • 2. 社会范式:决定系统之所以为系统的心智模式
  • 1. 超越范式
第7章 与系统共舞:系统的15大生存法则
  • 跟上系统的节拍
  • 把你的心智模式展现在阳光下
  • 相信、尊重并分享信息
  • 谨慎地使用语言,并用系统的概念去丰富语言
  • 关注重要的,而不只是容易衡量的
  • 为反馈系统制定带有反馈功能的政策
  • 追求整体利益
  • 聆听系统的智慧
  • 界定系统的职责
  • 保持谦逊,做一名学习者
  • 庆祝复杂性
  • 扩展时间的范围
  • 打破各种清规戒律
  • 扩大关切的范围
  • 不要降低“善”的标准
附录
  • 系统术语表
  • 系统原理概要
  • 常见的系统陷阱(8个常见陷进)
  • 采取干预措施的杠杆点(12个杠杆点)
  • 系统世界生存法则(15个生存法则)
参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3932.html

《[read]系统之美》上有2条评论

  1. 降低软件复杂性的一般原则和方法
    https://mp.weixin.qq.com/s/-Gu_XkY2bZq9Lf2ZCJZPtQ

    本文是作者阅读John Ousterhout的《A Philosophy of Software Design》之后,结合自己的工作经验,对“降低复杂性”做了详细总结,希望给读者朋友们带来不一样的思路。

    一、前言
    本篇文章是围绕着“降低复杂性”这个主题展开的,很多重要的结论来源于John Ousterhout,笔者觉得很有共鸣,就做了一些相关话题的延伸、补充了一些实例。虽说是“一般原则”,也不意味着是绝对的真理,整理出来,只是为了引发大家对软件设计的思考。

    二、如何定义复杂性
    子模块的复杂度Cp是一个经验值,它关注几个现象:
    1.修改扩散,修改时有连锁反应。
    2.认知负担,开发人员需要多长时间来理解功能模块。
    3.不可知(Unknown Unknowns),开发人员在接到任务时,不知道从哪里入手。
    造成复杂的原因一般是代码依赖和晦涩(Obscurity)。其中,依赖是指某部分代码不能被独立地修改和理解,必定会牵涉到其他代码。代码晦涩,是指从代码中难以找到重要信息。

    三、解决复杂性的一般原则
    首先,互联网行业的软件系统,很难一开始就做出完美的设计,通过一个个功能模块衍生迭代,系统才会逐步成型。对于现存的系统,也很难通过一个大动作,一劳永逸地解决所有问题。系统设计是需要持续投入的工作,通过细节的积累,最终得到一个完善的系统。因此,好的设计是日拱一卒的结果,在日常工作中要重视设计和细节的改进。

    其次,专业化分工和代码复用促成了软件生产率的提升。比如硬件工程师、软件工程师(底层、应用、不同编程语言)可以在无需了解对方技术背景的情况下进行合作开发;同一领域服务可以支撑不同的上层应用逻辑等等。其背后的思想,无非是通过将系统分成若干个水平层、明确每一层的角色和分工,来降低单个层次的复杂性。同时,每个层次只要给相邻层提供一致的接口,可以用不同的方法实现,这就为软件重用提供了支持。分层是解决复杂性问题的重要原则。

    第三,与分层类似,分模块是从垂直方向来分解系统。分模块最常见的应用场景,是如今广泛流行的微服务。分模块降低了单模块的复杂性,但是也会引入新的复杂性,例如模块与模块的交互,后面的章节会讨论这个问题。这里,我们将第三个原则确定为分模块。

    最后,代码能够描述程序的工作流程和结果,却很难描述开发人员的思路,而注释和文档可以。此外,通过注释和文档,开发人员在不阅读实现代码的情况下,就可以理解程序的功能,注释间接促成了代码抽象。好的注释能够帮助解决软件复杂性问题,尤其是认知负担和不可知问题(Unknown Unknowns)。

    四、解决复杂性之日拱一卒
    4.1 拒绝战术编程
    4.2 设计两次

    五、解决复杂性之分层
    5.1 层次和抽象
    5.2 复杂性下沉
    5.3 异常处理

    六、解决复杂性之分模块
    6.1 深模块和浅模块
    6.2 通用和专用
    6.3 信息隐藏
    6.4 拆分和合并

    七、解决复杂性之注释
    7.1 注释的误区
    7.2 使用注释提升系统可维护性
    7.3 使用注释改善系统设计

    八、后记
    John Ousterhout累计写过25万行代码,是3个操作系统的重要贡献者,这些原则可以视为作者编程经验的总结。有经验的工程师看到这些观点会有共鸣,一些著作如《代码大全》、《领域驱动设计》也会有类似的观点。所以本文中提到的原则和方法具有一定实操和指导价值。对于很难有定论的问题,也可以在实践中去探索。

    关于原则和方法论,既不必刻意拔高,也不要嗤之以鼻。指导实践的不是更多的实践,而是实践后的总结和思考。应用原则和方法论实质是借鉴已有的经验,可以减少我们自行摸索的时间。探索新的方法可以帮助我们适应新的场景,但是新方法本身需要经过时间检验。

发表评论

电子邮件地址不会被公开。 必填项已用*标注