第2章 注重实效的途径 A Pragmatic Approach
7. 重复的危害
系统中的每一项知识都必须具有单一、无歧义、权威的表示。
提示11: DRY-Don't Repeat Yourself
不要重复你自己
提示12: Make It Easy to Reuse
让复用变得容易
8. 正交性
提示13: Eliminate Effects Between Unrelated Things
消除无关事物之间的影响
编写正交的系统的主要好处:
- 提高生产率。改动得以局部化，所以开发时间和测试时间得以降低。
- 降低风险
在工作中应用正交原则的几种方式:
- 项目团队
- 设计
- 测试
- 文档
若干技术用于维持正交性：
- 让你的代码保持解耦
- 避免使用全局数据
- 避免编写相似的函数
9. 可撤消性
如果某个想法是你唯一的想法，再没有什么比这更危险的事情了。——Emil-Auguste Chartier, Propos sur la religion,1938
"错误在于假定决策是浇铸在石头上的——同时还在于没有为可能出现的意外事件做准备。""
"要把决策视为是写在沙滩上的，而不要把它们刻在石头上。大浪随时可能到来，把它们抹去。""
提示14: There Are No Final Decisions
不存在最终决策
"没有人知道未来会怎样，尤其是我们！所以要让你的代码学会“摇滚”：可以“摇”就“摇”，必须“滚”就“滚”。"
10. 曳光弹
提示15: Use Tracer Bullets to Find the Target
用曳光弹找到目标
曳光代码方法有许多优点：
- 用户能够及早看到能工作的东西
- 开发者构建了一个他们能在其中工作的结构
- 你有了一个集成平台
- 你有了可用于演示的东西
- 你将更能够感觉到工作进展
11. 原型与便笺
"原型的设计目的就是回答一些问题，所以与投入使用的产品应用相比，它们的开发要便宜得多、快捷得多。"
提示16: Prototype to Learn
为了学习而制作原型
在构建原型时，你可以忽略哪些细节:
- 正确性。你也许可以在适当的地方使用虚设的数据。
- 完整性
- 健壮性
- 风格
一些你可以在架构原型中寻求解答的具体问题：
- 主要组件的责任是否得到了良好定义？是否适当？
- 主要组件间的协作是否得到了良好定义？
- 耦合是否得以最小化？
- 你能否确定重复的潜在来源？
- 接口定义和各项约束是否可接受？
- 每个模块在执行过程中是否能访问到其所需的数据？是否能在需要时进行访问？
12. 领域语言
语言的界限就是一个人的世界的界限。——维特根斯坦
提示17: Program Close to the Problem domain
靠近问题领域编程
13. 估算
提示18: Estimate to Avoid Surprises
估算，以避免发生意外
"π的值是多少？
如果你想知道的是要买多少饰边，才能把一个圆形花坛围起来，那么“3”很可能就足够好了。
如果你在学校里，那么“22/7”也许就是一个好的近似值。
如果你在NASA （美国国家航空航天管理局），那么也许要12个小数位。"
提示19: Iterate the Schedule with the Code
通过代码对进度表进行迭代
网友评论