项目微管理5 - 规范
从鼬加入的那一周开始，四代就开始着手准备起草代码规范了。
代码规范不可少
很多人理直气壮的认为，创业团队，或者说人数少的团队根本不需要代码规范。
他们的口头禅经常是：“没办法啊！我们需要快速的完成客户的需求啊！客户最重要啊！实行代码规范只会拖慢项目的进度！而且时间太紧，我们也不能搞那么多的学习啊！”。
对于四代来讲，不采用规范的做法其实无异于是“饮鸩止渴”，暂时的无限制的代码提交确实很爽，在项目初期确实可能有助于快速完成需求的功能，但是这种鼠目寸光的做法，如果不尽早改正过来，一旦形成惯性，积重难返，对于只是玩玩的项目来说还没什么太大的副作用，不过对于想要长期发展的项目来说，这几乎就百分百会造成深远的影响，甚至严重一点就是灭顶之灾。
随意提交的代码导致的代码随意的堆砌，最后很可能是造成代码修改起来无比的困难，越往后越难以维护，最后只能是在团队一片哭爹喊娘的叫喊声中，项目迎来寿终正寝。四代真的不知道这种不负责任的结论还会影响多少人，还会终结多少项目啊！
对于“没时间，项目紧”这一点，四代觉的完全是扯淡，完全是借口，从四代的经历来看，任何的团队都需要代码规范，而且团队熟练掌握代码规范后，写代码并不会增加多少时间成本！对四代来说，许多的“清规戒律”之所以在很多的团队执行不下去，完全是团队管理者造成的，管理者的懒惰和不作为导致了团队的低效。
代码的作用
说到代码规范，就必须要首先理解代码的作用。扯淡！谁不懂代码啊？这还用讨论吗！答案是：用！
在四代看来，代码存在两个方面的作用，第一个作用是与机器对话，第二个作用是与团队对话。第一个是从个人和技术角度讲，第二个是从团队和沟通上讲。
对于四代来说，写代码存在有两个层次，也就是说，在四代的眼中，软件工程师至少存在两个等级，一个是初级，一个是高级，初级软件工程师能写出机器能懂的代码，也就是说编译没问题，运行很正确，但是高级软件工程师能写出人能懂的代码，也就是不仅编译没问题，运行很正确，关键是团队其他人还能读懂，这就是优秀的软件工程师最牛逼的地方，没有“之一”。
对于一个团队来说，有什么会比代码的传承性更重要吗？没有！即使是只有一个人的团队也是如此，谁能牛逼到面对自己一段杂乱不堪的代码，在几个月以后还了如指掌！时至今日，代码在沟通上的容易与否，也就是代码的沟通成本，或者说维护成本，是衡量代码好坏的最重要的特征了，这里同样没有“之一”。
为了让代码便于沟通，为了让团队合作更加高效，确实应该制定团队基本的代码规范！
代码规范那些事
代码规范这个事，毋庸置疑，大家绝对是赞同的，尽管很多人目前不会执行，反正大家认为这个玩意儿应该有。但是这个东东严格来说是没有标准的，不同的人有不同的看法。四代认为：对于一个团队来说，不管采用何种规范，只要做好三件事就可以了：第一件事是尽快执行下去，第二件事是坚决执行下去，第三件事是坚持执行下去。
首先得具有这个坚决的态度，这是做这件事的前提条件，否则说什么都是白扯，四代见过太多在团队中扯淡的人和事了！说的很好听，可实际上一旦谈到落实，就闭口不言！
其次，四代觉得对于代码规范本身，有几点还是需要注意的。
第一点，代码规范最好是明确的规范。
比如下面这些就是比较模糊的规范：
|
1. 变量应该不要太长。
2. 变量名应该清晰易懂。
3. 函数体不要太啰嗦。
4. 类不要太大。
|
如果把这些规范改成下面这样，或许更能容易执行一点：
|
1. 变量不超过5个单词。
2. 变量名要表达出变量的用途。
3. 函数体不要超过50行，函数复杂度不要超过10。
4. 类的公开成员不要超过20。
|
第二点，规范应该具有实用性。
至于实用性上，四代认同代码规范不易太长，可以采用很多人建议的那样，就搞个”程序员节操15条“，选取你认为团队中最需要实行的15条放到里面就可以了。比如四代就会选择如下一些简单易行的一些规则：
|
元素类型
|
命名规范
|
实现规范
|
|
通用命名
|
使用英文单词
表达出变量用途
不加变量类型
不使用缩写
本地变量采用小驼峰命名
函数和类型采用大驼峰命名
|
|
|
表达式
|
语句体即使只有一句也不省略{}
if语句中的条件表达式的逻辑运算不要超过3个
|
|
|
函数
|
以“动词”或者“动词+名词”组合
|
参数不多于5个
函数体不超过30行 (不含空行)
函数复杂度不超过7
|
|
类
|
类和属性以“名词”或者“形容词+名词”的方式命名
类实例变量以“m_”开头，静态变量以“s_”开头，后面部分使用小驼峰命名
交互型控件变量结尾需加控件类型全称
类常量/只读变量不加前缀且使用大驼峰命名
|
类的成员函数(包括普通函数，索引，属性)全部参照函数的规范
类不允许有非常量的公开字段，如果确实需要则用属性代替
类公开成员不超过15个
类不超过800行 (所有行)
|
|
接口
|
以“I”开头，以“形容词”或“名词”命名
|
接口的成员不超过5个
|
就这些，不管是重构还是正常写代码都用得上，姑且也把这些规则称为”程序员的节操“吧，呵呵，这可是程序员的底线啊。
第三点，规范应该具有时效性。
随着时间的不断推进，随着团队成员水平的不断提高，大家可以不断的修订这个规范的内容，比如每年一次，与时俱进嘛！
四代初步的规划是每年年初修订一次，不求完美，但求符合团队的实际情况。这个不需要多说了，一潭死水最容易臭掉，一切缺少发展特征的事物最终都会死掉，被淘汰，这是伟大的自然辩证法告诉我们的！在大学几年中，自然辩证法和哲学是四代认为最重要的课了，也同样没有“之一”！
第四点，规范应该是大家一致认同的。
规范是整个团队代码提交的准则，所以只有大家一致从心里认同了，大家才会始终贯彻它们。
四代非常重视这一点，当后来规范建立起来以后，四代先是让团队中的所有人试着执行了几个月，然后才正式的和所有的成员讨论了规范中的所有细节，解答大家的疑惑，征求大家的意见，最终形成了当年执行的版本。
代码审查那些事
有了代码规范了，大部分人可能会认为，这下代码审查的时候终于可以有话说了。不过四代个人觉得代码规范更多的是大家自检的项目，除了团队新人需要提醒一下外，基本上不需要别人太操心。
代码审查，这个大家同样都是点赞的，姑且不管效果有多明显，反正大家都觉得这个玩意儿有用，大概原因有如下一些：
|
1. 代码审查能避免一些低级的错误，比如拼写错误，比如简单的逻辑错误等。
2. 代码审查能使得大家互相学习一些新的知识。
3. 代码审查能多熟悉一些代码。
4. 代码审查能避免一些对方代码的失误而影响到自己的功能。
5. 代码审查能寻找到更加优化的方案。
|
但是一到实际的项目中，就会有各种问题导致不能贯彻执行下去，比如下面这些理由：
|
1. 时间不够
“哥啊，软件开发任务多的做不过来，那还有时间做代码审查？这不是代码审查好不好的问题，而是我没时间做啊！”
2. 需求变化
“需求变得太快，代码的生存周期比较短，不需要好的代码，反正过两天这些代码就可能会被废弃了！”
3. 态度问题
“别人的代码，我又不懂，怎么审查啊！而且就算是自己写的，写好就行啦，干嘛精益求精啊！”
4. 结果最重要
“大佬们都说了，能运行的代码最重要了，要那么漂亮干什么！”
5. 能力不足
“不好意思啊，我们都不知道怎么做代码审查啊！”
|
乖乖，总结一下都能写一篇论文。但是不管怎么样，四代根据团队实施代码审查的过程，觉得有几点是值得大家深入思考的：
第一点，任何提交到代码库的代码必须是经过代码审查的。
这个不用多说了吧，既然代码审查那么的重要，无论时间多么的紧迫，谨慎一点都是必要的，尤其是对一些发布流程比较长，发布成本比较高的产品，如PC团队研发的桌面版软件。
第二点，代码审查不仅仅检查那些代码规范，还要检查代码的逻辑是否合理。
虽然很多时候，代码审查并不能如想象的那样，发现代码的很多问题，但是代码审查会提升程序员的编程态度。试想如果一个人知道将会有同事检查他的代码，他编程态度就绝对会不一样的。他写出的代码将更加整洁，有更好的注释，更好的程序结构，因为他知道，大家将会查看他的程序。
在代码审查中最常犯的错误几乎每个新手都会犯的错误是，审查者根据自己的编程习惯来评判别人的代码（当然，基本的代码规范是需要大家共同遵守的，哈哈）。
对于一个问题，通常大家能找出十几种方法去解决。对于一种解决方案，大家能有百万种编码方案来实现它。做代码审查的时候，审查者的任务不是来确保被审查的代码都采用的是自己习惯的编码方式，因为大部分情况下，它不可能跟你自己写的一样。作为一段代码的审查者的任务是确保由作者自己写出的代码是正确的。
第三点，代码审查不一定非要说些什么。
代码审查经常易犯的毛病是，人们觉得有压力，感觉非要说点什么才好。当审查者知道作者用了大量的时间和精力来实现这些程序，不该说点什么吗？不，大部分时候并不需要。大部分时候，只说一句：“哇，不错呀”，会非常合适。
第四点，代码审查要坚持执行，一定不要敷衍。
没有什么事情能简单的做下来的。依四代的经验，在团队能正确的进行代码审查前，大家是需要花时间学习和实践的。人们在代码审查时经常会犯一些错误，导致不少麻烦，尤其在一些缺乏经验的审查者中经常的出现。他们给了人们一个很遭的代码审查的体验，成为了人们接受代码审查制度的一个障碍。
代码规范和代码审查是PC团队最重要的几件事之一，从规范讨论的那天起，四代就征求了鼬关于这件事的意见，他们经历过入职后修改部分代码的痛苦的经历后，一致认为这么做非常有必要，于是，就在某个月黑风高的夜晚，它终于被正式实施了。
版权声明：本文为dxy1982原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。