项目管理
2023-05-04 17:20:28 0 举报AI智能生成
项目管理中的各种方面
作者其他创作
大纲/内容
项目管理
代码管理
vs装企业版，在做功能时参考下代码图，看是否清晰
代码
规范
项目命名
微服务命名
镜像命名
容器命名
代码规范
日志规范
统一标题，分类，对应标志，内容。方便查找与统计分类等
服务器使用规范
例如：使用后要关闭所有应用再离开服务器
接口规范
比如公共接口应该有标识，不然新人按照页面上的接口直接修改，然后其他页面上的接口也用到了，结果会导致各种影响
代码检查
技术领导检查
小组交叉检查
功能
可靠
功能必须可靠，哪怕出错了也要有记录或重试机制。比如基于消息队列的要有本地事件表保证事务与可靠性
可用
任何时候都要能可用或者能替代
可查
每个操作都要有记录日志，并且可视，有页面可以让非技术人员也能清晰的了解过程，能够捕捉甚至回溯整个事件
异常可以分为系统异常和业务异常，系统异常例如程序错误等给开发看的，业务如此例如校验不通过，流程数据缺少等给业务看的，两方面的监控与处理，将业务问题抛给业务人员处理，减少开发处理
容错
系统要有容错率，必须要能够让非技术人员也能矫正问题，比如推送在失败后要有页面能看到推送的过程，失败了有原因可以看到，解决原因后非技术人员可以自己手动重新推送
测试
测试方向
验证功能完整性
验证数据完整性
验证流程完整性
验证数据正确性
bug交互流通
例如：在禅道上前后端联调，后端接口完成，将任务转前端对接，可以将自己设为抄送人，在前端对接完成后，提交测试时，自己也可以知道当前任务状态和进行完整的测试
测试流程
自测
交叉测试
测试技巧
将所有功能点分布到思维导图上，包括流程，功能，进度等
开发与测试在功能思维导图上或者execl等可视化界面上操作测试进度
例如：在提测的时候开发自测功能图上的流程和功能，编辑进度，再提交给测试，测试再对每个功能和流程做回归测试
自动化测试
使用apifox等设计测试用例，执行用例流程，造数据等
自动化测试的好处是，可以积累以前的测试用例，在上线的时候只测试修改的或新增的功能，其他功能直接使用积累的测试用例自动测试，这样就不会导致新需求的更改测试测不到全部功能，导致其他功能受影响
性能测试
使用apifox导出的测试用例在jmeter中进行压力测试等
上线
可以将线上数据库备份到测试库先模拟上线一次
可以减少线上数据库的配置缺失问题和未知问题
灰度发布
代码理念
统一理念
例如：DDD 在需求分析，模型设计，代码落实等统一思想
代码编写理念
例如：职责单一，可复用，可扩展等
文档管理
模型设计历史文件
需求文档等历史文件
流程图脑图时序图等历史文件
阶段里程碑等历史文件
前后端对接负责模块等历史文件
接口文档
swagger+yapi
自动生成文档+自动同步+mock+权限
项目流程文档
包含项目需求来源，各服务的作用，关联与执行顺序，产出结果等
项目关系文档
项目代码与数据库的关系文档，防止改动一处，处处报错
数据库关系文档
数据库的各种关联关系，包含外键关联或其他关联的数据
部署
云服务器
镜像发布
CICD
交付流水线
镜像根据环境分支发布
项目多服务使用正则匹配单服务更新
镜像根据版本/分支创建有特殊标识的镜像
本地推送+云托管
解放服务器镜像生成等的压力
本地推送可能会因为每个人电脑不同而不够稳定，也不能确实的保证本地发布的追溯版本，必须约定先提交后生成，不然无法保证当前发布的分支版本代码后面是不是改了后再提交，导致提交分支代码与镜像不一致
k8s容器编排管理
微服务管理
云数据库等等中间件
无感知服务发布
k8s自带pod无缝更新
请求加版本号，网关更具版本号路由
重试+高可用
无感知发布不影响微服务团队其他人的测试与调用
只允许子账号进行发布，主账号用来控制权限与强制规则，比如开发阶段只能操作dev不能操作发布环境等防止发布错乱
版本管理
sourcetree工作流管理
功能
发布版本
补丁
多版本并行管理
线上版本版本分支 例：1.0
版本分支 例：1.0
发布版本镜像
发布版本数据库
测试分支 例：1.0
测试版本镜像
测试数据库
测试版本分支数据库脚本等版本修改文件
测试分支 例：2.0
测试版本镜像
测试数据库
测试版本分支数据库脚本等版本修改文件
本地
本地数据库
本地新功能分支/修复分支
本地数据库脚本等版本修改文件
镜像命名规则
用户名+版本+git提交版本名+时间戳
多版本并行开发
1.前后端同步并行方式
前后端先确定好这个版本需要的接口，然后后端直接出接口的输入输入mock接口，前端直接对接，后端再填充业务
2.后端先行
有时候前端不充裕或者前端比较复杂，那么后端的进度可能比前端快，那么后端可以在当前版本接口出完的情况下，直接开下个版本的分支，继续接口开发，等待前端需要对接的时候，再返回来对接。这样可以保证前后端不会因为互相等待而浪费时间
如果在等前端，然后版本规划还没有的话，可以让后端写测试用例，单元测试，增强流程正确性
3.前端先行
一般很少见，这个前端直接不断写静态或使用mock接口不断按版本做下去，到时候要开发某版本的时候，再到分支上对接就可以了
总纲
项目计划
项目风险
项目质量
项目进度
项目规划
整理工作规划与项目阶段,里程碑等
需求分析重要：确定用户业务目标
补齐追获资料
统一设计风格
任务推进
催进度/同步消息
阶段演示/里程碑验收
架构
明确架构理念
明确架构风格
例：DDD六边形架构
明确各中间件及组件
技术选项
选择第三方大众熟悉优先
不需要自己培训
选择兼容差异好的
比如dapper和hibernate,hibernate可以缩小sql大手子和新手的差距，防止太大的差异
0 条评论
下一页
