开发人员行为规范手册
本文记录所有在团队工作中遇到的问题及管理开发员工的行为规范
想到哪儿写到哪儿，有空再整理！
产品篇
人人都是产品经理
不管你所处岗位与角色，把自己当成产品经理，那么你就是产品经理。
# 与富人为伍，你就不会变的太穷。
Agile Software Guide 先启阶段
# 敏捷开发必经阶段（磨刀不误砍柴工）
1、确定项目的利益相关人;
2、沟通确定系统的业务期望与愿景;
3、确定项目的当前状态与未来状态;
4、确定项目的业务范围;
5、需求分解;
6、史诗级（Epic）到主故事级（Master）逐层划分;
7、确定迭代开发需要的主故事列表。
Brook’s Law 布鲁克定律
为已经延期的软件项目增加人手只会让项目延期得更厉害。
# Sprint 能用里程碑解决的问题就不要使用瀑布流
Jira使用总结
Jira 配置时，先配置 问题>问题属性>`状态`和`解决方式`
先配置工作流，再配置工作流方案，把工作流关联到方案中
尽量不要改Jira默认工作流及问题状态。
开发篇
SQL服务注意事项
1、所有的sql文件不得使用中文字命名；
2、sql文件的位置必须放到 统一的Git目录对应的项目模块下，例：.dev/sql/service-name/table-name.sql；
3、sql中不得使用DROP、RENAME命令，限制使用表或字段约束；
4、sql文件以表名命名，如果是对字段的新增以“表名.列名.sql”命名，例：table-name.user_id.sql；
5、update 语句必须有where条件，并严格注明业务原因；
6、SQL文件的产生必须经过三名及以上开发人员的评审会确认；
7、SQL文件在合并到测试分支时必须在生产中提前准备。
日志是调试的最佳方式
日志输出是一门手艺
# CT(Computed Tomography)
导入表格数据如何增强体验
Excel批量导入时必须是以字符串输出至表单，导入时后台不验证，提交时以前端验证数据。
# 减少后台压力，客户端能做的事，尽量在客户端做。服务端只做最终验证一致性
Postel’s Law 波斯托定律 或 鲁棒性法则
保守输出，自由输入。
# 厚积薄发
如果出现500异常开发必须无条件立即解决
500异常表示服务异常，表示程序的承载力不够，不能处理当前的服务。
# 这个异常多数因为没有做到 Postel’s Law 波斯托定律
Knuth’s Optimization Principle 克努特优化法则
过早优化是万恶之源。
# 先写代码，然后找出瓶颈，最后才修复！
枚举类从中间插入新值在有些业务系统中是灾难
如果你的枚举类在数据库的映射类型是int，那么默认存入的是枚举的ordinal()数值（从0开始）
从顶部或中间插入新值将带来原来的数据状态全部错位的现象，这是一个灾难
高效的理解路径的讯息
优雅的URI路径能让开发者减少困惑，URI定义规格：版本号/业务路径/动作
业务路径：必须从大到小、"后者是前者的" 的关系例如： “模块名/分类名/子类名” 词性上一定是名词单数形式；
仅允许使用小写字母、数字、中划线，除模块名可以使用中划线、其它名禁止使用；
动作：保存、删除、更新、取一个、取列表、分页取列表、提交、上传、审批…… 英语词性上一定是动词原型；
路径参数不能使用数字以外的内容 正例：/user/page/1 能不用路径参数就不用路径参数
例：
v1/order/item/save
v2/person/address/remove
v3/member/profile/update
v4/job/task/get
v5/document/title/list
v6/auth-model/client/page
v7/cart/item/submit
v8/item/attachment/upload
运维篇
测试中的数据状态管理
使用一组固定的，有代表性且无害的数据，保证可以在每种环境中都能使用。
每个业务点都需要判断数据是否无害冗余且困难，则不如在关键节点上做到无害化处理。
测试任务不过夜
如果有一个测试任务在下班前产生 那么必须当天完成流转，不然为严重延误开发及上线进度。