更佳编程之路: 简介与第 1 章 开发编码指南

文档选项

将此页作为电子邮件发送

级别： 初级

Teodor Zlatanov (), 程序员, Gold Software Systems

2001 年 11 月 01 日

任何软件开发小组的成功或失败很大程度上取决于团队精神。对于构思良好而又不断变化的指导思想而言，从经理到成员，团队是否是一个整体是由它各个部分的和谐程度决定的。在打破完美程序员的神话后，Teodor将解散原有的缺乏创见的软件开发小组，然后再把它建设为一个和谐的，有活力的整体。

欢迎来到 developerWorks 阅读全面指导如何更好地用 Perl编程的系列文章。在这一系列文章的第一部分里，Teodor介绍了他写的书，并以一种崭新的观点来论述编码指南。

这是一本适合 Perl 初学者和中级程序员的书。但即使是 Perl 高级程序员，在看了第 1 部分的技巧、第 2 部分的项目管理工具以及第 3 部分的 Parse::RecDescentsource 代码分析脚本之后，也会发现这些章节的大部分内容是令人兴奋又相当有用的。

程序和 脚本这两个词在这里被交替使用。在 Perl 语言中，二者差不多是一回事儿。程序实际上可以由许多脚本组成，而脚本也可以包含许多程序，但为了简单起见，在使用这两个词时我们这样理解：一个脚本文件只包含一个程序。

第 1 部分主要介绍能提高您 Perl 编程技能的技巧，从最佳编程实践到代码调试都有讨论。它并不教您 Perl 编程。介绍 Perl 编程的书有很多，但这些书在讲解的清晰和全面方面确实做得不很好。

第 2 部分将告诉您如何利用标准的软件项目管理工具更好地管理一个较小的 Perl 软件开发小组。Perl 程序员经常形象化地把软件开发小组称作“一群猫”。第 2 部分将把项目管理工具应用于一个较小的（2 至 6 人）Perl 开发小组，并将研究成功地管理这样的小组与传统的项目管理方法有何不同。

第 3 部分将开发那些分析源代码的工具（将开发 C 和 Perl 的样本）并帮助您更好地管理小组的工具。今天源代码的分析充其量还只是表面的，这些分析包括从明显的和不相关“代码行”度量方法到函数点（function point）（请参阅文章后面的 参考资料），它们对于理解程序员的思想倾向没有帮助。理解程序员的思想倾向将是第 3 部分的目标。将开发一些工具来跟踪度量方法，如：注释的可读性和一致性、代码的复用性和代码的可读性。这些度量将作为软件项目的一部分而不是它的目标来介绍。

没有完美的编程，只有对完美的不断追求。好的程序员每天都会学到新的东西，并且不断提高他们的技术与技能。呆板和僵化永远都是独创性和创造性的天敌。

回页首

程序员最常犯的错误并不在他的程序错误列表中。它与程序员的年龄或选择的程序语言没有任何关系。这个最常犯的错误就是误以为自己具有了所有的能力而且根本 没有提高的余地了。

这可以说成是人的天性；但我认为人的天性是对知识与提高的不断追求。可是，傲慢自大和害怕犯错使我们止步不前。抵制这两种坏习性不仅可以使我们成为更好的程序员，还可以使我们成为更好的人。

我相信，相互沟通以及人员素质是创建成功的软件开发团队的关键，这比任何其它因素都重要。不断提高程序员的技能和接受批评的能力对一个软件开发团队的成员来说是基本的要求。这些要求优于所有其它的要求。

回想一下您上一次改变风格的情况。您是运用了学到的新算法，还是新的注释风格，或仅仅是以另一种方法命名变量？不管是什么，对于完成代码并使它完美这个目标而言，它只不过是前进路途上的一步而不是结束。

不应该要求程序员一字一句地遵守精确的编码指南；而程序员也不应该为了完成任务而仓促应付这些指南。想象一个管弦乐队 ― 既不能是一些死气沉沉、毫无激情的演奏者，也不能是一些草率地即兴发挥的演奏家（尽管后者更容易受到欢呼）。一个死气沉沉的演奏者仅仅照着乐谱而没有把精力和感情投入到音乐中；演奏家则必须约束自己，不能在演奏时随意尝试新的旋律片段或按自己的节拍演奏。

回页首

编码指南更象一个音乐家遵守的书面格式的乐谱 ― 何时演奏、何时停止、演奏得多快、什么节拍等等。而音调本身，打个不恰当的比方，就是项目的目标 ― 有时是独立的高音，有时则是乐器的和声。

