开发人员行为规范手册

本文记录所有在团队工作中遇到的问题及管理开发员工的行为规范

想到哪儿写到哪儿,有空再整理!


产品篇

人人都是产品经理

不管你所处岗位与角色,把自己当成产品经理,那么你就是产品经理。
# 与富人为伍,你就不会变的太穷。

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

运维篇

测试中的数据状态管理

使用一组固定的,有代表性且无害的数据,保证可以在每种环境中都能使用。
每个业务点都需要判断数据是否无害冗余且困难,则不如在关键节点上做到无害化处理。

测试任务不过夜

如果有一个测试任务在下班前产生 那么必须当天完成流转,不然为严重延误开发及上线进度。
评论未能加载 DISQUS被屏蔽 请检查网络