通信科技网站设计,建设银行杭州网站首页,无锡高端网站建设平台,wordpress 视频 模版在开发过程中我意识到一个问题
具体问题就是我没有一个可靠的机制来防止自己犯错
现在的流程是 开发 调试 - 测试同学 - 上线
这里测试的时间会有点长#xff0c;因为bug会有点多#xff0c;然后需要修改bug#xff0c;然后测试验证 改bug时间 理解测试bug描述…在开发过程中我意识到一个问题
具体问题就是我没有一个可靠的机制来防止自己犯错
现在的流程是 开发 调试 - 测试同学 - 上线
这里测试的时间会有点长因为bug会有点多然后需要修改bug然后测试验证 改bug时间 理解测试bug描述的内容 复现bug 阅读代码 找出漏洞修改 测试验证关闭bug
改进后的流程是 开发 调试 最后整体检查 写测试 - 测试同学 - 上线
这种开发模式会环节有点多写测试 最后整体检查是多出来的
其实第一个开发模式是不负责任的把风险转嫁给了测试。我们交给测试的代码应该是在自己看来检查不出问题了而不是自己不做检查测试作为上线最后把关验证代码
整体检查一遍其实也不会话费多少时间就算是code review了吧 整体检查一遍计划时间是3个小时左右其实就是跑一遍整个prd的描述
编写测试真的会占用很多时间吗
其实并不见得
首先我们并不需要为所有代码添加测试
比如 1 1 2 这种就不需要
其次我们需要熟悉测试框架和工具做到信手拈来则会提高效率
哪些代码需要测试这是个问题。相比测试覆盖率100%这种伟大的目标我提倡的是指哪打哪的方针只针对自己没有信心的代码编写测试
随着测试代码的增加收益会随之降低所以指导思想就是自己觉得会出错的后面想要修改实现的实现复杂的代码需要测试。这样会用极小的代价获取极高的收益
最后测试是一个工具保证我们代码在自己手中的时候再一个范围内不出问题的最后一道保障现在我想将这道屏障竖起来被丢掉的底裤穿起来
设计模式则是在开发中减少bug清晰思路方便扩展方便修改的手段这是在编码阶段就有一个良好的结构自然会减少很多bug
这些机制都是尊重墨菲定律而制定的方案肯定不能百分百解决问题但是会极大的减小出问题的概率甚至提升整个项目的效率提升项目质量 所以后面的开发流程就被我改成了
开发依赖设计模式原则 调试开发的反馈 写测试 最后检查 - 测试同学 - 修改bug - 回归 - 上线
后面的开发流程务必遵守
bug是不可避免的并且是测不完的这就需要我们有一个策略能保证项目正常进行这就是在一个合理的范围内保证项目正常运行。而这个合理的范围具体化就是测试编写的测试用例
其他问题
在开发中我们总想着快点完成任务有的时候急于求成就会埋下很多不好的设计想着写完了有时间再过来修改就像迭代一样一步一步完善。
还有一种编码方式是一步到位该做的都做好后面不需要返工。
这两种方法暂时我倾向的一步到位为不需要返工。但是实际工作中确是采用了迭代的方式一步一步完善的。因为我做不到一步到位总想着快点完成控制不住自己
为什么我倾向于一步到位呢因为返工是有成本的需要重新理解自己写的代码需要花费更多的时间。但是因为想要达到完美就止步不前也是不好的所以其中权衡也没有一个标准答案
