beyondyf都开了这么好的头 那的确值得参与一下
我对华为也很大的敬意 这个敬意来源很单一也很简单 就是上次看激荡三十年中对华为老板的描述：跑项目完全不靠关系，只追求服务质量；任正非基本不上任何媒体，踏踏实实做事。
说回到规范，先描述下自己的经历，写的很多，主要是突然想对这几年的经历做做总结，可能会有很多跑题：
大学前对代码规范一直认可但没认真去理解和学习，刚毕业的时候进入一家专注做产品的软件公司。他们的软件很多都开发了快十载，经历反复修改、多次重构，项目规模很大。刚进入公司的时候，公司用大把的时间纠正我们的C/C++编程规范，让我们看高质量C/C++编程指南那个文档，当时要求很吓人，也没几个能达到的，最难达到的就是让我们所有函数内部实现都是先写注释后写代码，还有我们老板提出一个更狠的要求，就是要在每行前加类似章节的序号。当时做简单的东西感觉无所谓，还可以实现，但是对于比较复杂、规模很大的程序上就力不从心了，尤其从新人到就职岗位后，发现同事们也没几个乖乖听的。
我后来分到的那个产品组，十多人开发维护七八年的三维软件，还有测试组不停的测试，规模很大。但是在那么多年中，一直没什么文档，5000多个文件，编译一次四核机器都要七八分钟（当时还偷懒靠这个小睡一会儿，可惜被老板堵到两次），还好项目组组长一直跟着这个项目搞了五六年，不明白就问就OK。可是经历这么多年，很多函数都是经过多人维护，而且大多都没有注释，结果经常是函数头一个变量某明奇妙加一个2，这个函数的几十行之后这个变量又被减去了3，问组长（其他公司叫项目经理），组长回答是这俩人早就辞职很多年了，你自己跟踪调试下看看是干啥的吧。另外还有个故事，这个组长的上一任，据说是公司技术最强的人，这个项目上一次重构就是那个人一个人一个月写的，那个月其他人一点儿活儿没干，后来这个组长被公司开除了，据说是因为侮辱组员（好像就是说了几句他技术不行的话）。据说这个人写算法（包括三维算法）从来就没用过纸，完全拍脑袋，然后那些类和函数大家用了很多年，从来没错过。
那个公司算是很注意项目管理的，老板大部分时间是窝在公司想如何管理规范和如何做新软件，公司有几个独立项目组是专门做软件项目管理软件的。vss、svn这类版本管理软件都是公司自己开发的，一个是为了安全，另一个是为了更好的和其他公司管理系统融为一体。版本管理、bug追踪系统、项目跟踪系统、代码审核系统、学习培训系统、公司内部论坛等等，都是公司自己开发，而且大家用的很习惯，感觉也很有帮助。
从那个公司出来，就一直是自己做项目，没有了那些管理系统的辅助，感觉很不适应。商务处理、需求分析、软件设计、进度管理、项目实施、外部合作、测试维护等等，除了项目实施带几个人搞，其他的都是一个人负责，那个时候才知道，做一个软件有多难，有多累，处理的事情多了，很难把程序写好，经过长时间的消磨，代码规范也一点点的不再重视了。因为着急出版本，所以必须要在短时间内定目标、定方法，那么在模块划分上就很粗糙，都是做的时候再想都需要写什么函数什么属性，所以完全不去顾及什么代码注释的问题了。完成第一个项目的一个版本后，中间又隔了一年，软件又需要维护，我自己再去看一年多前写的东西，很多地方都不知道为什么，看了半天才看明白，经常是改过来给客户，客户发现又有问题，我再改，发现又回到当初的方法了，才明白当年为什么要用这个方法。很简单的东西，都要维护很长时间。
在此期间我也做过一些接维护的项目，当时最夸张的是那个十多年的程序员，那MFC写的是相当飘逸，变量拼音缩写加英语命名，菜单都是模态对话框实现，最要命的是成片的全局指针和大量的内存泄漏，注释，想找到得全局搜索//才能看到几行。我带去的几个MFC程序员，技术很好，但是做了几天那个项目就都干不下去了，都表示一天干八个小时都比加班到凌晨累，而且还学不到什么东西。
之后我又做其他项目，弄到项目后交给其他公司团队做，做之前都约束好了代码规范要求，商务上也都答应了，合同上都写了，可是到了执行，完全不是那么回事儿。最夸张的是我说要求用php，签完了合同他们竟然整个项目用java写，完全没通知。之后的事情就更头疼了，不按期不完成不反馈，最要命的是竟然还说自己多么的诚信、负责，一直在声明自己是老实人，但死活不承认项目没按时按量完成，我问你看过软件么，他回答是“我为XXX了，他告诉我都做了！”，那我就没什么好说的了。自己拿回来接手，真是佩服，这个项目也是个十多年的程序员搞的，注释？说别的吧，人家很牛，用记事本写代码，那水平，完全是在创造天书，缩进是不少，但全是空格缩进，从上至下看他的代码就如同是看一条蛇在地上爬，只有一行代码看不懂的人看着不晕。性能么，用我朋友的话说，能承载百人以上就已经很佩服那个服务器了。兼容性，只支持五年前的平台。界面放到文件夹，完全混乱随意，但是很难理解为啥还要建那么多。还有就是方法，有很多界面和数据处理，好多相似的功能模块放到不同的文件里，而他们之间只有几个参数不同，维护一个小小功能要改很多个文件，最关键是容易忘。没办法，成本耗进去了，只能自己维护，商务上厚着脸皮半推翻式开发，做了几个月才交了那个版本。
当年为了省钱，也和兼职合作过，代码规范约束、项目结构设计、项目实施方法那还是有的，比这个合作公司要强一些，只是当自己不能完成的时候，往往态度或者处理方法是“去XXX的，老子不干了...”。
我一些技术很好的朋友和当年的同事，很多人写代码很少能简单注释，毕竟感觉花时间写注释太麻烦，想到赶紧做出来最好，当然，基本的一些规范还是有的。但是如果要负责一个项目设计和整体的实施，那肯定要在规范上做方案要求。
之后我做的一些短期项目，虽然注释和规范并不是很多，但因为比较熟悉业务和具体技术，最后都比较成功。
大概的经历先说这些，总结下我的感想
代码的规范的确很重要，一件事形成了标准就可以快速的被别人接受，一个人看习惯了一种规范的代码，那他看这类代码就会很快，看不规范的代码就会很烦。给别人看和给自己看是一样的。还有就是规范的代码在有些情况下，比较容易进入管理统计系统，例如如果项目实施的所有人都在每个功能上写足够的注释，那项目管理者就可以自动的生成获取项目进度数据程度和问题，也可以自动生成开发文档和使用说明书。我当年很喜欢VC6版本的MSDN，对每个函数介绍的很详细很简洁，连英文单词都很统一，同一意思都用同一个词。如果在这个平台开发的伊始不做详尽的规范，那是绝对达不到这个程度的。
代码规范就像是人与人之间沟通，让别人理解你，让自己保持一定的性格做事情。还有就是代码规范是在规模越大的项目上越能看出价值的，这和其他领域或者平常做事情中所提到的“标准”是一个概念的东西。尽量养成习惯，但也不要花太大的精力。
可是话又说回来，规范只是为了更好的维护，更好的开发大规模的项目。可一个项目的成败最重要的是他之前的需求分析和软件设计，需求分析与此话题无关先不说了，来说软件设计。软件设计如果用的平台过老，那就会增加整个系统的开发成本和周期，而且你也达不到成熟平台的稳定性。如果用新的但不成熟或者自己不熟悉的技术，那如果一个难题搞不定，可能让你整个项目走到前功尽弃、遗留大量隐患或者浪费大量的时间。如果数据结构和模块设计的不好，那以后你想开发一个功能很可能出现数据不可逆、逻辑实现需要过于复杂的过程等等。
其实那个文档中的规范主要包括代码可读性规范、性能规范、可检测规范，主要体现软件实施的一种思维。代码可读性规范最主要的目的就是写注释和用最简单的表达方式来实现程序，而其他的其实就是总结一些预防常见问题的一些方法。而想写好程序，最重要的还是要让开发者对开发的每个细节有足够的把握。
还有就是现在开发工具越来越智能化，很多查找分析创建，所以在开发一定规模、难度的项目上，代码规范的价值体现的不大。很多软件是短期开发应用，这中间基本上不需要更换实施人员和业务需求，所以不用严格的代码规范也会把项目做的很好，按经验来说如果一个团队五个人以内没有人员流动、开发周期一年以内没有需求变更可以不用刻意管理代码规范。也就是你如果管一个项目，一般你不知道这个项目会搞多久，你先制定好代码规范，如果这个项目规模不大，实施人员熟悉程序有限，设计方法不是非常好，那你在管理的过程中可以睁一只眼闭一只眼，要反而会影响效率与成败，毕竟干活的是人，干烦了会懒会跑的。
另外，代码规范中争议最大一般就是注释量大小的问题，其实很多人写东西，当时想出来写出来就不想写注释了，尤其大多注释是给别人看的，主要服务的是公司的利益（虽然不全是如此，但是大家都会这么想），所以强求他人写注释也不是什么好事。前几天在和朋友探讨这个问题，是否可能让一个人全职为项目其他人写注释，这样是以“旁人”的角度写注释效果更好；什么样的规模用多少人全职来写注释比较好；这样的人需要具备什么样的基础；什么样的人喜欢做这种事情等等。大概讨论出个结果，但是没有尝试的机会，至少现在感觉这个东西可行，等以后有机会的话尝试一下吧。
2012-04-04 14:16
