规范的目的及其能愿动词的使用

目的

规范化可以让我们的工程师训练有素，以此来提高软件交付的质量。

另一方面，团队的项目经验能够得到继承，在实战中不断进行总结和摸索，找到兼备开发效率、程序执行效率、扩展性和安全性的最佳实践，最终实现团体智慧的延续和精进。

优势

规范有以下优点：

• 高效编码 —— 避免了过多的选择造成的『决策时间』浪费；
• 风格统一 —— 最大程度统一了开发团队成员代码书写风格和思路，代码阅读起来如出一辙；
• 减少错误 —— 减小初级工程师的犯错几率；
• 提高团队战斗力 —— 在多人协作的工作中，做到 1 +1 大于 2。

开发哲学

因为篇幅原因，本规范无法涉及到项目里每一块代码的编写标准，所以此处重点说明下此规范遵循的『开发哲学』，开发中请把其当做指明灯，来指引你做决策：

• DRY ——「Don't Repeat Yourself」不写重复的逻辑代码；
• 约定俗成 ——「Convention Over Configuration」，优先选择框架以及社区提倡的做法，不过度配置；
• KISS ——「Keep it Simple, Stupid」提倡简单易读的代码，不写高深、晦涩难懂的代码，不过度设计；
• 主厨精选 —— 让有经验的人来为你选择方案，不独创方案；
• 官方提倡 —— 优先选择官方推崇的方案。

设计理念

以下是一些优秀的『程序设计理念』：

• MVC - Model, View, Controller ，以 MVC 为核心，严格控制 Controller 的可读性和代码行数；
• Restful - 利用『资源化概念』和标准的 HTTP 动词来组织你的程序。

在此规范中，我们会将使用这两套理念作为程序设计基础。

这些设计理念为我们设计程序提供了依据，遵循这些理念，能让程序变得清晰易读。

能愿动词

为了避免歧义，文档大量使用了「能愿动词」，对应的解释如下：

• 必须（Must）—— 只能这样子做，请无条件遵循，没有别的选项；
• 绝不（Must Not）—— 严令禁止，在任何情况下都不能这样做；
• 应该（Should）—— 强烈建议这样做，但是不强求；
• 不应该（Should Not） —— 强烈建议不这样做，但是不强求；
• 可以（May） —— 选择性高一点，在这个文档内，此词语使用较少；

参考：RFC 2119

关于执行

在这份规范里，有些内容里会解释『这样做的理由』，这样做的目的是为了达成共识。

请不要以此『理由』的准确性来怀疑规范的权威性，规范就是规范，可以讨论改正，但在执行的时候 必须 严格遵守。

请把『团队项目开发』想象就是在行军打仗，对于规范要绝对服从。要有大局观，做到团结一致，把个人的喜好放一边，把整个团队的执行效率放在第一位。