Unix基本哲学

，过早的局部优化实际上会妨碍全局优化（从而降低整体性能）。在整体设计中可以带来更多效益的修改常常会受到一个过早局部优化的干扰，结果，出来的产品既性能低劣又代码过于复杂。

    在Unix世界里，有一个非常明确的悠久传统（例证之一是Rob Pike以上的评论， 另一个是Ken

    Thompson关于穷举法的格言）：先制作原型，再精雕细琢。优化之前先确保能用。或者：先能走，再学跑。“极限编程”宗师Kent

    Beck从另一种不同的文化将这一点有效地扩展为：先求运行，再求正确，最后求快。

    所有这些话的实质其实是一个意思：先给你的设计做个未优化的、运行缓慢、很耗内存但是正确的实现，然后进行系统地调整，寻找那些可以通过牺牲最小的局部简洁性而获得较大性能提升的地方。

    制作原型对于系统设计和优化同样重要——比起阅读一个冗长的规格说明，判断一个原型究竟是不是符合设想要容易得多。我记得Bellcore有一位开

    发经理，他在人们还没有谈论“快速原型化”和“敏捷开发”前好几年就反对所谓的“需求”文化。他从不提交冗长的规格说明，而是把一些shell脚本和

    awk代码结合在一起，使其基本能够完成所需要的任务，然后告诉客户派几个职员来使用这些原型，问他们是否喜欢。如果喜欢，他就会说“在多少多少个月之

    后，花多少多少的钱就可以获得一个商业版本”。他的估计往往很精确，但由于当时的文化，他还是输给了那些相信需求分析应该主导一切的同行。

    —Mike Lesk

    借助原型化找出哪些功能不必实现，有助于对性能进行优化；那些不用写的代码显然无需优化。目前，最强大的优化工具恐怕就是delete键了。

    我最有成效的一天就是扔掉了1000行代码。

    —Ken Thompson

    （我们将在第12章对相关内容进行深一步讨论。）

    1.6.16 多样原则:决不相信所谓“不二法门”的断言

    即使最出色的软件也常常会受限于设计者的想象力。没有人能聪明到把所有东西都最优化，也不可能预想到软件所有可能的用途。设计一个僵化、封闭、不愿与外界沟通的软件，简直就是一种病态的傲慢。

    因此, 对于软件设计和实现来说，Unix传统有一点很好，即从不相信任何所谓的“不二法门”。Unix奉行的是广泛采用多种语言、开放的可扩展系统和用户定制机制。

    1.6.17 扩展原则: 设计着眼未来，未来总比预想快

    如果说相信别人所宣称的“不二法门”是不明智的话，那么坚信自己的设计是“不二法门”简直就是愚蠢了。决不要认为自己找到了最终答案。因此，要为数据格式和代

    码留下扩展的空间，否则，就会发现自己常常被原先的不明智选择捆住了手脚，因为你无法既要改变它们又要维持对原来的兼容性。

    设计协议或是文件格式时，应使其具有充分的自描述性以便可以扩展。一直，总是，要么包含进一个版本号，要么采用独立、自描述的语句，按照可以随时插

    入新的、换掉旧的而不会搞乱格式读取代码的方法组织格式。Unix经验告诉我们：稍微增加一点让数据部署具有自描述性的开销，就可以在无需破坏整体的情况

    下进行扩展，你的付出也就得到了成千倍的回报。

    设计代码时，要有很好的组织，让将来的开发者增加新功能时无需拆毁或重建整个架构。当然这个原则并不是说你能随意增加根本用不上的功能，而是建议在

    编写代码时要考虑到将来的

需要，使以后增加功能比较容易。程序接合部要灵活,

    在代码中加入“如果你需要……”的注释。有义务给之后使用和维护自己编写的代码的人做点好事。

    也许将来就是你自己来维护代码，而在最近项目的压力之下你很可能把这些代码都遗忘了一半。所以，设计为将来着眼，节省的有可能就是自己的精力。