你是否 diss 过别人的代码？—— 怎样的代码才算优秀？
你一定在内心吐槽过他的代码太烂：没注释、逻辑混乱、到处都是 magic number、实现方案过时、耦合严重、一改就出 bug。
此时心中的怒火油然而生，仿佛自己是正义的化身，要代表月亮消灭这样的代码，甚至拼写错误也可以成为你 diss 的点。稍等片刻，先抑制一下燃烧的小宇宙，你有没有认真想过“到底什么样的代码才算的上优秀？”
在看了 Gerald M. Weinberg 的《The Psychology of Computer Programming》后让我有了不一样的认识。不过我觉得这是一个开放问题，不同情况下会有不同答案，欢迎讨论。
可行性
作者给出的第一个标准是“程序的可行性”，它是指对于任何一种约定的输入，程序都能给出期望的输出。毕竟可行的程序总比不可行的要好。在不满足可行性前提下的优越性能，高可扩展性都不值一提。
但不可否认的是，我们脑子里成天考虑的是这些次要问题。甚至会形成“不优雅就是垃圾”的价值观，好像只有这样才可以在内心自恃高人一等。获得这种莫须有的优越感的代价可能是写出了不可行的代码，捡了芝麻丢了西瓜。
引用一段原文：
如果程序根本无法正常运转，对其效率、适应性及生产成本的评估就毫无意义。无论如何，我们需要务实一些，需要承认：也许根本没有哪个完美的程序曾经被写出来过。每一个真正大型和重要的程序都必然包含很多个纰漏。所以对程序进行评估时，必须考虑到其不完美的一面。
按时性
作者给出的第二个标准是“按时性”。
即使不考虑可行性的问题，效率的问题仍然不是最重要的。程序开发中经常遇到一个问题是要符合开发的日程计划，推迟完成的程序常常没有意义。
我们不得不比较一下，到底是一个可能在未来完成的高效程序带来的潜在节省更大，还是没有一个程序损失更大。现实中，往往是后者的损失更大。
真正困扰人们的并非是预先估计的平均开发时间，而是实际消耗时间的标准偏差。就好比大多数人宁可每天早上花固定的10分钟等公交车，也不愿意每周有4天只等1分钟，而最后一天等26分钟，尽管就平均等待时间而言，后一种方案只需要6分钟，但由于某次无法预测的长时间等待就会打乱计划，这点好处无法弥补其损失。所以宁可承诺一个更留有余地的排期，然后按时完成。而不是承诺一个满打满算的排期，然后delay。
开发过程中遭遇的各种意外导致实际消耗时间和预估时间形成方差，这一问题是值得我们深入思考的。如何提前感知不确定性，如何快速解决意外，是一项需要不断提升的能力以减小方差。
适应性 & 效率
作者给出的第三个标准是“适应性”，即程序的可扩展性。紧跟其后的标准是“效率”，即程序运行的性能。
总算轮到了本以为重要的标准，作者的一席话描述地入木三分：
在软件生命周期内，多数程序都会被修改，无论其经验的多少，绝少有哪位程序员能反驳这一论断。既然如此，为什么在必须修改以前的程序时，我们总是觉得这项任务如此艰巨，以至于往往决定弃之不用，干脆自己从头写起呢？只要阅读过程序，我们就会透过这些程序发现：实际上，很少有哪位原作者会考虑可能的后续修改。
作者还提了两个问题来表达程序员的矛盾之处：
在编写程序时，你曾经有多少次想到过它在未来可能被别人修改？反过来，在修改别人程序时，你又曾经咒骂够几回？
之所以把适应性和效率放在一起讨论，是因为它们俩会此消彼长，作者用 Fisher 定理来证明这个观点：
Fisher定理：一个系统对某一特定环境适应性越强，它适应新环境的能力也就越弱。
如果强调的是程序的效率，那么我们往往会追求紧密式的代码，而如果在未来要对这些代码进行修改，那将会非常棘手。如果使用的是更高层的语言，那么为了使程序更高效，我们往往需要深入到机器语言层。这种做法至少抵消了原本用更高层语言编程的一个好处 —— 在不同机器之间的可移植性。其实际效果是，我们将被局限于特定的某台计算机或特定的某个实现。
回想设计模式，无一例外是通过增加一层抽象以达到可扩展的目的，这样的设计增加了类的数量，类的构建和类方法调用的都会消耗空间和时间的性能，降低了效率。而且它让功能的实现变得更加间接，也增加了理解成本，降低了沟通效率。
但作者认为性能问题不是问题：
运行效率正在成为计算中一个日益不明朗的问题，随着单位计算能力成本的逐年下降，以及单位程序开发成本的不断提高，在程序开发方面比在产品方面投资更多的典型做法，早已不合时宜。因此我们期望，随着岁月的推移，我们听到的关于效率的言论将会越来越少。
紧接着依然是两个耐人寻味的问题：
你是否曾经因为追求效率而延误了工作进度？反过来，是否曾经因为要赶时间完成而没有做到尽善尽美？
但有趣的是，面试时，极少有公司是按照上述的优先级来考察候选人的，通常的考察优先级正好相反，即使有算法笔试也是把重点放在实现方案的内存性能或时间性能上，并不会对程序的正确性进一步追究。
