新年第三周，解答知乎的问答了解了二叉树、尝试跑了flutter demo，却忘了最重要的网络基础的学习。
关键词
上线失败
记一次上线失败
本周上线一个打通A、B两个系统的功能，最终因为新开发的功能影响了B系统其它功能模块，又没能及早的发现，导致线上回滚，上线失败。下面记录了本次上线从开发到上线的全过程。
周一：收到开发该工能的需求(后面对该功能简称成为F)。
周二：接入Jenkins，完成功能逻辑思维导图，包含功能数据流向、交互逻辑、测试用例和开发对应的文件。并将逻辑发到工作群，在确认修正功能逻辑后定版。
周三：基本功能开发完毕、mock开发完成，后端接口没完成，于是联调定在了周四。
周四：加班联调完毕，在联调中发现很多mock开发阶段没有考虑到的问题，很多时候是前端没有考虑清楚，错误的让后端同学花时间debug。
周五：测试人员在测试环境测试，开发修复
周六：修复周五剩余的bug，下午两点正式上线到生产环境。生产环境测试开发的功能，一切正常。准备打卡下班。突然，xx模块挂了、yy模块不能正常工作...。最后不得不做出回滚的决定。
现在结合我们团队的开发流程，针对开发F功能上线失败的案例进行反思。团队的开发流程包括：理解需求、逻辑梳理、验证方式、分支开发、及时反馈、code review和上线验证。
首先是理解需求
原型如图一。需求要做的是将A系统的工程与B系统的环境相关联，实现在B系统对A系统工程的运行态的进行管理维护。
图一 工程和环境
第二步是逻辑梳理
包括数据流向、交互逻辑、开发关联文件等。 逻辑梳理脑图如图二
图二 开发逻辑图
旁白：
梳理逻辑的意义：逻辑梳理目的是为了将对需求的理解转化为可执行的操作，在梳理逻辑的过程中将需求传达不明确的点清晰化，同时对开发的模块有一个整体的认识。还有梳理的逻辑可以作为维护的文档，方便后面对功能的维护和开发。
本次逻辑梳理的不足：
- 在这次梳理逻辑输出脑图发到工作群后，没有同时和后端、测试、产品过一遍。导致自己分别和后端、测试过自己的流程图。时间上浪费了。
- 需求信息同步时，没有让测试、前后台开发参与，结果是测试人员得从前后端人员的脑图中了解本次开发的功能，进而编写测试用例。
- 没有进行功能影响范围评估，只是考虑新增功能的开发和测试。如从A系统直接跳转到B系统和从A系统选择发布服务到跳转B系统(B系统有发布服务到harbor的功能)默认选中的工程和环境是不同的(见图一工程和环境)。在功能开发时没有考虑后者，导致功能不完整。
第三步是编写测试用例
让自己开发的功能可用是开发者的基本素养。如何保证开发功能的可用性，而不是随便点击就报错，这就需要经过有效的测试。首先有效的测试必须是在理解业务需求和明确功能影响范围的基础上的。其次，有效测试的可执行就需要测试用例和单元测试(目前团队前端开发还没有引入单元测试�)来保障。最后，测试用例的全面性能够帮你最大限度降低线上bug。
在这次编写开发用测试用例的过程中，没有遵循最小闭环测试的准则，而是局限在对F功能本身的测试。结果就是开发用测试用例本身是残缺的，测试用例全部通过也无法保证系统的可用。功能可用是系统可用的前提，功能可用不能保证系统运转正常。同时基于最小闭环编写测试用例还能很好的平衡开发和自测的时间矛盾(开发用测试用例如果考虑了全流程的方方面面，编写用例本身会占用太多时间(并且有专业测试做这件事)。基于最小闭环的开发与自测，能够合理的安排功能开发，不会因为细节影响整个功能的开发)。所以关于测试用例的编写有两点思考
- 基于最小闭环编写开发用测试用例
- 借助专业测试人员的用例
下面对比本次开发用测试用例[基于F功能本身]和基于最小闭环的测试用例(部分)，注意测试用例都体现在B系统
基于F功能本身的测试用例：
工程-环境展示值的优先值(下面使用展示优先级替代)
工程展示：上次选中的工程 > 工程列表第一个工程
环境展示：上次选中的环境 > 默认环境 （前提是已选中工程）
- A系统没有建立工程，弹窗提示”前往ddp创建工程“，重定向到/login页面
- A系统有建立工程，默认值参考 展示优先级
- 浏览器有选择值，展示参考 展示优先级
- 切换工程和环境，跳转首页，并reload页面，重置应用状态
基于最小闭环的测试用例：
- A系统没有工程时，从A系统跳转B系统，B系统弹窗提示”前往ddp创建工程“，重定向到/login页面
- 在A系统创建工程，从A系统跳转B系统，B系统工程和环境展示参考 展示优先级，跳转到首页
- 切换工程和环境，跳转首页，并reload页面，重置应用状态
上面两个测试用例的区别是基于F功能本身的编写的测试用例只是关注自己功能本身，而基于最小闭环的测试用例则是基于系统，数据流向是具体的。
第四步则是分支开发
git flow就不多介绍了，团队git flow也是基于这个做了些许改动。团队在使用git flow的两点不足之处
- 后端发布版本没有打tag，回滚时只能看commit信息，找到上周上线的版本。
- 对fix分支进行合时需要手动合并到多个目标分支，存在可能遗漏的情况。
过年这段时间找找合适的工具，希望做到git flow更好用。
第五步及时反馈
首先说明，及时反馈是贯穿在整个应用开发生命周期的。从需求确认、功能模块设计、界面交互、前后端联调和功能测试等，无不涉及沟通、涉及反馈。及时有效的反馈是信息保持通畅的基础。在这点上团队做的还是挺好的。通过早晚对开发进度，测试与开发通过禅道异步进行沟通(遇到阻塞流程的bug时直接当面沟通)，完善功能点后通过发gif图到群里通知大家等方式保持开发、测试人员信息的通畅。
第六步 code review
这里得重点批评自己。这次开发的功能自己review 后上线了。
团队推崇结对编程，有code review的习惯。因为自己单独做一个react 栈的项目，团队其他成员使用vue栈开发其它项目，于是"大全独揽"，未找其他成员review。code review其实是不分框架与语言的。code review重点关注的我认为有几点：
- 代码风格, 好在我们有prettier、eslint帮助统一格式化代码风格，利用husky让我们使用git hook钩子变得简单，无需多余的格式化代码动作。
- 业务逻辑。若能清晰的用语言完整说出自己代码实现的逻辑，并考虑了业务场景，则说明功能实现是完整的。代码就是用编程语言将业务逻辑抽象的实现。
- 代码设计。好的代码肯定是经过设计的。
因此在code review中业务逻辑和代码设计时部分语言的，这两点在code review的过程中，相互碰撞，能收到意外的惊喜。
第七步上线验证
代码开发完了、自测没问题都不算功能完成，只有经过专业的测试人员测试并上线了，功能才是完成了。
这次功能开发完后，进过开发和测试环境的测试验证，功能本身是开发完了。但我们忘了很重要的一点，功能全流程测试--数据流向的上下游都需要串联起来测试，一切正常后才能上线。这次是意识上的疏漏，需要谨记。
说到全流程测试，工作量就大了。因此后面团队的接口测试、单元测试、ui测试、集成测试就得做到自动化。今天测试组的伙伴进行了接口自动化的测试，这是在测试自动化的路上迈出的一小步。前端什么时候测试驱动开发呢(现在开发前先写测试用例应该也算吧)，引入静态类型语言会不会是一个选择？先自己搞搞
总结
开发流程规范要践行、code review不能马虎、找到合适的工具避免做重复的事。重要的点切记理清需求后，记得问一句这次的功能影响范围是什么，数据流向清楚了吗。
网友评论