简介

精彩点评

• 

  郭雅杰

  推荐

  我是做汽车嵌入式软件的，这本书是说互联网软件的。这本书的涉及的领域与我工作领域不同，但是里面的思想和原则却对我有帮助。

• 

  李靖峰

  推荐

  前三个part是对已经反复被验证的概念的解读，第四part是本书核心理念，其余part是对前述理论的应用（callback）

• 

  Xiaoyi

  推荐

  看这本书最大的感受就是: 原来心中憋了很久说不出道不明的小疑惑，在这一瞬间豁然开朗。

• 

  陈春健

  推荐

  个人由于对于大型软件的认识比较少，所以对原则的目的不是很理解

• 

  Daniel

  推荐

  架构整洁之道，本书适用于架构入门的初学者，没有多少新知识点，而是对架构思想进行了提炼总结，推荐阅读。以下是提炼总结： 1.设计与架构究竟是什么： 软件架构的终极目标，用最小的人力成本来满足构建和维护该系统的需求。 2.架构的两个价值维度：行为和架构 架构是行为的基础，不打好基础，系统就乱套了，最终难以维护 3.三种编程范式（目的是限制）： (1)结构化编程（structured programming），限制了goto语句。 (2)面向对象编程（object-oriented programming），限制了函数指针。 (3)函数式编程（functional programming），限制了赋值语句。 4.关于测试的2点认知 (1)科学方法论不需要证明某条结论是正确的，只需要想办法证明它是错误的。如果某个结论经过一定的努力无法证伪，我们则认为它在当下是足够正确的。 (2)Dijkstra曾经说过“测试只能展示Bug的存在，并不能证明不存在Bug”，换句话说，一段程序可以由一个测试来证明其错误性，但是却不能被证明是100%正确的。测试的作用是让我们得出某段程序已经足够实现当前目标这一结论。 5.锁与变量的关系 (1)所有的竞争问题、死锁问题、并发更新问题都是由可变变量导致的。如果变量永远不会被更改，那就不可能产生竞争或者并发更新问题。如果锁状态是不可变的，那就永远不会产生死锁问题。 (2)软件架构师应该着力于将大部分处理逻辑都归于不可变组件中，可变状态组件的逻辑应该越少越好。 6.关于软件设计的5个原则 (1)单一职责：函数和类必须在某一维度职责单一，只对某一类行为者负责。避免边界不清晰，后期维护困难 (2)开闭原则：对扩展开放，对修改关闭；对客户端修改关闭，对服务端修改开放 (3)里氏替换选择，父类出现的地方子类可以进行替换，提升代码复用性、扩展性；同时又增加了父子类的耦合性 (4)接口隔离原则：接口、类的职责要单一，低耦合 (5)依赖反转原则：要依赖抽象/接口，不依赖具体实现（代码注释要更贴近业务语言，避免出现具体实现相关的描述，简称通用语言）。 7.关于组件 组件是软件在部署过程中的最小单元。设计良好的组件都应该永远保持可被独立部署的特性，也意味着这些组件应该可以被单独开发，对应在Java里就是jar文件。 8.关于组件聚合 (1)软件开发者必须要能够知道这些组件的发布时间，以及每次发布带来了哪些变更 (2)对大部分应用程序来说，可维护性的重要性要远远高于可复用性。 (3)这些变更最好都体现在同一个组件中，而不是分布于很多个组件中 (4)将由于相同原因而修改，并且需要同时修改的东西放在一起。将由于不同原因而修改，并且不同时修改的东西分开。 (5)这种平衡本身也在不断变化。也就是说，当下适用的分割方式可能明年就不再适用了。所以，组件的构成安排应随着项目重心的不同，以及研发性与复用性的不同而不断演化。 9.关于组件耦合 (1)第一种是“每周构建”，第二种是“无依赖环原则（ADP）”。 (2)我们可以打破这些组件中的循环依赖，并将其依赖图转化为DAG。目前有以下两种主要机制可以做到这件事情 a．应用依赖反转原则（DIP） b．创建一个新的组件 (3)我们不希望那些频繁变更的组件影响到其他本来应该很稳定的组件 (4)组件依赖关系是必须要随着项目的逻辑设计一起扩张和演进的。 (5)任何一个我们预期会经常变更的组件都不应该被一个难于修改的组件所依赖，否则这个多变的组件也将会变得非常难以被修改。 (6)让软件组件难于修改的一个最直接的办法就是让很多其他组件依赖于它。带有许多入向依赖关系的组件是非常稳定的，因为它的任何变更都需要应用到所有依赖它的组件上。 10.关于软件架构 (1)软件架构等同于设计架构，即要设计出易于理解，易于修改，易于维护的的软件。最大限度的释放开发人员的维护人力，减少软件运营成本 (2)软件架构设计的主要目标是支撑软件系统的全生命周期，设计良好的架构可以让系统便于理解、易于修改、方便维护，并且能轻松部署。软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本。 (3)对于一个因架构设计糟糕而效率低下的系统，我们通常只需要增加更多的存储器与服务器，就能够让它圆满地完成任务。另外，硬件也远比人力要便宜，这也是软件架构对系统运行的影响远没有它对开发、部署、维护的影响那么深远的一个原因。 (4)设计良好的系统架构应该可以使开发人员对系统的运行过程一目了然 (5)在软件系统的所有方面中，维护所需的成本是最高的。满足永不停歇的新功能需求，以及修改层出不穷的系统缺陷这些工作将会占去绝大部分的人力资源。 (6)系统维护的主要成本集中在“探秘”和“风险”这两件事上。其中，“探秘（spelunking）”的成本主要来自我们对于现有软件系统的挖掘，目的是确定新增功能或被修复问题的最佳位置和最佳方式。而“风险（risk）”，则是指当我们进行上述修改时，总是有可能衍生出新的问题，这种可能性就是风险成本。 (7)优秀的架构师会小心地将软件的高层策略与其底层实现隔离开 (8)优秀的架构师所设计的策略应该允许系统尽可能地推迟与实现细节相关的决策，越晚做决策越好。 11.关于独立性 我们一定要小心避免陷入对任何重复都要立即消除的应激反应模式中。一定要确保这些消除动作只针对那些真正意义上的重复。 12.划分边界 (1)软件架构设计本身就是一门划分边界的艺术。边界的作用是将软件分割成各种元素，以便约束边界两侧之间的依赖关系。 (2)简单来说，通过划清边界，我们可以推迟和延后一些细节性的决策，这最终会为我们节省大量的时间、避免大量的问题。这就是一个设计良好的架构所应该带来的助益。 (3)边界线应该画在那些不相关的事情中间。GUI与业务逻辑无关，所以两者之间应该有一条边界线。数据库与GUI无关，这两者之间也应该有一条边界线。数据库又与业务逻辑无关，所以两者之间也应该有一条边界线。 (4)这其实就是单一职责原则（SRP）的具体实现，SRP的作用就是告诉我们应该在哪里画边界线。 13.边界剖析 所谓划分边界，就是指在这些模块之间建立这种针对变更的防火墙。 14.策略与层次 低层组件被设计为依赖于高层组件。一条策略距离系统的输入/输出越远，它所属的层次就越高。而直接管理输入/输出的策略在系统中的层次是最低的。 15.业务逻辑 业务逻辑就是程序中那些真正用于赚钱或省钱的业务逻辑与过程。 选择直接在数据结构中使用对业务实体对象的引用。毕竟，业务实体与请求/响应模型之间有很多相同的数据。但请一定不要这样做！这两个对象存在的意义是非常、非常不一样的。随着时间的推移，这两个对象会以不同的原因、不同的速率发生变更。 16.关于框架 使用框架要衡量成本和产出，框架是工具而不是生活信条 17.整洁架构 所有跨边界的依赖线都是指向内的，这很好地遵守了架构的依赖关系规则 18.层次与边界 过度的工程设计往往比工程设计不足还要糟糕。但另一方面，如果我们发现自己在某个位置确实需要设置一个架构边界，却又没有事先准备的时候，再添加边界所需要的成本和风险往往是很高的。 19.软件构建发展的3个过程： (1)“先让代码工作起来”——如果代码不能工作，就不能产生价值。 (2)“然后再试图将它变好”——通过对代码进行重构，让我们自己和其他人更好地理解代码，并能按照需求不断地修改代码。 (3)“最后再试着让它运行得更快”——按照性能提升的“需求”来重构代码。 分层架构的理念是基于接口编程的理念来设计的。当模块之间能以接口形式交互时，我们就可以将一个服务替换成另外一个服务 20.数据库是实现细节 数据存储只是一个实现细节，所以架构方案不应局限于数据存储 系统架构应该对磁盘本身的存在完全不关心。 21.Web是实现细节 业务规则应该与UI解耦，做到可插拔式，便于扩展 22.应用程序框架是实现细节 程序框架只是实现细节，架构尽量避免依赖框架 如果选择了框架，就要做好准备在整个生命周期里适应它 23.依赖关系方向 所有跨越边界的依赖关系都应该是同一个方向 只有外部代码能依赖内部代码，反之则不能

