追求完美程序员最常犯的错误并不在他的程序错误列表中。它与程序员的年龄或选择的程序语言没有任何关系。这个最常犯的错误就是误以为自己具有了所有的能力而且根本 没有提高的余地了。
这可以说成是人的天性；但我认为人的天性是对知识与提高的不断追求。可是，傲慢自大和害怕犯错使我们止步不前。抵制这两种坏习性不仅可以使我们成为更好的程序员，还可以使我们成为更好的人。
我相信，相互沟通以及人员素质是创建成功的软件开发团队的关键，这比任何其它因素都重要。不断提高程序员的技能和接受批评的能力对一个软件开发团队的成员来说是基本的要求。这些要求优于所有其它的要求。
回想一下您上一次改变风格的情况。您是运用了学到的新算法，还是新的注释风格，或仅仅是以另一种方法命名变量？不管是什么，对于完成代码并使它完美这个目标而言，它只不过是前进路途上的一步而不是结束。
不应该要求程序员一字一句地遵守精确的编码指南；而程序员也不应该为了完成任务而仓促应付这些指南。想象一个管弦乐队―既不能是一些死气沉沉、毫无激情的演奏者，也不能是一些草率地即兴发挥的演奏家（尽管后者更容易受到欢呼）。一个死气沉沉的演奏者仅仅照着乐谱而没有把精力和感情投入到音乐中；演奏家则必须约束自己，不能在演奏时随意尝试新的旋律片段或按自己的节拍演奏。
演奏和谐的音调编码指南更象一个音乐家遵守的书面格式的乐谱 ―何时演奏、何时停止、演奏得多快、什么节拍等等。而音调本身，打个不恰当的比方，就是项目的目标― 有时是独立的高音，有时则是乐器的和声。
在管弦乐队中，指挥负责指挥但并非告诉每个乐手应该如何演奏，每个人都是整个演奏的一部分。指挥负责协调。因为音乐在编程技术出现以前已经存在了好几个世纪，所以或许有值得借鉴的经验。软件项目经理既不是“暴徒”也不是“越狱的罪犯”。她和其他的人一样是团队的一个成员。
不必盲目地把本系列文章所介绍的指南摘录出来作为正式的编码原则。您项目的编码标准就是您自己的，它们真实反映了您自己的“管弦乐”的乐谱。不要强求程序员们做得完全正确，这样只会造成一种不信任和畏惧的气氛。对于极小的错误，您不必在代码重审或追究责任上斤斤计较。
取而代之的是，介绍这些指南并且观察大家的反应。如果没人采用您喜欢的注释格式，那它可能就是一种不好的格式。如果您觉得大家编写程序时显得不太聪明，那么可能是您编写指南时太过聪明。如果您认为人人都应该使用的调试器呆在布满灰尘的房间里还没被拆开，那么请重新考虑对Whizzo Debugger 3.4 的需求。或许每个人都因为某种原因更喜欢使用 AcmeDebugger 1.0。
当然，程序员有时会毫无原由地很固执，其实只是不愿变革。很难使人们相信20年的经验并不能给他们组织有序的思想。另一方面，刚参加工作的大学毕业生经常会显得缺乏自信。承认并适应这些特征，以及团队中所有其它的特征。把想法介绍给较顽固的经验丰富的成员时，要使他们觉得自己是在帮着做这件事。通过指导和支持使大学毕业生树立起信心，直到他们能独立发挥作用。
所有的这些，难道只是为了几条编码指南吗？编码指南对于一个软件团队，正如指挥和和声对于音乐一样，是基本的。它们产生一致性和凝聚力。新成员会感觉受到欢迎并能更快地融入到团队中。老成员则将更乐意接纳这些新来者。如果缺少一位成员，正如因为一个人不能理解另一个人的代码，将不会使项目限于瘫痪境地。
请牢记速度并不是衡量程序代码改进的唯一尺度。对于任何软件项目，特别是长期项目，易测试、易编制文档和易维护也是很重要的。象Perl这样灵活的语言有助于在软件项目的各个阶段中进行良好的编码。尽管本书关注的是Perl，但其中的许多原则也适用于其它语言，如 C、C++、Java 和Python。 |
