hnxxcxg可撤消性.txt

f your application uses MFC in a shared DLL, and your application is in a language other than the

如果某个想法是你惟一的想法，再没有什么比这更危险的事件了。

工程师们喜欢问题有简单、单一的解决方案。

没有什么永远不变——而如果你严重依赖某一事实，你几乎可以确定它将会变化。

要实现某种东西，总有不止一种方式，而且通常有不止一家供应商可以提供第三方产

品。

如果你认为只有一种实现方式的观念所牵绊，你也许就会遇到让人不悦的意外之事。

问题在于，关键决策不容易撤消。

一旦你决定使用这家供应商的数据库、那种架构模式、或是特定的部署模型，除非付

出极大的代价，否则你就将受制于一个无法撤消的动作进程。

我们不必做出许多关键的、不可逆转的决策。因为我们并非总能在一开始就做出最好

的决策。我们采用了某种技术，却发现我们雇不到足够的具有必需技能的人。我们刚

选定某个第三方供应商，他们就被竞争都收购了。与我们开发软件速度相比，需求、

用户以及硬件变得更快。

大多数时候，对第三方产品的调用都缠绕在代码各处。但如果你真的已经把数据库的

概念抽象出来——抽象到数据库只是把持久作为服务提供出来的程度——你就会拥有

“中流换马”的灵活性。

错误在于假定决策是浇铸在石头上的——同时还在于没有为可能出现的意外事件做准

备。

要把决策视为是写在沙滩上的，而不要把它们刻在石头上。大浪随时可能到来，把它

们抹去。

不存在最终决策。

你需要设法保持代码的灵活性，考虑维持架构、部署及供应商集成等领域的灵活性。

你可以把第三方产品隐藏在定义良好的抽象接口后面。

没有人知道未来会怎样，尤其是我们。所以要让你的代码学会“摇滚”：可以“摇”

就“摇”，必须“滚”就“滚”。

为未来编码很困难。

每一项决策都会导致不同版本的未来。你的代码能支持多少种可能的未来？哪一种未

来更有可能发生？到时支持它们有多困难？

你敢打开盒子吗？