• 

  曾強

  推荐

  相见恨晚的一本书!  如何衡量好的架构，如何写好的架构，如何向别人介绍怎么做架构!

• 

  开心每一刻

  推荐

  作者介绍如何划分系统架构的边界，运用到了SOLID原则，提倡业务domain和边界隔离，为未来不稳定的边界更换提供了条件

• 

  爱学习的小马老师

  推荐

  宏观讲解软件架构，非常有高度，并且从具体的逻辑上进行了多维度的讲解；自己还需要再看几遍。

• 

  曹宇

  推荐

  非程序员读来有点费劲，但很多架构设计思路是可借鉴的。附录的共鸣很多，很多深刻的认知都来自于曾经踩过的坑。

• 

  Nereus🌊

  推荐

  具体依赖抽象，低层策略依赖高层策略，不稳定依赖稳定，SOLID原则…… 大道确实至简，但是合理的运用在实际场景却不简单，具体的问题一定要具体分析，而不能套用模式，面对问题切记要以谦逊的态度了解事实，才可能做出最合适的决定。 自勉。

• 

  rex

  推荐

  Highly recommended for every software architect, system analyst/designer/manager and programmer! 初次了解这本书是在知乎的一篇文章《有哪些编程书，看完让人直呼过瘾》，而我的阅读体验也正如文章标题，非常兴奋，直呼过瘾！http://daily.zhihu.com/story/9667682 作者从1970年就开始做程序员，拥有丰富的各种系统的开发和架构经验，人称Uncle Bob。在书中作者基于自己的实战经验，用简单平实的语言和例子，阐述了软件架构的核定思想和原则。摘录几段如下： -  Software provides two different values : function and architecture. The 1st value is to make machines behave in a way that makes or saves money for the stakeholders. The 2nd value is to make software to be “soft”, that is, it must be easy to change for new requirements. -  The primary purpose of architecture is to support the life cycle of the system. Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize productivity. -  Good software begin with clean code. The SOLID principles tell us how to arrange our functions and data structures in to classes, and how those classes should be interconnected. The SOLID principles are: SRP - Single Responsibility Principle; OCP -  Open-Closed Principle; LRP - Liskov Substitution Principle; ISP - Interface Segregation Principle; DIP - Dependency Inversion Principle. -  Components are the units of deployment. They are the smallest entities that can be deployed as part of a system, eg. jar files in Java. And the three principles of component cohesion are: REP - Reuse/Release Equivalence Principle; CCP - Common Closure Principle; CRP - Common Reuse Principle. - The way you keep software soft is to leave as many options open as possible, for as long as possible. What are the options that we need to leave open? They are the details that don’t matter. -  All software can be decomposed into two major elements: policy and details. The policy element embodies all the business rules and procedures. The policy is where the true value of the system lives. The details are those things that are necessary to enable human and other systems to communicate with policy. They include IO devices, databases, web systems, servers, frameworks, communication protocols, and so forth. -  Conway’s law: any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure. -  There are many ways to decouple layers and use cases, at source code level, at deployment level, at service level. And decouple at the service level is expensive. 书中有许多例子来说明如何实施这些原则，以及一些常见错误和解决方法，还特别介绍了一种Clean Architecture供参考。这些架构思想和实例对我非常有价值，传道解惑，值得一读再读，且不断实践。

