美国肯塔基州法律条文规定：“任何一个女人都不能穿着游泳衣出现在本州的公路上，除非她身边有至少两个警察护送，或者她手中拿着一根棍棒。”这条法律条文的后面又画蛇添足地补充道：“这条法律条文不适用于那些体重低于90磅(约40公斤)或体重超过200磅(约90公斤)的女性，当然它也不适用于母马。”

美国应该算是是一个法制比较健全的国家，但是由于太过健全，立法者也就设立如此令人啼笑皆非的条文，虽然令人喷饭搞笑，但是其的确存在于美国的地方法律条文中，因此在理论上来说它们依然有效。

相信所有的软件公司都有各种类型的开发要求和编码规范性文档，这些文档主要针对开发过程中的各种工作行为做一个规约性的要求，其作用也就不言而喻。对于软件开发过程中几乎所有的团队都在使用这些规范，有编码规范，开发环境设定文档，还有各种工作约定的规范文档，但是其效果可能有天壤之别。作为项目经理，那么在项目启动之前，这些规范文档的选取和制定也需要一定的技巧。

当我们在制定这些开发规约的时候，首先注意需要注意的是这些开发规范的尺度，也就是说所要制定的的开发规范需要详细到哪种程度，是否是面面俱到，和法律文书一样周全严禁；还是说蜻蜓点水，点到而止。甚至有不少公司从网络直接下载下别人现成的开发规范，拿来己用，那么我们在制定这种文档的时候需要注意的问题有那些呢？

公司已经确认项目可以进行，从现在到项目的实际开始还有一段时间，人员的招聘目前HR还在想方设法去完成，但是对于项目组内部来说，这段时间需要我们做的事情也是非常繁琐和重要，首先需要考虑到人员进来之后的再次培训工作，虽然公司已经对进来的人员有一个针对公司制度和文化的培训，但是还缺乏一些工作性质的培训，特别是这个项目的人员既有新人、外项目组的、外驻人员，如此的团队有必要在项目开始前进行一些列的培训，所以培训材料的准备也是计划中的一部分，还有开发中的开发规范和工作准则等等，这些都是前期文档性的东西，一起虽然都由，但是还是需要安排人员整理。

我叫上大师、老马到会议室去确认开发规范的事情，他们进到会议室便随意找了个椅子坐下，老马端着他那超大号的茶杯喝着。

“新的项目预计是在下个月中开始，现在我们所要做的就是前期的准备工作，我想和你们俩确认一下我们的开发规范等文档还存在什么问题？”我也没有任何寒暄，直接说道。

“你说编码规范么?”大师问道？

“我们不是有现存的编码规范，而且挺详细的。”老马说道。

“我们项目组现在是有现成的开发规范，而且还不止一个版本。这些版本应该都是从网上收刮来的，有微软的，也有不止何人指定的，总的说也是挺全面的。”我回答道。

老马看了看我，狐疑地问道：“那还需要改吗？”

“其实我们回头想想看，现在我们的开发规范有用吗？估计我们大家都没有人能够清楚那些规范要求的是什么？而且这个规范到目前为止也只是成了一个摆设。”

大师点点头：“是有点过，学起来也比较累。”

“那我们是需要重新再指定一个开发规范吗？”老马狐疑地问道。

“也不是，我在想是不是可以把现在的开发文档做一个精简？大概上保留两到三张纸的量就可以了。”

“两到三张纸？”老马好像更疑惑不解了，“如果只有这么一点内容，有点太简单了，很多的内容就描述不到，到时候还有可能出现问题。”

“其实在两到三张纸的这个范围内指定开发规范，我们就不可能做到面面俱到地考虑问题，把关键性和常用性的内容考虑到就可以了，比如说开发规范中的命名规范，常见的变量定义要求，和常见的函数定义要求等。所有的考虑点都是使用频率最高，最广泛的内容，不要把所有的特殊现象都写到里面，那么两到三张纸还是可以应付。”我回答道。

“如果这样的话，作为开发规范那么其中的漏洞也太大了，到时候我们怎么拿这个规范去要求其他的开发人员？”老马也有点疑问，不解地问。

“其实我也一直在考虑这个问题，如果说我们的开发人员有良好的开发习惯的话，那么这些规范对于他们来说作用不太大，因为他们的做事方法已经达到我们的开发要求。开发规范的主要作用就是说统一整个团队的风格，尽量保证开发出来代码的质量。理想情况下，整个团队所有人写出来的代码就像出自一人之手，但是可能性很小，在整个团队中，如果希望做到所有的风格一致，那么我们可能做出来的开发规范可能就需要做到想法律文书一样，厚厚一本。”

“哈哈。”老马笑了笑，“那估计该成立一个开发标准专业，让他们用四年时间去学。”

“所以我做了一个权衡，我们允许出现部分的问题，但是这些问题量应该控制在一个范围内，比如说某些比较特殊的处理和定义，这些内容在开发规范中并没有定义，因为其出现的概率很低。能保证所我们常见的那些规范都考虑到了，就足够了。同时尽量减少多义性和建议性的部分内容，那么开发规范就少多了。”

“恩，两到三张纸，开发规范，命名要求，代码书写风格。”大师是乎在自言自语。“够用就行。”

对于项目开发过程中选择开发规范的时候，其可选择性和考虑的问题也比较多，那么当我们在尝试指定这些规约性的时候，其内容的覆盖程度不能作为主要的考虑点，我们更多需要考虑这些文档的学习成本和实用性。如果说所有的问题都考虑到了，细节性问题，突发性问题等等，那么规范内的条款也就会对应增加，那么对于团队的成员在学习这些规范的时候，其学习的周期就会比较长，而且由于其中规定的内容比较多，学习之后的遗忘量也就比较大，很难让他们做到完全记住，并且能够贯彻使用。由于学习周期比较长，那么学习成本也就非常高，之后的遗忘，那么规范的实用性也就较差。

有时候我们在做事情的时候，往往容易为了百分之五的问题，而投入了百分之九十的精力，而且当这百分之五是属于偶然性的问题的时候，那么这种投入就更没有价值。如果我们希望追求完美，那么在这种项目开发过程中并不适用，所以不论指定开发规范也好，还是制定工作要求也好，只要能够被彻底、坚持执行的规范才算是有意义，否则都是一纸空文，其作用也不过是为了事后应付差事罢了。

项目经理在指定这些规范，实用性、学习周期、可执行度都需要考虑一番，所以不论是从网上下载的也好，还是自己从头制定也好，能把这些问题都考虑到了，做出一个权衡之后选择适合自己团队的规范性文档，一切一切只要够用就好，切莫追求完美主义。