《工作模式的探索与实践课件》由会员分享，可在线阅读，更多相关《工作模式的探索与实践课件（54页珍藏版）》请在金锄头文库上搜索。
1、工作模式的探索与实践当下的痛点o 任务追踪和分配的过程，沟通效率低、信息延时高o 开发过程中的需求、任务、成果相互孤立，缺少关联o 成果复用率低、交接周期长、人员替代成本高o 有些同样或类似的事情，可以交给机器做的，但还是在进行手工操作目录o 复杂的事情简单化o 开发的标准统一化o 做事的过程流程化o 项目的管理方法化o 重复的工作自动化o 有待改进的地方复杂的事情简单化为什么要把复杂的事情简单化？可实施 可交付 可追踪可实施-任务拆解可实施-任务拆解系统拆解为各个子系统分解后，我们能够明确：职责：做什么，不做什么和其他子系统有什么关系可实施-任务拆解子系统拆解为更为具体的任务需求分析数据库设
2、计接口实现可交付-里程碑可追踪-责任到人开发的标准统一化工程结构的标准标准化不同编程语言的工程结构统一开发规范有了统一的标准才能做更多的事后台设计的标准设计以合适的载体呈现，结合到版本控制里目前的设计文档都存在代码库内，代码随着设计的变更而变更，两者同时随着版本演进UML：需求分析SQL：数据库设计Swagger：接口设计UMLSQL数据库查询语言完成数据库表设计后，将建表语句导出并按规范进行修改。修改数据库设计后，需写升级脚本来对数据库进行升级。Swagger以Swagger文档为载体，维护Restful接口文档按照Open API规范对接口进行设计统一通用的参数如分页参数的标准Swagge
3、r容器化部署的标准o 服务无状态化o 统一规范的日志输出（日志收集）o 一致的Dockerfile及工程结构（同一种编程语言）o 一致的容器部署配置（命令行部署工具、图形化部署工具）做事的过程流程化我们的工作流程是怎样的需求阶段设计阶段编码阶段测试阶段发布阶段需求阶段工作内容输入输出梳理功能列表及使用对象原始需求UML用例图分析功能的业务流程原始需求UML用例图UML活动图UML状态图设计阶段工作内容输入输出说明关键技术预研UML用例图UML活动图UML状态图关键技术点demo代码创建代码仓库Bitbucket仓库地址必须遵守gitflow架构设计UML用例图UML活动图UML状态图架构图UM
4、L类图UML时序图使用PlantUML完成UML图，并存储在代码仓库根目录uml文件夹下。数据库设计UML类图UML时序图DDLER图接口设计数据库DDLER图UML活动图UML活动图Swagger文档swagger.yml文件存放在代码仓库开发阶段工作内容输入输出集成开发环境准备架构图集成开发环境部署配置单元测试案例编写UML活动图UML类图UML时序图数据库DDLER图Swagger接口文档单元测试源代码业务实现代码编写业务实现源代码测试阶段工作内容输入输出开发人员自测单元测试报告集成测试环境准备集成测试环境配置提交测试组测试测试Bug修复发布阶段工作内容输入输出打包发布可部署的软件包项目
5、的管理方法化我们是如何把控进度的敏捷开发冲刺、看板站会周例会工作日志工作周报Tempo冲刺、看板每周作为一个Sprint（冲刺），将待解决的任务列在看板上，实时追踪任务的进度，可以一目了然的看到所有任务处在什么状态站会每日晨会跟踪进度和问题，15分钟左右即可昨天做了什么今天要做什么遇到了什么问题，需要什么协助周例会每周例会回顾总结并定下周计划工作日志通过每天记录工作日志来记录工作细节和汇报工作情况工作周报Tempo我们是如何把控质量的Git FlowCode ReviewUnit TestGit Flow项目开发中，多人合作是非常常见的。人一多，问题便会接踵而至：代码分支合并版本迭代、发布Bu
6、g修复为了更好的管理代码，需要制定一个工作流程Git Flow多人协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去feature与bugfix的提交关联到对应的Jira任务或者缺陷提交的信息中明确表明当前提交做了什么，并保证只包含此次内容的提交Code Review开发工程师的直接产出就是代码，代码的健壮性就直接决定了交付物的质量当一个单独的功能开发完成后，需要发起Pull Request提出对代码进行合并，当经过Review后才允许并入主分支功能相对简单的时候可以只走bitbucket线上进行Review即可功能相对复杂的时候需要相关工程师一起开会进行ReviewC
7、ode ReviewUnit Test单元测试针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作重复的工作自动化 脚手架工具 定制Spring Boot脚手架，进一步满足企业级开发场景o 按既定规范初始化工程结构o 加入通用的包及工具类o 加入容器化相关配置以支持CI/CDGit Hook检查代码格式多人协作开发时，由于每个人编码习惯不同，经常会导致一个工程内的代码风格各异，导致可读性和可维护性降低Git Hook检查Git提交信息提交类型必须为规定的类型提交的信息格式要符合定义的规范持续集成与交付使用Jenkins完成持续集成、持续交付持续部署待实现持续维护的代码库才适合，也相对有
8、意义去做持续集成、持续交付持续集成持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起持续交付持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的类生产环境中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。CI、CD目前的一些落地Deploy和UPMCI、CD与UPM的结合自动构建镜像自动部署持续集成与交付的前后对比前v无法确保本机环境污染（漏提交等）v时间成本高：需要手动进行全过程v有人力成本：需要有人去做这个事后v专门的Build Server，确保环境干净v时间成本低：机器自动化构建v无人力成本：无监督机器自动化v可以较早发现集成过程遇到的问题，进而避免返工有待改进的地方有待改进的地方 单元测试做的不够好（TDD测试驱动开发），可与Git Hook结合 Swagger接口文档手工编写效率较低（制作Swagger图形化编辑器工具）工作流程还需要进一步实践和落地 还未最大限度的利用好手头已有的工具 Crucible：和Bitbucket配套使用的Code Review工具，还没用起来 Confluence：决策日志尚未广泛使用