• 

  YY

  推荐

  之前读过一遍英文版 有理解但印象不够深刻。这次又读了一遍中文版，是每天早晨读 1~2个番茄时钟的方式，前后大概读了2周多。大概是因为工作中摸过的系统越来越多的原因，在读的时候就能映射出来应该怎么改我们现在的系统，以及我们系统中哪里的设计和书里面提到的一样，如何受益了。 是很愉悦的阅读体验。 另外这本书最后附录部分，是uncle bob的工作简历。因为时代不太一样的原因，推荐略过

• 

  Tara

  推荐

  看的纸质书，同事给我发了这个的某一页的截图，然后看了几页试读就买了，挺好的，结合何川不久前的课，我们要在这个容易变化的世道里寻找一些不变的东西。 “边界”   “可能性”

• 

  fly的狐狸

  推荐

  本书让人了解了编程的发展，软件设计原则，系统的边界隔离，软件架构设计，以及常见的UI，数据库，三层架构的介绍。没有万能的架构，只有万能的架构师[微笑]

• 

  没想好先过渡

  推荐

  作者给出了架构的理想状态，虽然现实工作影响因素很多，但不妨碍对理想架构的追求。即使无力改变整个系统的结构，这些理论也能在开发一个小模块甚至一个小方法时去应用去感受。