应对变化: 解耦:得墨忒尔法则 元数据与动态配置 并发与次序 划分模块、分而治之 编码时 不要靠巧合编程 代码需要演化：重构 编写易于测试的代码

1. 弯曲，或者折断
效 程实 编 3
Horky
7/Jun,2010
http://blog.csdn.net/horkychen
1

2. Keywords
• 化应对变 :
– 解耦 : 得墨忒尔法则
– 元数据与 配置动态
– 并 与次序发
– 分模 、分而治之划 块
• 编码时
– 不要靠巧合 程编
– 代 需要演化：重码 构
– 写易于 的代编 测试 码
2

3. 得墨忒尔法则 (Demeter)
• 某个对象的任何方法都应该只能调用：
– 它自身
– 传入该方法的任何参数
– 它创建的任何对象
– 任何直接持有的组件对象
3

4. 元数据与动态配置
• 将变化封装起来，使用元数据进行配置。
– 什么是变化的？
– 什么是不变化的？
– 抽象、抽象
4

5. 并发与时序
• 时间耦合（ temporal coupling)
– 定义好你的工作流
– 用服务为并发进行设计
– Windows COM+ 技术解说
5

6. 分而治之
• 观察者模式
6

7. 靠巧合编程
• 有时我们不知道为什么代码会有问题，因为我
们都不知道它为什么能工作。
• 几项注意：
– 它也许只是看起来能工作
– 你依靠的边界条件也许只是一个偶然
– 没有记入文档的行为可能会产生不必要的依赖
– 多余的和不必要的调用会成为代码的负担
– 多余的调用还会增加引入 BUG 的风险
• 简洁且高效的代码是我们的目标
• 在文档记录各种假定。大胆假设、小心论证。
7

8. 深思熟虑的编程
• 总是意识到你在做什么
• 不要盲目地编程
• 按照计划行事
• 依据可靠的事物，不要依靠巧合和假定
• 为你的假定建立文档。（异常处理和断言）
• 不要只是测试你的代码，还要测试你的假定
• 为你的工作划分优先级
• 不要做历史的奴隶。不要让已有代码支配未来
的代码
8

9. 代码需要演化
• 软件工程师与建筑师
• 软件工程师与园丁
9

10. 如何进行重构
• 重构需要慎重、小心进行的活动，也需要
勇气：
– 不要试图在重构的同时增加新功能。
– 在开始之前，确保你拥有良好的测试。
– 采取短小、深思熟虑的步骤进行重构。
10

11. 易于测试的代码
• 测试是 R&D 的责任！
• 保证我们清楚我们在做什么，并且做好了
。
– 单元测试及回归测试
– 例如 :Perl 的编译支持
• make test 进行回归测试
• 测试驱动开发
– ZOLO 4 将要求工程师在编写 FS 时生成 Check
list
11

12. Q&A
12