可持续发展的程序设计

        为什么很多程序被用户用了一次就扔掉？一方面在中国，软件基本上是不花钱的；另一个方面，用户往往只有单次的功能需求。不过，本文并非讨论如何避免这种事情发生，而是要站在程序员的角度去考虑另外一个类似的问题：很多我们曾经写过的代码被自己用了一次就扔掉。

       代码“即用即抛”的习惯使我们开始一个新的项目就意味着白手起家，重头再来。实际上我们是希望自己的代码高度可重用的。写过的代码如果都能在此后的项目中加以利用，那将是一件非常美妙的事。想要真正实现这个愿望其实并不难，只要你学会可持续发展地设计程序即可。

       代码重用实际上是软件工程中已被充分考虑过的问题。组件技术以及我们乐于使用的第三方类库都是代码重用的体现。但是我们就不能考虑自己的代码重用吗？我的一位朋友，在某家企业的运维部工作，他时常抱怨部门里可用的自动化脚本奇缺，以至于自己每天都淹没在“人肉”的维护工作之中。这意味着大量的索然无味的重复性工作。我的那位朋友并不准备“坐以待毙”，他现在(今天周六)正在加班，埋头写着各种自动化脚本。我认为这与程序员的代码重用有十足的类似性。程序员应当让自己的代码更具重用性，以避免毫无意义的重复性工作。

       如何去做？Scott Meyers在《More Effective C++》条款32中给我们提供了非常精彩的参考。条款32鼓励程序员在未来时态下进行程序开发，力求使自己的代码更有弹性、健壮性和高可信赖度。所谓“在未来时态下”即开发程序的过程中充分考虑可能的变化，他总结了一些与此相关的忠告：

(1) 软件的维护人员往往不是那款软件的开发人员，因此一位优秀的开发人员应该留意这个问题，让自己编写的代码适合阅读、易于理解、便于维护；

(2) 如果你想明确禁止Class的某些行为，不要单单依靠文档或注释，利用C++的语言特性去实现吧。比如你要禁用某个Class的拷贝构造和赋值操作，就应该明确设定它们为private，这比你在源代码中添加大篇幅的警告更有现实意义；

(3) 不要突发奇想，而要谨慎地去设计。软件开发不仅是编码，若如此程序员真的就只是“码农”而已了。软件开发至少包括软件设计和软件实现两个过程。请重视软件的设计，你需要更谨慎地对待它。多考虑你的设计是否完备，是否还有漏洞，某种新功能的实现是否带来副作用等；

(4) 别存侥幸心理，凡是用户能够做的，用户肯定会做。只要编译器允许，即使逻辑上有错误的事，用户也会去做。要接受“用户会犯错”这个现实，因此不要侥幸地认为用户不会走入雷区而让自己轻松悠然，多花时间和精力去完善自己的设计吧；

(5) 偶尔也要考虑一下软件的平台移植性，如果你在操作系统上押错了宝，可能等待你的将是彻头彻尾的失败。

       上面的这些忠告的确出于理性地经验总结，但是它并不是让你在未来时态下思考问题。从实际出发仍然很重要！不要等着编译器厂商实现了某种你期待的C++标准特性之后才动手实现你的设计，你的等待可能很漫长，黄花菜都凉了；不要脱离了当前用户的实际，不要强迫用户更改自己的操作系统或者升级自己的硬件，你应该做的是在当前的条件下实现用户需要的功能；不要对用户承诺多久之后你的软件有多么巨大的性能提升，那并不会给用户带来任何温暖，你要想着如何让自己美妙的想法尽快实现，尽快推向市场，尽早转化为财富。

       当你被拉回到现实中来，你可能会觉得很操蛋。是不是上面的忠告都是站着说话不腰疼。或许是吧，不过即便你非常注重用户当前的需要，也不要忘记留意一下自己的需要。重用代码会给你省下不少的时间和精力，让你周末不用加班写着重复的代码。留意自己的需要，让自己的代码具有可重用性，记得以下3点：

  (I) 完整地实现Class，哪怕有些功能你现在还用不到呢，完备的Class才具有通用性；

 (II) 设计好Class的接口，你想要对外禁用的接口就设置为private吧；

(III) 尽可能让你的代码更具通用性，必要时使用C++模板编程。