在管弦乐队中，指挥负责指挥但并非告诉每个乐手应该如何演奏，每个人都是整个演奏的一部分。指挥负责协调。因为音乐在编程技术出现以前已经存在了好几个世纪，所以或许有值得借鉴的经验。软件项目经理既不是“暴徒”也不是“越狱的罪犯”。她和其他的人一样是团队的一个成员。

不必盲目地把本系列文章所介绍的指南摘录出来作为正式的编码原则。您项目的编码标准就是您自己的，它们真实反映了您自己的“管弦乐”的乐谱。不要强求程序员们做得完全正确，这样只会造成一种不信任和畏惧的气氛。对于极小的错误，您不必在代码重审或追究责任上斤斤计较。

取而代之的是，介绍这些指南并且观察大家的反应。如果没人采用您喜欢的注释格式，那它可能就是一种不好的格式。如果您觉得大家编写程序时显得不太聪明，那么可能是您编写指南时太过聪明。如果您认为人人都应该使用的调试器呆在布满灰尘的房间里还没被拆开，那么请重新考虑对 Whizzo Debugger 3.4 的需求。或许每个人都因为某种原因更喜欢使用 Acme Debugger 1.0。

当然，程序员有时会毫无原由地很固执，其实只是不愿变革。很难使人们相信 20 年的经验并不能给他们组织有序的思想。另一方面，刚参加工作的大学毕业生经常会显得缺乏自信。承认并适应这些特征，以及团队中所有其它的特征。把想法介绍给较顽固的经验丰富的成员时，要使他们觉得自己是在帮着做这件事。通过指导和支持使大学毕业生树立起信心，直到他们能独立发挥作用。

回页首

编码指南对于一个软件团队，正如指挥和和声对于音乐一样，是基本的。它们产生一致性和凝聚力。新成员会感觉受到欢迎并能更快地融入到团队中。老成员则将更乐意接纳这些新来者。如果缺少一位成员，正如因为一个人不能理解另一个人的代码，将不会使项目限于瘫痪境地。

请牢记速度并不是衡量程序代码改进的唯一尺度。对于任何软件项目，特别是长期项目，易测试、易编制文档和易维护也是很重要的。象 Perl 这样灵活的语言有助于在软件项目的各个阶段中进行良好的编码。尽管本书关注的是 Perl，但其中的许多原则也适用于其它语言，如 C、C++、Java 和 Python。

最后，请做一个革新者。不论您在团队中的职位 ― 经理或成员 ― 请不断寻找新的想法并实践它们。完美或许不太可能，但它却是值得尝试的目标。革新者是团队的真正力量，如果没有他们那么悦耳的音调很快会变得乏味。和同行保持联系；不断从他们那儿学习新东西。象 Usenet 那样的媒体（请参阅 参考资料）是交换意见的好地方。相互指导，相互学习。请记住一点，总会有提高的余地。最重要的，开心一点，然后让音乐响起。

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 请阅读 Capers Jones 所著的 （McGraw-Hill）。
  
  
  
• 请阅读 ，并请查看 。
  
  
  
• 请查看 。
  
  
  
• 请在 developerWorks的 “Cultured Perl”系列中阅读 Teodor 的其它有关 Perl 的文章：
  • A programmer's Linux-oriented setup
  • Application configuration with Perl
  • Automating UNIX system administration with Perl
  • Debugging Perl with ease
  • The elegance of JAPH
  • Genetic algorithms applied with Perl
  • One-liners 101
  • Parsing with Perl modules
  • Perl 5.6 for C and Java programmers
  • Reading and writing Excel files with Perl
  • Review of Programming Perl, Third Edition
  • Save it with Perl
  • Small observations about the big picture
  • Writing Perl programs that speak English
  
  
• 请浏览 developerWorks上 更多 Linux 的参考资料。
  
  
  
• 请浏览 developerWorks上 更多开放源码的参考资料。
  

		Teodor Zlatanov 于 1999 年毕业于美国波士顿大学，获得计算机工程理学硕士学位。从 1992 开始，他就成为了一名程序员，使用 Perl、Java、C 和 C++。他对文本分析的开放源码工作、3 层的客户机服务器数据库体系结构、UNIX 系统管理、CORBA 和项目管理都很感兴趣。可以通过 与 Teodor 联系。