目标
通过严格的规范来统一输出、达成共识、提升质量。
时序图规范
示例：微信内网页支付时序图
微信内网页支付时序图
一、原则
有明确的交互过程的上下文。
清晰标识参与过程的交互对象。
为每个对象设置生命线。
从初始消息开始，依次画出随后消息。
考虑消息的嵌套，标示消息发生时的时间点。
说明时间约束的地点。
二、评审
评审时间：根据迭代计划时间进行（QA跟进提醒）
评审方式：会议形式
发起人员：SM组织团队主动发起邀请“评审团”参加
评审团：PO、TM、QA、技术专家、其他组SM（可选）
评审流程：
以团队为单位（非个人或部分人），结合时序图上不同的角色、对象，对团队本迭代认领的故事进行串讲，包括对“需求理解”、“技术实现”和“任务分工”三大部分的介绍。
“评审团”会随机抽查团队成员进行串讲。
二次评审：根据评审情况决定是否需要重复以上步骤进行二次评审。
接口规范
一、接口分类
查询类接口
操作类接口
上传下载类接口
推送类接口
二、接口编写原则
实用性
数据格式：使用的数据格式，要综合考虑各个端（客户端、前端）的通用性，有较好的跨平台性，且占用字节数较少。
接口执行效率（接口访问速度）：移动端有限的网络条件下，要求接口响应速度要快，所以在开发过程中尽量选择效率高的框架。
数据量：按需分配，需要什么数据就返回什么数据，过多的数据量影响处理速度，最重要的是影响传输效率和浪费用户流量。
API缓存：这点比较重要，不管是文件缓存还是memcache缓存。
易用性
接口、参数命名准确：无论是接口还是参数，命名都应该有意义，让人一目了然。
一个页面尽可能就用一个接口：现在很多的APP页面都有广告、焦点图、文章列表等，对于这些不同格式的数据，不可能都分配一个接口，这样加大了APP请求接口数，影响响应速度。建议服务器端尽可能处理好数据后通过一个接口返回给APP客户端。
接口数据、状态：接口必须提供明确的数据状态信息，不管是成功的，还是失败的。
接口要有可扩展性：方便后期功能性调整，接口应具备可扩展性。
安全性
接口安全：客户端和服务器通过约定的算法，对传递的参数值进行验证匹配。
加密规范：在传递用户名密码时，应采用规范的加密算法如MD5、RSA、DES，进行数据通信请求。
接口版本控制：对于接口版本控制，需要应对不断的APP版本升级，新、旧接口的处理，因而需要关注接口版本控制。
三、接口设计原则
尽量减少参数传递：请求接口操作时，应减少参数传递，如某些操作只需要ID不需要其他参数，这时候就应该只传递ID这个参数。
尽量避免接口重复性：调用接口时，尽量提高接口复用性，减少HTTP请求，提高程序稳定性。
数据类型规范：调用接口时，应标注参数数据类型，以及是否可为空或者默认字段，如标注了Int型字段，就不能返回“null”的String类型字段，否则容易造成程序APP出现数据类型解析异常。
编码规范：整个API接口开发过程中，应标注接口编码方式，目前建议采用UTF-8编码，UTF-8通用性以及URL请求方面都较规范。
请求方式：编写API接口应该标注请求方式，如：GET、POST
GET和POST方式：在数量较小情况下可以使用GET方式，但数据量超过1024字节就应该采用POST方式，避免出现请求失败或者请求异常的问题。
返回接口调用状态：所有API接口都应该统一标识调用的成功失败信息和规范错误编码信息，以及必要的提示字段信息。
安全机制：接口应规范验证签名机制，用户登录后统一调用KEY对接口安全验证。
参数说明：应标注参数名称、是否必选、数据类型及范围、说明以及“否（必选）”传递默认的参数。
四、管理与实施
版本管理：接口的任何修改都有迹可循，有提交记录，可以结合使用rap+gitlib的wiki进行管理。
接口需提供测试用例：为了方便接口使用者高效的进行接口联调、希望接口提供者能提供一个默认的接口测试用例。
五、评审
评审时间：根据迭代计划时间进行（QA跟进提醒）
评审方式：会议形式
发起人员：SM组织团队主动发起邀请“评审团”参加
评审团：PO、TM、QA、技术专家、其他组SM（可选）
评审流程：
以团队为单位（非个人或部分人），对新增、修改的接口的设计思路进行讲解。
“评审团”结合“接口编写原则”和“接口设计原则”进行评审。
二次评审：根据评审情况决定是否需要重复以上步骤进行二次评审。
数据库表设计规范
示例：E-R图
补充：E-R图也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。
一、原则
有明确的所属数据库说明。
表名称命名规范
使用小写英文以及下划线组成，尽量说明是那个应用或者系统在使用的。
相关应用的数据表使用同一前缀，如社群circle_
备份数据表名使用正式表名加上备份时间组成。
字段名称命名规范
字段名称使用单词组合完成,首字母小写,后面单词的首字母大写，如userId
表与表之间的相关联字段要用统一名称，不好的案例：live_profile表中biz_id对应的是circle_id
字段类型规范
用尽量少的存储空间来存数一个字段的数据，如：能用varchar(20)的就不用varchar(255)
表与表之间的相关联字段要统一格式，不好的案例：如表1中string类型的账号0123456,在表2中转成int类型的123456
完整性约束规范
尽量避免NULL
根据业务特性，合理的用Check来实现约束，如直播号价格>=0
合理创建索引
结合表的大小、读写频率，合理创建索引。
数据物理删除
用isDelete标识数据删除状态（0：正常 1：删除）
尽量使用视图
简单性：看到的就是需要的
安全性：通过视图用户只能查询和修改他们所能见到的数据
混用范式化和反范式化，减少数据冗余、局部依赖、传递依赖
范式优点
范式化的更新操作通常比反范式化要快
当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据
范式化的表通常更小，可以更好地放在内存里，所以执行操作会更快。
很少有多余的数据意味着检索列表数据时更少需要 DISTINCT 或者 GROUP BY语句。
反范式优点
不需要关联表，则对大部分查询最差的情况——即使表没有使用索引——是全表扫描。 当数据比内存大时这可能比关联要快得多，因为这样避免了随机I/0。
单独的表也能使用更有效的索引策略。
二、输出格式
表名: circle_xx
作者: 敲锣打鼓兔子
日期：2018-04-28
版本：1.0
描述：保存社群基本信息
具体内容：
circleId int,自动增量 用户代码
circleName char(12) 用户名字
......
三、评审
评审时间：根据迭代计划时间进行（QA跟进提醒）
评审方式：会议形式
发起人员：SM组织团队主动发起邀请“评审团”参加
评审团：PO、TM、QA、技术专家、其他组SM（可选）
评审流程：
以团队为单位（非个人或部分人），对新增、修改的数据库表的设计思路进行讲解。
“评审团”结合“数据库表设计原则”进行评审。
二次评审：根据评审情况决定是否需要重复以上步骤进行二次评审。
写在最后
需要pdf的朋友，可以私信“开发输出规范”
阅读起来可能更加的清晰方便
pdf截图