Clean Architecture(审校计划)

translation

Clean Architecture(审校计划)

第一部分 概述 1-16

第1章 设计与架构究竟是什么

第2章 两个价值维度的故事

1. 翻译用词不太准确

位置：第14页-架构价值
原文：“I’m using the word “shape” here in a unconventional way, but I think the metaphor is apt. Software developers often feel as if they are forced to jam square pegs into round holes.”
错误点：但是其寓意是很明显的
建议：但是其寓意是很贴切的。

第二部分 从基础构件开始：编程方式 21-51

第3章 编程范式总览

1. 有悖原意

位置：23页-函数式编程
错误点：λ 演算法的一个核心思想是它可变性
建议： λ 算子的一个核心思想是它的不可变性

第4章 结构式编程

1. 语序有问题

位置：27页-可推导
错误点：同样的，Dijkstra 利用再次用枚举法证明了选择分支结构的可推导性
建议：同样的，Dijkstra 再次利用枚举法证明了选择分支结构的可推导性

Euclidean hierarchy of theorem
怎么翻译？

2. 名字打错了

30页-测试> Dikstra 曾经说过

建议：Dijkstra 曾经说过

第5章 面向对象编程

1. 笔误

33页-集成（inheritence）

建议：继承

第6章 函数式编程

1. 年代的惯用法不合适

46页，第一段： Alonzo Church 在1930年代发明的λ-演算

错误点：惯用法不对
建议：1930年代 -> 20世纪30年代

2. 笔误

位置：49页-可变性的隔离
错误点：一并不...
建议：在上面的代码中，inc函数会将参数加一并存到 counter 这个 atom 实例中。

3. 多种错误

位置：49页-可变性的隔离
错误点：部分用词不恰当：
建议：counter 不是变量，函数名和变量名不应大写。

错误点：描述的逻辑和实际不符
建议：在这里，swap! 所采用的策略是传统的比较+替换的算法。即先读取 counter 的值，再将其传入 inc 函数。然后当 inc 函数返回时，将原先用锁保护起来的 counter 值和传入到 inc 函数时的值进行比较。如果两边的值一致，则将 inc 函数返回的值存入 counter，释放锁。否则，先释放锁，再从头开始重试。

第三部分 设计原则 55-81

1. 年代惯用法不对

53页，第4段：早在1980年末期

建议：早在20世纪80年代末期

2. 行业常用的翻译

54页：LSP: Liskov 可替换原则

建议：LSP: 里氏替换原则

第7章 SRP：单一责任原则（建议：单一职能原则）

第8章 OCP：开放闭合原则（建议：开闭原则）

1. 翻译不当

63页 虚拟实验

原文是 A THOUGHT EXPERIMENT
建议：思维实验

第9章 LSP：Liskov 替换原则（建议：Liskov 里氏替换原则 ）

1. 翻译不符合技术定义

位置：71页，第1段-LSP与软件架构
建议：它可以是Java风格的接口，具有多个实现类。也可以像ruby一样，几个类共用一样的方法签名（此处指的是mixin），甚至也可以像一个REST接口，由多个服务响应。

第10章 ISP：接口隔离原则

75页，图10.3：有问题的软件架构：图上缺少了字母 系统 S -> 框架 F -> 数据库 D

第11章 DIP：依赖反转原则

第四部分 组件构建原则 84-117

第12章 组件

第13章 组件构建原则

复用/发布等同原则

1. 不符合原作

位置：93页-复用、发布等同原则
建议：这意味着它们共享相同的版本号和相同的版本跟踪，并且包含在相同的发行文档中，这些都应该同时对该组件的作者和用户有意义。

共同闭包原则

建议：有不少 CCP 写成了 CPP

第14章 组件耦合

1. 翻译不明

位置：102页-循环依赖
错误点：不清楚这种读取声明的方式到底是什么样的？

2. 前后文翻译不统一

错误点：前文都是用共同闭包原则（CCP），这里用了组件聚合原则。
建议：统一改成共同闭包原则

3. 有悖原意

