Recent Posts

编码规范的简单经济原理 最简单的理据，往往来自于最朴素的经济追求：这里有利润。 分析编码规范的成本很直接。编写推广学习、部署改进工具，代码走查关注是否违例，所有这些花费在编码规范上的时间的综合，就是编码规范的成本。 而从编码规范中获得的收益相对间接和持久，是通过对你投入软件活动中的时间的精简，通过软件活动中的一系列沟通活动和质量成果逐渐展现出来。 很确定的是，坚持编码规范所带来的收益能够远远高于它的成本。它为你节约的时间，能远远大于你花在它上面的时间。 能赚钱的就是好生意！ 这绝对是一笔好生意。 能提高代码可读性。 遵守相同编码规范的代码，常常看起来就像是一个人写出来的一样。具有相同的风格是降低学习曲线的有效方式。当你新到一个具有编码规范的公司，读懂某几个函数或模块的写作方式后，常常代表你可以快速读懂相同规范的所有代码了。 能减少人与人之间的沟通成本 理解并遵守相同编码规范的人，就像在讲同一种语言，沟通会快速而准确。而在发生编码风格冲突的时候（不用怀疑，程序员之间的风格冲突是永恒的……），编码规范将会作为仲裁的最终依据，减少沟通的无效消耗。 能提高代码质量 合理的编码规范几乎每一条都会针对一个在编程世界里常见的技术问题。在实践中应用编码规范，就像是常备了一位高水准的代码审查者，能帮助你规避很大比例的常见问题。 简单的来说，在一句If语句中错误的使用了赋值（=）而不是判等（==），可能会带来一个隐藏超过一年的bug，在特定的客户机房，花费你超过一个月的调试时间才能解决。释放一块内存后指针没有清零，可能会带来内存的第二次释放导致系统崩溃。变量没有初始化，可能会在函数栈的多次值传递后，将程序引入一个未知的随机态…… 这许许多多的常见错误，都可以通过在头脑中的强烈规范意识，以及严格的代码规范审查所避免。（我不太喜欢用“低级错误“这个词，因为实际上几乎所有的程序错误都是”低级错误“。） 能为团队工作建立脚手架 团队，需要规范。 在所有的团队中，不是每一个成员，都拥有相同的知识领域、教育程度、行业背景、项目经验，从而不是每一个成员，有着相同的思维深度、隐喻哲学和学习能力。 建立合理的规范，可以建立团队在技术上沟通的模式，前文已提及，更重要的是，还可从团队内部，重（chóng）用已有的程序智慧，为成员提供了有高度的脚手架，避免成员个体在程序设计上特定弱点所带来的质量短板。 团队中个人的优势能力决定了团队的质量能力的上限，而编码规范的执行，则决定了团队代码质量的下限。 能节约智力投入 还记得在你在遥远的中学时期吗？英文考试的倒数第二题永远是找茬题：给十多行英文让你找错。 很快你就自己总结了一个检查表，包括在试卷上出现过的所有错误类型（单复数错误、时态错误、介词错误……），此后考试时对每一行都遍历一遍检查表，基本上快准狠。自然而然的找你妹的题就变成了完全不花智商的按图索骥送分题。 编码规范就是这样的一个检查表，它必然是程序世界和公司经验的知识沉淀物，它能帮助你减少思考的密集程度，将最重要的智力资源投入到真正需要你去设计和关注的核心点上。 你不用再在多种程序风格中进行翻译和映射，因为只有一种程序风格。你看一眼函数名就知道它是做什么用的来自于什么模块，你看一眼变量名就知道它是什么内容大概应该是什么类型。 你不用再去思考变量的初值，因为变量的初值总在定义的时候有说明，对整数来说大多是0，对指针来说大多是NULL。 你不用再去思考来自于外部的一个buffer是否需要你去释放，或者你定义的buffer应该在什么地方去释放。 …… 是的，我们希望在一切在程序世界里可能有争议的地方，或者完全没有争议的地方，都有我们自己的规定和习俗。 让软件工程师在最常见的程序过程中沿袭习俗，在关键和艰难的创新点上灵活创新，继而充分的用80%以上的智力来解决20%的核心问题。这才是对软件工程师团队的最大效率提升。（请把你积攒的每一点怒气都用在释放大招上！）…