个人团队的敏捷开发管理方案

CodeWhite7

已于 2023-11-15 09:25:18 修改

阅读量2.3k

点赞数 1

分类专栏：笔记文章标签： 1024程序员节

于 2021-10-24 10:54:41 首次发布

本文链接：https://blog.csdn.net/weixin_46146269/article/details/120930996

版权

笔记专栏收录该内容

11 篇文章 0 订阅

订阅专栏

项目管理方案

需求分析、功能设计、程序设计、代码开发和功能测试(敏捷开发流程)

项目文件管理

项目进度：前端、后端

节点管理：交付时间的节点、计划、甘特图

文档管理：wink文档、项目文档、接口文档、框架文档等

文件管理：项目的资料文件，Excel、流程图、需求书等等

项目问题

命名的规范，文件名称、函数名称、属性名称、css、js规范
进度概念，一定要有一个进度的概念，系统进度
测试概念、写出来的东西肯定不会一下就完整，写完功能点一定要测试不能走捷径
问题点：可以总结问题到一个文档中、开会解决、与开发方案
工作汇报、每日的汇报
git管理、需要熟悉git命令、文件冲突、分支、提交规范的管理。
接口文档规范
质量管理：开发习惯问题：不能说我方便这样写、调试的方法要及时删除、重复的东西需要抽取、不能说后续再去完善、最好尽早的发现，后续处理，可能牵一发动全身、有缺陷的请使用 // TODO 标注、方法名称和参数需要标注
需求不明确，有时候有需求不能及时的解决、
由于软件的复杂性，总会由于环境不同、工具不同、新技术的不确定、测试的不充分而带来意想不到的结果

项目总结

这个项目遇到的最大困难
怎么解决的
学到了什么
对后期的工作又有那些启发

代码编写要求

遵循前后台代码规范
项目中不允许出现多余的代码，代码生成器生成的代码如果没有用到要及时清除
接口单一原则，一个接口一个方法坚决只允许完成一件事情，如果是同一类任务，需要通过if判断来处理不同的逻辑，那么if判断中的代码一定要抽取出方法而不能全部挤在一个方法中
禁止硬编码，所有的配置一定要写到配置文件中
禁止编写复杂sql，除非不得已为之，在实现功能和可读性之间我们更偏向于可读性
接口传值最小化，前端传值给后台应该尽量少传，后台能自己处理的就自己处理，把业务逻辑尽可能的留在后台
禁止使用map传参写接口，必须使用统一的AjaxResult类作为参数传递的格式
接口的录入公共参数不需要录入比如createBy，createTime limint 这些参数不需要录入。
接口录入要进行分类，不能全部录在一个分类下
如果处于测试需要要写死用户信息，那么一定要通过拦截器去写，不能再代码中硬编码
对于暂时无法实现的业务逻辑一定要在代码中加待办的标注 //TODO ,在发版本之前先检查一下所有的TODO标记
自己开发的功能一定要自己进行测试，测试的时候要尽量使用符合业务要求的数据进行测试，通过后在用非常规的字符进行测试，自己测试完了在移交到测试那边测
每天下班前要提交当天完成的代码，代码提交的备注尽量写清楚本次提交的目的
编写查询功能一定要考虑数据库表的记录条数，如果数据量上百万的表要尽量分历史表与作业表
金额计算要使用专门的类BigDecimal
及时解决程序员的环境、配置等问题，让其安心开发
bug要及时督促修复不要留到后期集中修复，那样会导致后期要交版本的时候非常紧张

BUG修复

测试要把发现的bug提到极客平台上并选择对应的开发人，和功能
开发收到bug提示后要及时响应解决完bug后，在极客平台把bug设置为解决状态,并选择方案为修复代码
测试收到开发解决的bug后进行bug的回归，如果确实解决了则关闭bug

每日三个问题

昨天做了什么，是否完成
今天打算做什么
提出团队或者自己的问题如：

阻碍工作的问题
需要协助的问题
可以改进的问题
代码或者功能有变动需要通知其他人知晓的问题

晨会的目的是同步信息，发现阻碍项、项目经理要总结工作情况，鼓励与批评对应的人

注意事项：

体验不好的界面坚决拒绝，不管开发愿不愿意都要改，对开发的宽容就是对客户的伤害，对客户的伤害就是对公司整体员工的伤害

接口文档规范

测试管理

相应的软件测试管理.xlsx文档。

进度管理

每日的进度汇报：每日工作.xlsx

整体的进度汇报: 项目规划.xlsx

前端代码规范

vue文件：