原文：“The Fan-in and Fan-out metrics1 are calculated by counting the number of classes outside the component in question that have dependencies with the classes inside the component in question. ”
位置：108页-稳定依赖原则
错误点：把 have dependencies with the classes inside the component 翻译成了统计组件外部类的依赖与组件内部类的数量来计算的；其实应该是和组件内部有依赖的那些外部类的数量。
建议：Fan-in 和 Fan-out 这两个指标是通过统计和组件内部类有依赖的组件外部类的数量来计算的。

稳定抽象原则

1. 有悖原意

位置：112页-高阶策略应该放在那里
原文：“However, if the high-level policies are placed into stable components, then the source code that represents those policies will be difficult to change”
建议：然后，如果我们将高阶策略放入稳定组件中，那么描述哪些策略的源代码就很难被修改了。

2. 图不对

位置：144页-排除区
错误点：和原图不符，区域的标识错了。
建议：重新配图

3. 有悖原意

位置：115页-无用区
原文：“ This location is undesirable because it is maximally abstract, yet has no dependents. Such components are useless. Thus this area is called the Zone of Uselessness.”
错误点：yet has no dependents 翻译成了又不依赖于其它组件，其实是说没有被其它组件依赖。
建议：因为这些组件通常是无限抽象的，但是没有被其他组件依赖，这样的组件往往是无法使用的。

第五部分 软件架构 120-238

第15章 什么是软件架构

1. 不符合行业术语

位置：125页-保持选项开放
错误点：dependency injection framework 翻译成了依赖注射框架
建议：依赖注入框架

2. 笔误 127页, 第3段：

然而，管理大量的卡片是意见【一件】很麻烦的事；127页，第4段，或者处理磁带时以外【意外】插入空白记录。

第16章 独立性

第17章 划分边界

1. 多余的词

156页 令人生畏的单体结构 第3段 因为即使最终所有的组件最终都被静态链接成了一个可执行文件

错误点：多了最终。
建议：删除前面的最终

第18章 边界剖析

第19章 策略与层次

第20章 业务逻辑

第21章 尖叫的软件架构

第22章 极净架构

第23章 展示器和谦卑对象 （这里的序号有错）

1. 有悖原意

原文：“For example, if the application needs to know the last names of all the users who logged in yesterday”
位置：188页，第1段，数据库网关
错误点：Application 翻译成了数据库
建议：例如，如果应用程序需要知道...

2. 不太符合行业术语

位置：188页，第3段，数据库网关
原文：because the gateways can be replaced with appropriate stubs and test-doubles.
错误点：stub 指的是测试桩，而test-doubles指的是测试替身
建议：因为数据库网关通常可以被替换成对应的测试桩和测试替身类。

第24章 不完全边界

单向边界

1. 不符合行业惯用法

位置：192页
建议：策略模式

第25章 层次和边界

第26章 Main 组件

第27章 服务：宏观和微观

第28章 测试边界

第29章 至净嵌入式架构

1. 不符合原文

位置：228页 目标硬件瓶颈
原文：“If the target is the only place where testing is possible, the target-hardware bottleneck will slow you down.”
错误点：翻译成了尚不存在的平台上
建议：如果我们只能在特定的平台上测试代码，那么这一定会拖慢项目的开发进度。

2. 翻译不通顺

位置：236页 第2段
建议：是可以在目标操作系统之外被测试的。

第六部分 240-321

第30章 数据库只是实现细节

1. 不符合原文

位置：246页
原文：“Relational database systems that force the data to be organized into tables and accessed with SQL have much more to do with the latter than with the former. The data is significant. The database is a detail.”
错误点：主要是为了速度
建议：关系型数据库强制我们将数据存储成表格并以SQL访问更偏向存储和读取数据。

第31章 Web是实现细节

第32章 应用程序框架是实现细节

255页，依赖注入框架

第33章 设计与架构究竟是什么

第34章 拾遗

1. 错字

位置：279页
建议：同一个源代码树中，就有可能使得应用中一个区域的基础设施代码。

附录A 架构设计考古