代码规范之争——[个人Week2作业]

这四个问题均是出自 http://goodmath.scientopia.org/2011/07/14/stuff-everyone-should-do-part-2-coding-standards/ 。

我对这四个问题均持 反驳 的看法，下面是我的理由~

Q1：这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。

A1：

其实很简单，因为统一编码规范可以造就代码风格的一致性。在团队里每个开发者所看到的代码，无论是自己写的或者是别人写的，都将有着统一的代码结构，有着一样的命名协定。这样的代码给人带来阅读源码愉悦的体验： 你看别人的代码就像看你自己的代码一样！ 当然好的注释是非常必要的，否则别人的代码就算像是自己写的代码，一个月后估计就只有上帝能看懂了。

我以为这样做还有个好处就是“一次制定，终身受用”。比如开发某大型商用软件，如果开始能够统一代码规范，那么即使最初的开发者离职了，接手的新人也能够从统一的规范中快速入手并进行同样规范下的源码修改。通过遵循一致的风格， 此种规范能够让其他开发人员的介入、帮助、维护或新的发展变得高效有序 。而且代码规范具有极高的复用性，在不断的实践中总结出一套好的规范集，能够在许多大型软件开发前就做出约束与规定，这样对以后的每个软件开发流程都有非常好的影响。

并且，统一风格利于寻找bug。在做代码审查的过程中， 规范一致的代码对于审查的效率提升有莫大帮助。 想象一下你看这一堆你觉得像坨屎一样的代码进行code review的时候会有多好的心情吗...还会想着认真寻找bug吗？看都不想看，还能让人好好review嘛！

最后，我觉得是对于程序员个人的一种收获。编码规范的统一更利于程序员自身 主人翁意识 的培养，这种意识的培养我觉得是工程师与码农的很大区别之一（纯属个人意见）。能够对自己的代码负责，就能够开发出更加高质量的代码，对于工程师本身也是能力的锻炼。 如果开发者从来不管代码后续的维护问题，不管源码的可阅读性问题，那么对他而言码代码只能算作是一种工作，而从来不能称之为艺术。

Q2：我是个艺术家，手艺人，我有自己的规范和原则。

A2:

代码书写过程中所遵循的编码规范，有时就好像是一个作家在书里的写书风格。它们的共同之处当然有：它们往往容易被忽略，只有少数人才能够严格地遵循它们，并且这些人最后往往能够成功。但是它们当然也有着巨大的不同：作家写书是单兵作战，而工程推进大部分时候是团队合作的。

问题所述的情景在很多软件开发过程中都会很常见。许多程序员都以自己的编码风格为傲，有些甚至是为了代码而代码的。将本来逻辑清晰的代码写得复杂又难懂——这样或许能为他在部门经理心中的地位的提升做出很大贡献？或者只是为了装x(捂脸)？...只是调侃一下：D。复杂晦涩难懂的代码，或者说句法怪癖，基本不可读的代码，是很难得到他人的认同与维护的。 能力与创造力和是否坚持自己的怪癖规范没有半毛钱关系。

当然传统软件工程开发里不乏很多单兵作战的例子，比如Ken Thompson、Linus Torvalds、还有Donald Ervin Knuth教授“排版不爽就做个Tex”的让人津津乐道的故事。确实，上个世纪涌现出的这些享誉世界的Hacker们，确实是以一己之力震惊世界的程序员的典范，是真正的程序员。

但是，他们是艺术家，然而我们现在并不是 。艺术家往往是富有灵感与创意的，但是艺术家是有前提的：必须得有足够的天份与更多的练习。也就是说： 首先你需要是个匠人，然后你才可能是个艺术家。

作为一名solo developer，渴望成为superhero而独立开发软件，在现代软件工程的复杂程度下，基本是不可行的。开发初期，我们可能会因为自己可以随意制定规范与原则而感到效率极高：不需要跟别人开发的模块耦合，不需要“被迫”写注释，不需要花“大量的时间”去改变自己原先的编码规范而适应团队的编码规范，不需要做大量“无用”的交流工作。

但是作为一名独立开发者最大的好处同时也可能是最大的坏处就在于两个字：自由。 时间越长，对于独立的开发人员来说一个软件的发布就越困难。除非开发者本身本来就有详尽的知识技术、可行的解决方案和大量开发的经验。但是现实往往是残酷的，每个人都会有自己的思维盲点，在开发中这是避免不了的。我的观点不是说某个人不能开发一个小的软件，我的意思是说，一个人在付出足够多的努力成为“艺术家”之前，软件开发流程往往会因为设计的局限与解决方案的不准确而被迫停止。

