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