代码整洁之道读书笔记——第十一章：系统 && 第十二章：迭进

第十一章 系统

复杂要人命。它消磨开发者的生命，让产品难以规划、构建和测试

11.1 如何建造一个城市

城市能运转，还因为它演化出恰当的抽象等级和模块

11.2 将系统的构造和使用分开

11.2.1 分解main

使用应该对构造过程一无所知

11.2.2 工厂

使用抽象工厂模式构建对象

11.2.3 依赖注入

对象不应该负责实体化对自身的依赖，它应当将这份权责移交给其它“有权利”的机制

11.3 扩容

一开始就做对系统纯属神话。我们应该去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。这就是迭代和增量敏捷的精髓所在

11.4 Java代理

适用于简单的情况，例如在单独的对象或类中包装方法调用

11.5 纯Java AOP框架

略

11.6 AspectJ的方面

略

11.7 测试驱动系统架构

最佳的系统架构由模块化的关注面领域组成，每个关注面均用纯Java对象实现，不同的领域之间用最不具有侵害性的方面或类方面工具整合起来，这种架构能测试驱动，就像代码一样

11.8 优化决策

延迟决策至最后一刻也是好手段。如果决策太早，就会缺少太多客户反馈、关于项目的思考和实施经验

11.9 明智使用添加了可论证价值的的标准

略

11.10 系统需要领域特定语言

略

11.11 小结

系统应该是整洁的。侵害性架构会湮灭领域逻辑，冲击敏捷能力

 

第十二章 迭进

12.1 通过迭进设计达到整洁目的

Kent Beck关于简单设计的四条规则：

1. 运行所有测试
2. 不可重复
3. 表达了程序员的意图
4. 尽可能减少类和方法的数量

以上规则按其重要度排列，1最重要，依次往下

12.2 简单设计规则1：运行所有测试

紧耦合的代码难以编写测试。编写测试越多，就越会遵循设计规则，使用依赖注入、接口和抽象等工具尽可能减少耦合

12.3 简单设计规则 2~4：重构

添加了几行代码后，就要暂停，琢磨一下变化了的设计。设计退步了吗？如果是，就要清理它，并且运行测试，保证没有破坏任何东西。测试消除了对清理代码就会破坏代码的恐惧

在重构过程中，可以应用有关优秀软件设计的一切知识：提升内聚性，降低耦合度，切分关注面，模块化系统性关注面，缩小函数和类的尺寸，选用更好的名称，如此等等

12.4 不可重复

避免及其雷同的代码出现，我们可以对某一些代码做一些共性抽取，实现小规模的复用

12.5 表达力

多花一点点时间在每个函数和类上，选用较好的名称，将大函数切分成小函数，时时照拂自己创建的东西。用心是最珍贵的资源。你要记住，下一位读代码的人最有可能就是你自己

12.6 尽可能少的类和方法

有的编码会要求我每个类创建接口，但是其实没有必要，我们要找到这个最合适的粒度，明白如何编写代码，控制类和方法的数量才是最舒服的。我们的目标是在保持函数和类短小的同时，保持整个系统短小精悍

12.7 小结

有没有能替代经验的一套简单实践手段呢？当然不会有。

总结

这两章的内容比较少，而且比较抽象，第十一章系统大体描述了一些很宏观的东西，包括一些设计模式该在什么地方什么时候使用，其实也不太好懂，需要再过段时间回来重读。第十二章的话，其实就是将前面几章的内容做了一个小总结，要注意命名规范，不要有重复代码，函数和类的长度等等。也没什么要特别的地方，其实对于代码整洁的问题，就像作者所说的，不是说有一套规范或者其他什么简单的手段就能让你立马明白如何写出整洁的代码，需要我们不断的实践实践再实践，不断的再项目当中磨练，边磨练边总结边体会。其实我们就像代码一样，需要不断的迭代，不断的思考，不断的进步，才能明白如何能做一个更加优秀的人！这次先到这，下次回来继续总结。