Clean Architecture:软件架构与设计匠艺(英文版)

【美】Robert C. Martin(罗伯特·C·马丁)

出版时间

2018-06-30

ISBN

9787121342615

评分

★★★★★
书籍介绍

通过合理运用软件架构的通用法则,可以显著提升开发者在所有软件系统全生命周期内的生产力。如今,传奇软件匠师Robert C. Martin(Bob 大叔),携畅销书Clean Code 与The CleanCoder 所获巨大成功之威,深刻揭示这些法则并亲授运用之道。Martin 在《Clean Architecture:软件架构与设计匠艺(英文版)》中远不只是在为我们提供选项,他几乎是在将软件世界中横跨半个世纪的各种架构类型的设计经验倾囊相授,目的是让读者既能阅尽所有架构选型,又可通晓其如何决定成败。Bob 大叔也的确不负厚望,《Clean Architecture:软件架构与设计匠艺(英文版)》中充满了直接而有效的解决方案,以供读者应对所面临的真正挑战——那些或最终成就或彻底破坏你项目的挑战。

Robert C. Martin(Bob大叔)从1970年编程至今。他是cleancoders.com的联合创始人,该网站为软件开发者提供在线视频教育。同时,他还是Bob大叔咨询公司的创始人,该公司为全球大型公司提供软件开发咨询服务、培训以及技能培训服务。同时,他在 8th Light公司任“首席匠人”一职,该公司是位于芝加哥的一家软件开发咨询公司。本书作者在各种行业周刊上发表了十余篇文章,同时也经常被国际会议和行业峰会邀请进行演讲。他曾任C++ Report的主编,并且曾任敏捷联盟(Agile Aliance)的主席。

Martin曾经编写和参与编辑了多本图书,包括The Clean Coder、Clean Code、UML for Java Programmers、Agile Software Development、Extreme Progra...

(展开全部)

AI导读
核心看点
  • 架构终极目标是最小化构建维护成本
  • 组件隔离降低变更带来的影响范围
  • 依赖规则确保高层策略独立于细节
适合谁读
  • 具备一定项目经验的软件工程师
  • 希望理解架构设计原则的开发者
  • 寻求提升系统可维护性的团队
读前提醒
  • 无需全读,可跳读理解核心逻辑
  • 结合重构实践反复阅读体会更深
  • 关注架构决策与业务需求的关联
读者共识
  • 系统讲解架构设计的经典之作
  • 观点虽非全新但极具系统性与深度
  • 适合有经验者结合实践深入研读

本导读基于书籍简介、目录、原文摘录、短评和书评生成,不等同于全文精读。

