在开发过程中我意识到一个问题

具体问题就是我没有一个可靠的机制来防止自己犯错

现在的流程是 开发 + 调试 -> 测试同学 -> 上线

这里测试的时间会有点长，因为bug会有点多，然后需要修改bug，然后测试验证
改bug时间 = 理解测试bug描述的内容 + 复现bug + 阅读代码 + 找出漏洞修改 + 测试验证关闭bug

改进后的流程是 开发 + 调试 + 最后整体检查 + 写测试 -> 测试同学 -> 上线

这种开发模式会环节有点多，写测试 + 最后整体检查是多出来的

其实第一个开发模式是不负责任的，把风险转嫁给了测试。我们交给测试的代码应该是在自己看来检查不出问题了（而不是自己不做检查），测试作为上线最后把关验证代码

整体检查一遍其实也不会话费多少时间，就算是code review了吧
整体检查一遍计划时间是3个小时左右，其实就是跑一遍整个prd的描述

编写测试真的会占用很多时间吗？

其实并不见得

首先，我们并不需要为所有代码添加测试

比如 1 + 1 === 2 这种就不需要

其次，我们需要熟悉测试框架和工具，做到信手拈来则会提高效率

哪些代码需要测试，这是个问题。相比测试覆盖率100%这种伟大的目标，我提倡的是指哪打哪的方针，只针对自己没有信心的代码编写测试

随着测试代码的增加收益会随之降低，所以指导思想就是，自己觉得会出错的，后面想要修改实现的，实现复杂的代码需要测试。这样会用极小的代价获取极高的收益

最后测试是一个工具，保证我们代码在自己手中的时候，再一个范围内不出问题的最后一道保障，现在我想将这道屏障竖起来，被丢掉的底裤穿起来

设计模式则是在开发中减少bug，清晰思路，方便扩展，方便修改的手段，这是在编码阶段就有一个良好的结构自然会减少很多bug

这些机制都是尊重墨菲定律而制定的方案，肯定不能百分百解决问题，但是会极大的减小出问题的概率，甚至提升整个项目的效率，提升项目质量
所以后面的开发流程就被我改成了

开发（依赖设计模式原则） + 调试（开发的反馈） + 写测试 + 最后检查 -> 测试同学 -> 修改bug -> 回归 -> 上线

后面的开发流程务必遵守

bug是不可避免的，并且是测不完的，这就需要我们有一个策略能保证项目正常进行，这就是在一个合理的范围内保证项目正常运行。而这个合理的范围具体化就是测试编写的测试用例

其他问题

在开发中我们总想着快点完成任务，有的时候急于求成就会埋下很多不好的设计，想着写完了有时间再过来修改，就像迭代一样，一步一步完善。

还有一种编码方式是一步到位，该做的都做好，后面不需要返工。

这两种方法，暂时我倾向的一步到位为，不需要返工。但是实际工作中确是采用了迭代的方式，一步一步完善的。因为我做不到一步到位，总想着快点完成，控制不住自己

为什么我倾向于一步到位呢？因为返工是有成本的，需要重新理解自己写的代码，需要花费更多的时间。但是因为想要达到完美就止步不前也是不好的，所以其中权衡也没有一个标准答案