编码规范
为什么会有编码规范？
一个软件的生命周期中，80%的花费在于维护，很少有一款软件在整个生命周期中，都是由最初的开发人员来维护，编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码。
衡量代码质量的唯一有效标准: WTF/min，无论是漂亮的或者糟糕的代码都可以引发What The Fuck感叹。
思想
1.无论多么小的需求，都需要先设计号所有逻辑，然后再动手开始编码。
文件
README.md 特定目录或者特定内容的介绍文件。
单个源文件代码不要超过2000行。
每行代码尽量不要超过120个字符。
缩进排版通常使用4个空格字符，单行放不下需要换行请在新行添加8个字符缩进。
变量都声明在代码块开始的地方，不要在首次用到的时候再声明。
注释
• 文档注释，所有源代码文件都应该由一个开头注释，类注释和方法注释。
• 代码注释，业务代码中的注释，如果能用代码说明意图的内容，请减少使用注释，单行注释，多行注释。
• TODO，现在大部分主流IDE都支持的字符，可以将当前想法标记出来后续处理。
• 单行注释，写在其说明内容的上面。
空行
一个源文件的两个片段之间应该使用两个空行。
两个方法之间应该用一个空行。
方法内变量部分和第一个语句之间应该用一个空行。
方法内两个逻辑段之间应该用一个空行。
注释块前面应该用一个空行。
空格
关键字和括号之间应该用空格隔开。
参数列表中参数分隔符的后面应该有空格。
命名规范
1.Package 通常由全部小写的顶级域名来书写。
2.Class、Interface首字母大写，其余小写，尽量使用完整名词，避免使用缩略词。
4.Variables多个单词构成，第二个单词开始单词首字母大写，必须便于记忆。
5.Instance Variables实例变量，
6.Constants常量全字符都用大写。
7.文件的命名，中间用-分割，例如fss-2011.sql
8.URL，最后面不要加斜线，例如https://www.duchaoqun.cn
Function
• 动词+其他单词命名，第二个单词开始单词首字母大写。
• 函数尽量短小，保证它只做一件事情。尽量保证函数都在最低的抽象层级上，函数内的语句都再同一个抽象层级上。
Boolean类型返回值命名规范
尽量用英文表达出函数或方法完成的功能。
遵循动宾结构的命名法则，函数或方法名中动词在前，类的成员函数或方法须只使用“动词”，第一个字母是小写，但是中间单词的第一个字母是大写。
如果是返回一个成员变量的值，名称一般为get+成员变量名，如若返回的值是bool变量，一般以 is｜isNot｜has｜does｜doesNot 等作为前缀。
如果是修改一个成员变量的值，名称一般为：set + 成员变量名。
函数或方法名的长度不得少于8个字母。
编程惯例
1.若没有足够理由，不要把实例或类变量声明为公有。
2.避免用一个对象访问一个类的静态变量和方法。应该用类名调用。
3.在含有多种运算符的表达式中使用圆括号来避免运算符优先级问题。即使运算符的优先级对你而言可能很清楚，但对其他人未必如此。你不能假设别的程序员和你一样清楚运算符的优先级。
错误处理
你抛出的每一个异常都应该具有完整的上下文以确定错误的来源和位置。
具有创造性的错误信息会在代码写出来后很久，甚至是作者已经离开很长时间后仍然被人们记住。
代码写出来首先是给人读的，然后才是指导机器要怎么做。要像艺术家一样写代码。
接口文档API
设计原则
API（Application Programming Interface）API本身的含义指应用程序接口，包括所依赖的库、平台、操作系统提供的能力都可以叫做 API。我们在讨论微服务场景下的API设计都是指WEB API，一般的实现有RESTful、RPC等。API代表了一个微服务实例对外提供的能力，因此API的传输格式（XML、JSON）对我们在设计API时的影响并不大。
协议
webService接口是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。
http api接口是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。
速率限制用户的频繁调用，来控制服务器资源。
使用标准的协议和消息格式，合理的命名。
2.?????? 统一的路径规则，完整的参数校验功能，详细的错误提示信息。
3.?????? 统一响应码与异常处理逻辑。
4.?????? 具有安全的认证策略。
5.?????? 使用HTTP动词定义(GET,UPDATE,DELETE)对资源的操作。
6.?????? 避免简单封装，让API成为操作数据库的接口。
7.?????? 关注点分离，不同的业务逻辑单独接口处理。
8.?????? 功能覆盖完全，且彼此独立不重复。
9.?????? 规范的版本控制，使用URI前缀的方式控制接口的升级问题。
10.?? 完善的接口文档和丰富的代码实例。
11.?? 完整的接口调用记录与可配置的缓存策略。
状态码
• 所有内容都应该是字符串。
• 收到消息后根据 status 和 message 来处理 data 的内容。
• status 是我们的状态码，message 是提示消息，data 是返回的数据。
1000-1999 各种消息
2000-2999 成功相关
[‘status’: ‘2000’, ‘message’: ‘请求处理成功’, ‘data’: …]
3000-3999 保留，例如转发第三方的请求。
4000-4999 客户端错误
[‘status’: ‘4000’, ‘message’: ‘未找到相关信息’]
5000-5999 服务端错误
[‘status’: ‘5000’, ‘message’: ‘未知服务错误’]
[‘status’: ‘5001’, ‘message’: ‘创建附件失败’]
接口模板
描述
说明该接口的所有信息
地址
/v2/contract/download
请求方法
GET
请求格式
application/json;charset=UTF-8
请求参数
参数 类型 必须 描述
id String Y 唯一标识
返回参数
参数 类型 描述
code Integer 响应码
message String 响应消息
result Object 返回数据
响应码
包括统一的响应码，和自定义的响应码。