<!-- 
	Author: XXX 
	Date: 2021-08-21
	Description：工作单模块 
-->
<template>
</template>

字段注释：

// 姓名
let name = "小米";

函数注释：

/**
 * Book类，代表一个书本.
 * 
 * @date 2021-08-01
 * @param {string} title - 书本的标题.
 * @param {string} author - 书本的作者.
 */
function book (title, author) {
  this.title = title
  this.author = author
}

有时我们发现某个可能的 bug，但因为一些原因还没法修复；或者某个地方还有一些待完成的功能，这时我们需要使用相应的特殊标记注释来告知未来的自己或合作者。常用的特殊标记有两种：

// FIXME : 说明问题是什么
// TODO : 说明还要做什么或者问题的解决方案

function book (title, author) {
  this.title = title
  // TODO: 这是一个未完善的方法
  this.author = author
}

具体看：前端代码规范.pdf

后端代码规范：

具体看阿里巴巴代码规范.pdf

数据库规范：

建表规范

建表规范

表设计规范

1.主键必须为：ID，类型 [Long(19)] 唯一索引，因为历史原因暂时用String(32)类型
2.外键字段命名：{【关联表名】去掉业务前缀}+“_”+ {关联字段名}，例如：order_main_id
3.区分位: iz_* [String(1)] 1表示是 0表示否，（禁用 is_,代码生成实体有问题 )
4.状态位: *_status [String(1-2)] 状态字段必须加注释说明每个值代表含义
5.字段命名，多单词采用下划线分隔例如：school_id
6.索引命名：主键索引命名为：pk_表名缩写_字段名（索引要求全库唯一，为兼容多数据库）；
唯一索引命名为：uniq_表名缩写_字段名 或 uk_表名缩写_字段名；
普通索引命令为： idx_表名缩写_字段名（表名缩写：下划线分隔单词首字母组合）
7.区分、状态、类型字段，尽量用String类型，避免数字类型的一些问题；如果需要考虑性能建议用int类型
（禁用tinyint类型，需要兼容其他数据库）；

表业务前缀和建表标准字段

1.表命名必须带上业务前缀：例如 sys_开头(系统表前缀)
2.所有的表加字段：所属部门，用于部门数据权限
3.所有的表加字段：创建时间，创建者，最后更新时间，更新人
4.逻辑删除字段，del_flag [String(1)]，1表示删除 0表示未删除，可选择加
5.乐观锁字段， update_count[Integer]，可选择加
6.字符串类型字段，varchar类型长度不允许超过1000（过长转库会变类型）
7.大文本尽量少用，字段类型采用text、longtext，禁用blob系列类型（必须用要确认）

帮助脚步

ALTER TABLE `表名`
ADD COLUMN `create_by`  varchar(32) NULL COMMENT '创建人',
ADD COLUMN `create_time`  datetime NULL COMMENT '创建时间' AFTER `create_by`,
ADD COLUMN `update_by`  varchar(32) NULL COMMENT '修改人' AFTER `create_time`,
ADD COLUMN `update_time`  datetime NULL COMMENT '修改时间' AFTER `update_by`,
ADD COLUMN `del_flag`  varchar(1) NULL COMMENT '0表示未删除,1表示删除' AFTER `update_time`;

其他说明：

表字段注释，每个字段必须设置注释说明;
表字段注释，状态类型的字段必须说明取值规则（比如性别sex取值规则）
比如：‘性别 0男,1女’
索引，查询频率高的字段加索引（单字段索引、组合索引、唯一索引）;
状态、类型字段，尽量用字符串varchar类型1-2长度，少用int类型，避免不必要的问题。****

Git规范：

常用命令：git教程.pdf

分支：

master：项目的主分支，给用户提供正式版本的。
release:release是发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
develop：开发用的分支为Develop。
feature：feature是为了开发后续版本的功能，从Develop分支上面分出来的。开发完成稳定后，要再并入Develop。
fixbug：fixbug分支是从master分支上面分出来的。fix结束以后，再合并进Master和Develop分支。最后，删除"fixbug分支"。

提交规范：

1. type

用于说明 commit 的类别，只允许使用下面7个标识。

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

2. scope(可选)

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

3. Body 部分是对本次 commit 的详细描述，可以分成多行，每行尽量不超过72个字符。下面是一个范例。

<type>(<scope>): <subject>
// 空一行
<body>

新增接口的示例：

feat(Controller): 用户查询接口开发
fix(Bean): 用户查询缺少username属性

新增xxxxx

写在后边：

如果需要软件测试文档、前端代码规范、以及阿里巴巴java规范可以私信我。