读书分享：《程序员修炼之道：通向务实的最高境界》的思想经验

相较于全书众多的干货笔记，这篇文章是个别思想经验的总结，希望和大家交流。

能适应使用者的就是好的设计。对代码而言，就是要顺应变化。因此要信奉ETC原则（Easier To Change，更容易变更）——就该如此。

据我们所知，无论是什么设计原则，都是ETC的一个特例。

为什么解耦很好？因为通过隔离关注焦点，可让每一部分都容易变更——此谓ETC。

为什么单一职责原则很有用？因为一个需求变化仅体现为某个单一模块上的一个对应变化——此谓ETC。

为什么命名很重要？因为好的命名可以使代码更容易阅读，而你需要通过阅读来变更代码——此谓ETC！

我们认为，想可靠地开发软件，或让开发项目更容易理解和维护，唯一的方法是遵循下面这条被称为 DRY 的原则：

在一个系统中，每一处知识都必须单一、明确、权威地表达。

每个项目都有自己的词汇表：对团队有特殊意义的术语。“Order”对于开发在线商店的团队来说是一回事，而对于记录宗教团体的世系的应用程序来说，意味着完全不同的另一件事。重要的是，团队中的每个人都知道这些词的意思，并始终如一地使用它们。

一种方法是鼓励大量的交流。如果每个人都参与结对编程，并且频繁地交换结对，那么术语就会渗透性地传播开来。

另一种方法是使用项目术语表，列出对团队有特殊意义的术语。这是一个非正式的文档，可以在 wiki 上创建并维护，也可以将索引卡片挂在墙上。

过一段时间，项目术语将会有自己的生命。随着每个人都熟悉了这些词汇，就能够把这些术语用作简称，准确而简洁地表达许多意思。（这正是模式语言所指。）

新手开发人员经常犯的错误是，把这种对需求的声明照单全收，然后实现对应方案。

根据我们的经验，最初对需求的声明，往往并非绝对化的要求。客户可能没有意识到这一点，但一定希望你能一起去探索。

下面给出一个简单的例子。你在一家出版纸质书和电子书的公司工作。你接到一个新的需求：所有 50 美元以上的订单都应该免运费。停一秒钟，把自己带入这个场景。首先想到的是什么？你有大把机会发现问题：

1、50 美元含税吗？

2、50 美元算没算上本应支付的运费？

3、50 美元必须全是用来买纸质书吗？还是允许在同一订单中有部分电子书？

4、包邮指的是怎样的服务？是加急还是平邮？

5、如果是国际订单如何处理？

6、未来会经常改变 50 美元这个限制吗？

这就是我们所做的。当某些事情看起来很简单的时候，我们却会去寻找那些边缘情况，并就其不胜其烦地问人。

很可能客户已经想到了其中的一些问题，并假定实现将以某种方式工作。问这类问题只是把信息明确下来。但有些问题可能客户之前并没有考虑到。这就是事情变得有趣之处，也能让好的开发人员从此处事老练。

每个人都觉得，地球上只有自己一个好司机。全世界都在闯红灯、实线变道、不打灯就转弯、开车发短信，总之都不符合我们的标准。所以我们需要防御性驾驶。在麻烦发生之前就做好准备，预料到意料之外的事情，永远不要把自己置于无法自拔的境地。

与编程类比，上述理论也明显成立。我们不断地与他人的代码交互，代码可能不符合我们的高标准，或需要处理可能有效也可能无效的输入。所以我们被教导要防御式编程——有任何疑问，都要去验证我们得到的一切信息；使用断言来检测错误数据，不信任任何可能来自潜在攻击者或有恶意者的数据；做一致性检查，对数据库的列设置约束——做完这些，我们通常就会自我感觉良好。

务实的程序员则更进一步，他们连自己也不相信。既然没人能写出完美的代码，那么也包括自己在内。务实的程序员会为自己的错误建立防御机制。我们将在契约式设计中描述第一个防御措施：客户和供应商必须就权利和责任达成共识。

热门相关：仙城纪   寂静王冠   网游之逆天飞扬   明月照大江   网游之逆天飞扬