勿忘初心架构就解决业务问题的

Roc
2018-01-03 12:06:03

2018年读的第一本书, 这个是clean code 之后又一个佳作。 另, Bob 大叔是将故事的好手, 本书章节都蛮短,但是有力。

故事是从一个例子开始,为什么软件生产效率为什么会 下降?是什么原因导致的下降?软件的外部质量(behavior)和内部质量(code/structure)。当只关注软件的外部质量而不关注内部质量,那么生产效率会随着软件的软件功能的日益复杂和时间遗忘变成遗留(legacy) code, 软件难于理解,难于修改,bug 常出乎意料(regression bug ),生产效率随之 下降,成为一个一个人人避之的焦油坑。关注软件内部质量,Uncle bob 从Clean code 开始关注代码的质量,如何从形和神写出高的质量代码,有了clean code 和TDD, refactor,依赖注入 之类的工程实践,提出软件工匠。 时光穿梭,8年过去,关注点从clean code 代码出发到clean architect。 这个就是本书的核心,架构的重要性,架构的初心。什么设计架构,什么好的架构, 如何做到好的架构,有哪些原则,以及提出来一个clean architectect图,同时纠正以往在设计的时候对于框架,数据库,web的依赖。

但是开始先做一些铺垫和热身。

1.讲解计算机语言的模式进化。(结构化编程从语言中去掉got

...
显示全文

2018年读的第一本书, 这个是clean code 之后又一个佳作。 另, Bob 大叔是将故事的好手, 本书章节都蛮短,但是有力。

故事是从一个例子开始,为什么软件生产效率为什么会 下降?是什么原因导致的下降?软件的外部质量(behavior)和内部质量(code/structure)。当只关注软件的外部质量而不关注内部质量,那么生产效率会随着软件的软件功能的日益复杂和时间遗忘变成遗留(legacy) code, 软件难于理解,难于修改,bug 常出乎意料(regression bug ),生产效率随之 下降,成为一个一个人人避之的焦油坑。关注软件内部质量,Uncle bob 从Clean code 开始关注代码的质量,如何从形和神写出高的质量代码,有了clean code 和TDD, refactor,依赖注入 之类的工程实践,提出软件工匠。 时光穿梭,8年过去,关注点从clean code 代码出发到clean architect。 这个就是本书的核心,架构的重要性,架构的初心。什么设计架构,什么好的架构, 如何做到好的架构,有哪些原则,以及提出来一个clean architectect图,同时纠正以往在设计的时候对于框架,数据库,web的依赖。

但是开始先做一些铺垫和热身。

1.讲解计算机语言的模式进化。(结构化编程从语言中去掉goto 使得程序可以分解验证,面向对象从语言总限制数据访问,提供封装继承和多态,函数是编程从语言中拿掉赋值,较少中间状态,没有副作用)

2. 面向对象的设计原则Solid 原则( 职责单一【反例偶然耦合,提交代码的merge】, Open Close 原则(设计追求),里氏替换原则(陷阱),接口分离(隔离变化),依赖注入(为什么以及如何做到底层依赖高层))

3.包设计的原则,如何做到高内聚低耦合

然后进入主题,什么是设计与架构。 这个是本书的重点。

15章开始给出软件架构对于软件生命周期的影响(5个视角 开发,测试,部署,运维, 维护), 以及什么是设计师,设计师就是资深程序员, 没有一线编码很难做好的设计(这个在国内的国情稍有不一样)。 好的设计上要实现业务(这个是本),中间要指导实现,后面要易于维护。 这个是自己对好的架构的理解。 Bob 给出自己的好的定义: 软件架构就要抓住本质的东西,与次要的东西分离解构。这样次要的东西的决定就可以推迟,到最后的有充分的 信息在做决策

Good architects carefully separate details from policy,and then decouple the policy from the details so thoroughly that the policy has no knowledge of the details and does not depend on the details in any way. Good architects design the policy so that decisions about the details can be delayed and deferred for as long as possible.

16章开始讲故事,别人家故事因为过早对于次要问题的决策导致失败,而自己家因为延迟决策而成功的例子。告诉软件要区分主次问题,次要问题不要着急做决策,比如数据库(想想我司,估计要被骂吧)。 bounder line 就是提醒我们那些次要问题不要着急做决策。17、18章紧接着告诉我边界意味这什么? 边界意味着隔离,意味着修改不会传染,不会级联修改。隔离粒度(源代码,发布单元,进程)

Managing and building firewalls against this change is what boundaries are all about

另外一个角度,软件架构就是划分和协作。那么在Bob这里也同样,划分成component,就是为了隔离和分工协同开发。 那隔离目的就是防火墙,隔离变化的。19章 20章 软件的核心就是解决业务,那么什么是业务? 模型和场景。业务也分层次(低层的和高层的),同样低层的依赖高层,但是怎么确定谁高谁低呢? 给一个原则(好操作,不好理解)

A strict definition of “level” is “the distance from the inputs and outputs.” The farther a policy is from both the inputs and the outputs of the system, the higher itslevel. The policies that manage input and output are the lowest-level policies in thesystem.

Bob给一个很有力剪短的例子(银行利率例子)和加密算法例子来阐述。

22 章给出了一个Bob 的clean architect 图。 这个是 本书的精华和浓缩。两条:

Entity(模型)/场景/API/外部各种适配器(UI,BD,controller,storage...)。
依赖规则,外部依赖内部,内部不依赖外部。

该架构体现软件的价值,支撑和实现业务,将业务放到第一优先集,这个应理所当然。 二业务不需要以来外部(次要问题),次要问题,反过来不能影响业务设计决策。 24 章 讲述Humber 模式。25 章,软件不需要过度设计。怎么把我这个度,引用来自于敏捷的社区格言:

YAGNI: “You Aren’t Going to Need It.

同样提供不同的方式,(最后一步省略,facade,单向依赖)

25给一个例子,分层的例子; 27 紧扣当下热点评价一下微服务架构。提到一个 Compoent -Based Service, 软件的划分边界不一定按照serivce 边界,这个例子告诉你很可能是夸service边界的,是按compoent划分。 28章,测试,架构的一部分。好的架构容易测试,同时测试可以让你设计更好,达到高内聚低耦合。 代码或者模块可以测试,意味着可以对象可以创建,可以调用,那么对象就不依赖别人创建,而这些不正是我们松耦合。而对象本身作用,以及验证, 也就是高聚合,我们程序员一直追求的。29章,嵌入式的软件,也应该遵循clean 架构。感觉随着芯片的便宜,更多嵌入式开发都变成通用软件开发,嵌入式软件变为通用软件.

23 章 放到最好,说架构与代码项目组织关系。软件代码结构要体现架构,把架构放在最明显的地方,不要让代码结构把架构淹没在代码的碎片里。 如果酒店设计,大堂要设计的明显耀眼人人都可以看到。34 章,就是一个实践,如何在代码里面保证体现架构? 分层, 分feature,以及分compnent。这是一个权衡。自己感觉团队习惯约定与这个有一点冲突,当然架构本来就是一个折中。

最后强调什么是次要的问题。26章 Main Component 是次要问题。30章数据库是次要问题。31web 是次要问题。32 章框架是次要问题。这些就是水到渠成的故事。 (但是对于开发而言,实现这些是他们的日常工作,主要矛盾。 )

软件的架构,其实就是识别问题,找打主要和次要问题。 换一个视角,软件复杂的分为两种,一种是关于业务的,业务复杂度。 另外一种是技术的,技术复杂度。 没有银弹,说即使技术在强大,工具再强大,但是业务复杂度总是没法避免的,这个是根本复杂度。是技术没法从根本上解决调动。

3
0

查看更多豆瓣高分好书

回应(1)

添加回应

推荐Clean Architecture的豆列

了解更多图书信息

豆瓣正在热议

豆瓣
免费下载 iOS / Android 版客户端