而且，对于软件的开发流程的推进，除非开发者是一个非常自律的人，不然可能遇到某个大的bug开发者就会丧失后续开发与维护的想法了。但是如果是在一个团队中的话，大家可以一起想办法解决bug，至少不会让开发者丧失后续开发的信心。

所以说， 每个开发者在想要一直保持“自己的规范与原则”前，需要认真地考虑一下自己是否真的是工程开发中的“艺术家”。 如果还不是，那么就必须遵守团队的编码规范；如果是，等到成为“艺术家”的时候，开发者自己也应该明白团队编码规范一致的重要性了。

Q3：规范不能强求一律，应该允许很多例外。

A3：

世界上确实没有完美的适用于各个软件开发的规范，这是正常的。如果一个编码规范能完美适应大部分软件的开发，才是不正常的：因为这种兼容性而导致的要么就是编码规范集的急剧缩小，或者是不能适应它的软件团队推倒重新制定一套新的编码规范。

但是， 实践开发验证过的编码规范确实可以提高生产效率， 或者说，自己完全重新定制一套编码规范有时并不如采用某种相似结构的编码规范来得高效。这不仅仅是由团队本身的实力决定的，更是因为实践过程中使用过的东西更具有执行力。完全新的编码规范，就好像温室的花朵，可能在软件开发过程中团队要不停地对这种规范进行修改——甚至是重新来过，花朵最后可能就只剩绿叶还留着——根本的东西已经没了。这种规范制定上的错误有时候是致命的，而且很多时候重新从头制定会产生各中奇奇怪怪的编码规范：

http://stackoverflow.com/questions/218123/what-was-the-strangest-coding-standard-rule-that-you-were-forced-to-follow

所以我比较赞同的是在软件开发中，以前人的经验实践过的编码规范作为基石——就像是泥塑的前期形态已经定好，辅以根据开发的软件的特色、框架等制作的扩展规范编码——就像是为泥塑精细雕琢一样。只有这样，才能在保证编码规范的大方向走对的情况下，走出自己的编码规范的路。这样， 不论我们走的是小道，山道或者不从道上走，都能走上正确的归途 —— 前人早已经用脚为我们走出为了成功的方向 。这么宝贵的精神财富，何苦不用呢？

Q4：我擅长制定编码规范，你们听我的就好了。

A4：

其实我觉得这句话，和下面这句话的效果并没有什么不同：

我擅长吃饭，你们的饭都让我来吃就好了。

编码规范不是一个人能决定的，就像一个团队——也不是一个人能决定的。在一个团队里大家确实要有所分工，各司其职，但是有些东西必须大家一致同意才能决定——比如团队例会时聚餐的地点、菜品的口味等。编码规范就像是饭菜的口味一样：确实有吃货可能会选到很好吃的饭店——对他自己而言，但是对于其他人呢？

这就相当于一个北京的同学拿着一盘炸蚕蛹，广东的同学端着一盘爆炒田鸡给你吃一样——他们确实选择了他们喜欢的，但是你并不一定喜欢，有时候反而非常讨厌。 因为对于他人来说美味可口的东西对你来说未必下得了口。所以对于那些自称擅长制定编码规范的同学来说，他所制定的编码规范可能确实看起来风格很好，很美味，"很多人"都喜欢。但是他现在要满足的不是"很多人"，而是"团队"的口味。 个人在这一点上务必要为团队的统一与规范做出让步。

这种心理更多地出现在这样的开发者身上：抱怨不是因为制定的编码规范不好，而是出于"我"比制定编码的人更优秀，"我"不能被比我差的人所制定的规范所束缚的心理。这样的开发者大多数觉得自己的代码会被一个loser所制定的lower的编码规范所拉低，所以实际上， 他们的抱怨往往来自于心理失衡，而不是规范本身的问题 。为了有这种"人上人"的体验，他们往往想要 制定编码规范来lead别人 ，就好像他们制定了编码规范就能鲤鱼跃龙门——成为小组组长、部门经理、公司CTO一样。

这种态度本身是带有傲慢、虚荣心的，如果一个开发者想要实现这样的"规范独裁"，那么他必定只是一个蹩脚的开发者，更遑论是小组组长、部门经理、CTO了。 真正优秀的开发者是谦虚、礼貌以及能够为团队做出牺牲的。 不懂得融入团队，天天把别人当傻x的开发者，往往自己一直扮演着最傻x的角色。