实施代码规范提升软件工程质量

一份代码规范定义的是适用于具体项目的团队编码风格，并非作为一个通用的标准。不同的人和同一个人在不同的时期，对代码标准的理解，都会有不同的看法，没有对错之分，而有些时候也只是形式上的差异，代码经过编译之后并没有本质不同。基于以上事实，每个开发人员当然可以保留自己对编码的一些个人见解，但对于代码规范，仍然是需要摒弃个人风格而去遵循的项目准则。

目的

不同的编码风格最大化统一，使工程代码可读性高，便于维护；另外代码规范中也包含一些优化的规则，有利于改善性能。

工程指标

1. 1. 复杂度：降低复杂度没有具体的指标，但确是工程实现需要关注的核心问题。降低结构的复杂度对于越大的尺度（高层次）越重要，对框架的复用性，开发效率以及工程质量起到决定性的作用。
      • 关于复杂度与Bug：最低级的Bug是结构性的Bug，其次才是算法实现级的Bug。前者只要通过设计与重构出简单清晰的结构模型就能得到非常有效的控制，后者则需要大量不同类型的测试（主要是性能测试），属于更微观的尺度。
      • 关于系统约束（产品活动与工程活动的关系）：从产品设计角度理解：以有限的资源创造无限可能；从工程开发角度理解：把无限的可能转化为有限的解，且边界越清晰越好。
   2. 稳定性：在生产环境必须保证的就是稳定性。工程中尽可能利用经过市场验证的成熟的方案，编码优先考虑语言自身提供的API，实现功能从直觉上使用最简单的方式，采用一些常规型，普适性的思路。
      • 以开发效率与版本稳定性优先，也有可能以一定程度的性能损失为代价。
      • 关于稳定性与Bug：从测试的观点出发，有种说法叫做测不出Bug就说明没有Bug，但是从科学的角度来看却很不严谨。不过你也可以这么说，没有任何程序是没有Bug的，只是还有没测出来（符合事实的怀疑论调调XD）。如果从这个角度来看，内心会坦然很多，因为事实总是残酷的。我一直奉行平衡之道，走两个极端都是不符合客观规律的，碰到问题解决问题，没有银弹。
   3. 性能：有预定的指标，但是优化没有极限。我们需要做到的就是达到产品市场定位的要求，即针对发布的不同平台，基于最低的硬件性能标准，得到符合用户良好体验的结果。

代码原则

• • 如果一件事情的一般规则是A方案，也可以是B方案，那么潜在的意思就是，如果可以使用B方案时，就应该用B方案。
  • 一定不要让代码复杂，以企图覆盖绝大多数的需求，只满足当前需求的最小子集。
  • 一定不要把时间花在追求一遍写出完美的代码，即便是专家也会犯错。考虑如何把可能产生的错误封装在尽可能小的作用域内，便可以快速下笔。
  • 单个文件的代码行数过多非常影响人的阅读状态，个人习惯不超过500行，这是统计意义上非常自然的标准（和《代码大全》的推荐行数不谋而合）。
  • 对于明确会出现逻辑异常的地方，用Try／Catch补救或者从设计上做限制甚至牺牲。
  • 表达精炼，每多一行代码意味着更多的Bug。

难点

人类的一切群体活动都可以理解为经济行为，那么必然需要计算的是成本问题。而推行规范或者制度所需要耗费的成本有可能是巨大的，如果不能依靠某些有效途径来降低其成本，则几乎不可能成功（暴君制度当然不能赞同）。

• • 代码模版
  • 常用代码片段
  • 代码生成器
  • 自动格式化工具
  • 注释标准化工具

关于代码片段

加速了编码速度，这是一个典型的可以形成正循环的例子。因为可以提高编码速度，代码片段体现出自身价值（即有意义），进而提升了开发者使用其的意愿，最终达到促进规范得以实施的效果。好的方式方法本身应该符合两个指标，一是具有明显的积极意义，二是实现上操作简单。

PS：关于“正循环”这个概念，有时间需要单独讲。它化有为（显性行为）为无为（隐性行为，下意识行为），符合道法自然的哲学思想，有着广泛的普适性。