精彩摘录
  • "人渐渐地发现,这个世界上有很多问题就像翘翘板一样,只能要一边,这一边上去了,另边就下来了。就像要么用空间换时间,要么用时间换空间一样,你很难同时满足空间和时间要求的“双利解”;就像CAP的三选二的理论一样,这个世界不存在完美的解方案无论什么方案都有好的一面和不好的一面。而且这些工程师还还渐渐发现,每当引入一个新的技术来解決一个已有的问题时,这个新的技术就会带来更多的问题,问题就像有一个生命体一样,它们会不断地繁殖和进化。"
  • "《架构整洁之道》孙宇聪译,软件架构参考书籍。 第一章 软件架构的终极目标是,用最小的人力成本来满足构建和维护该系统的需求。 软件开发的核心特点:要想跑得快,先要跑得稳。 过度自信只会使得重构设计陷入和原项目一样的困局中。 研发团队最好的选择是清晰地认识并避开工程师们过度自信的特点,开始认真地对待自己的代码架构,对其质量负责。 要想提高自己软件架构的质量,就需要先知道什么是优秀的软件架构。而为了在系统构建过程中采用好的设计和架构以便减少构建成本,提高生产力,又需要先了解系统架构的各种属性与成本和生产力的关系。 第二章 软件系统两个价值维度-----行为价值和架构价值。 软件架构师这一职责本身就应"
  • "软件架构师可以根据相关函数被修改的原因、修改的方式及修改的时间来进行分组隔离,并将这些相互隔离的函数分组整理成组件结构,使得高阶组件不会因低阶组件被修改而收到影响"
  • "这些工程师们普遍用一句话来欺骗自己:“我们可以未来再重构代码,产品上线最重要!”但是结果大家都知道,产品上线以后重构工作就再没人提起了。市场的压力永远也不会消退,作为首先上市的产品,后面有无数的竞争对手追赶,必须要比他们跑得更快才能保持领先。 所以,重构的时机永远不会再有了。工程师们忙于完成新功能,新功能做不完,哪有时间重构老的代码?循环往复,系统成了一团乱麻,生产效率持续直线下降直至为零。"
  • "这就是科学理论和科学定律的特点:它们可以被证伪,但是没有办法被证明。 但是我们仍然每天都在依赖这些定律生活。开车的时候,我们就等于是在用性命担保F=ma是对世界运转方式的一个可靠的描述。每当我们迈出一步的时候,就等于在亲身证明F=Gm1m2/r2是正确的。 科学方法论不需要证明某条结论是正确的,只需要想办法证明它是错误的。如果某个结论经过一定的努力无法证伪,我们则认为它在当下是足够正确的。 当然,不是所有的结论都可以被证明或者证伪的。举一个最简单的不可证明的例子:“这句话是假的”,非真也非伪。 最终,我们可以说数学是要将可证明的结论证明,而与之相反,科学研究则是要将可证明的结论证伪。"
  • "根据上述讨论,我们可以得出一个无法逃避的结论:组件结构图是不可能自上而下被设计出来的。它必须随着软件系统的变化而变化和扩张,而不可能在系统构建的最初就被完美设计出来。"
  • "首先,软件架构师自身需要是程序员,并且必须一直坚持做一线程序员,绝对不要听从那些说应该让软件架构师从代码中解放出来以专心解决高阶问题的伪建议。不是这样的!软件架构师其实应该是能力最强的一群程序员,他们通常会在自身承接编程任务的同时,逐渐引导整个团队向一个能够最大化生产力的系统设计方向前进。也许软件架构师生产的代码量不是最多的,但是他们必须不停地承接编程任务。如果不亲身承受因系统设计而带来的麻烦,就体会不到设计不佳所带来的痛苦,接着就会逐渐迷失正确的设计方向。"
  • "正如我们之前所说,架构师们所追求的目标是最大限度地降低构建和维护一个系统所需的人力资源。那么我们就需要了解一个系统最消耗人力资源的是什么?答案是系统中存在的耦合一一尤其是那些过早做出的、不成熟的决策所导致的耦合。 那么,怎样的决策会被认为是过早且不成熟的呢?答案是那些决策与系统的业务需求(也就是用例)无关。这部分决策包括我们要采用的框架、数据库、Web服务器、工具库、依赖注入等。在一个设计良好的系统架构中,这些细节性的决策都应该是辅助性的,可以被推迟的。一个设计良好的系统架构不应该依赖于这些细节,而应该尽可能地推迟这些细节性的决策,并致力于将这种推迟所产生的影响降到最低。"
作者简介
Robert C. Martin(Bob大叔)从1970年编程至今。他是cleancoders.com的联合创始人,该网站为软件开发者提供在线视频教育。同时,他还是Bob大叔咨询公司的创始人,该公司为全球大型公司提供软件开发咨询服务、培训以及技能培训服务。同时,他在 8th Light公司任“首席匠人”一职,该公司是位于芝加哥的一家软件开发咨询公司。本书作者在各种行业周刊上发表了十余篇文章,同时也经常被国际会议和行业峰会邀请进行演讲。他曾任C++ Report的主编,并且曾任敏捷联盟(Agile Aliance)的主席。 Martin曾经编写和参与编辑了多本图书,包括The Clean Coder、Clean Code、UML for Java Programmers、Agile Software Development、Extreme Programming in Practice、More C++ Gems、Pattern Languages of Program Design 3,以及Designing Object Oriented C++ Applications Using the Booch Method。
目录
PART I Introduction 1
Chapter 1 What Is Design and Architecture? 3
The Goal? 4
Case Study 5
Conclusion 12

显示全部
用户评论
核心观点之前已经在《敏捷软件开发》和博客里写了,但依然是目前为止我看到最系统的讲架构的书,还得好好咀嚼一下。 冷静下来想想,还是说的略显啰嗦,主要还是大部分观点不是新观点了。
代码怎么写架构怎么做,关键取决于怎么让人舒服。看起来舒服,维护起来舒服,扩展起来舒服。 关键在于怎么抽象,怎么划分模块,怎么组合模块,怎么定义边界,怎么方便扩展,怎么权衡决策。 说起来简单做起来可不容易,需要大量实践以及思考这类架构书中的一些原则和指导思想。
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
SOLID + Component + Dependency Rule + Dependency Rule 核心观点和敏捷里的一致。作为只写业务的人来说,很熟悉,但是对于架构这个词来说一直朦朦胧胧,看完Bob的书以为明白了,仔细回味依然在云中。
写的很好很清晰,看得出作者对这个领域有完整的认识。
非常好的书,说的东西都比较高层且偏经验化,如果没有太多项目经验全部看下去没多大感觉。不像教科书一样体系严谨周密,所以会显得啰嗦。我觉得不需要全看,跳着看大概三分之一,理解作者对于架构设计中需要考虑的因素和大的分离逻辑即可。然后,当重构软件的时候再拿出来读一下,感觉会很不一样。
收藏