本文主要是介绍【原创】有时候，慢即是快，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一
从我住的地方到公司，有两条路。
一条要经过一个天桥，路程稍微远一点，好处是可以安全放心的过马路。
另一条路程稍微近一点，但是要等过马路的红绿灯，如果刚好是绿灯，就会很快。
我一直习惯走天桥的这条路，但是路上我经常看到更多的人是去走红绿灯那条路，刚开始不是很理解，为此我特意用地图对比了两条路线，发现红绿灯那条路近一些，这个应该是主要原因吧，另外不用爬桥，应该也有一定的关系。
反观我自己为啥要选择天桥这条路呢？主要原因就是不想等红绿灯。
没有红绿灯，我感觉一路通畅，路上听一些音频时，也不用担心过马路的危险；
没有红绿灯，我省去了等待红绿灯的焦躁，心情会好很多；
没有红绿灯，我可以随时调整自己步伐的快慢，不用想着去抢绿灯的时间点，时间在我自己把控；
没有红绿灯，虽然路稍微远一点、陡一点，但我努力一下还是能更快的到公司；
这时候，慢就是快。
二
我记得高中数学试卷的第一部分是选择题，有 12 道，每题 5 分，一共 60 分，在 150 分中占比 40%，所以是每次考试必争分之地，多错或少错一道选择题的差距会很大。
大家当然都知道选择题的重要性，但是因为时间的原因，又不可能每道选择题都去实际推演出最后的结果，所以当时比较流行的做法是「排除法」，具体啥意思就不用我解释了吧，相信大家都用过。
但是我比较笨，总是担心这种方法不靠谱，还有一个担心是排除法做出来的题，就算结果是正确的，也并不代表自己会做这道题，那么就是自己欺骗自己，如果真正高考时候的选择题不适用排除法该怎么办呢？
我没有去找别人寻求答案，我只是默默的在每次做选择题的时候，继续使用推演法，至少要保证我会的确实是会了。
这样造成的问题就是我的时间分配要做调整了，我在选择题上花费的时间会更多，但好处是我所有的题都是推演出来的，相对来说我比别人做题的数量也更多，久而久之锻炼的机会也更多，在选择题上面的准确度也更高。
有时候还会出现很多人把时间放在最后的大题上，结果大题太难没做出来，我呢，刚好没时间做大题，但是前面题的准确率又更高，总分反而就更高了。
这时候，慢就是快。
三
我一直给组里面同学强调，长期项目的质量把关要更严格一些，用例颗粒度要更细一些，哪怕多花一点时间，也一定要做到每次的项目都不要留坑。
主要是因为我们之前经历过爬坑的痛苦。
如果一个项目，本次测试只覆盖了必要的测试点，满足了主要功能诉求，但是对于设计不合理，甚至用户操作稍微变更一下就满足不了需求的情况都放过了。
那么可预见的未来是，后续的项目迭代就不是新功能的迭代了，而是一方面不断去填补用户新的操作路径的需求覆盖（每次都只考虑用户当前的需求，没有扩展，其实就是没有解决用户的根本诉求），另一方面就是不断在不合理的设计上继续打上更多的不合理设计的补丁。
久而久之，这个项目就会千苍百孔，随便一个修改都是牵一发而动全身，每个参与项目的人都会身心俱疲。
如果同样的项目，每次的合理性考虑都很充分，所有操作路径都有完整覆盖，那么每次的关注点都可以集中到本次修改的需求，以及很少的关联影响范围上，这样就是良性迭代，项目不会因为迭代次数增加而身陷囹圄。
虽然这样做，每次迭代的项目时间会拉长，但是整体来看，节省的时间却是大把大把的。
这时候，慢就是快。
以上，不知道你的项目中是否存在类似「头痛医头，脚痛医脚」的解决方案？碰到这种情况你是如何解决的呢？
不知道你是否同意这些例子中「慢即是快」的说法，请点个「好看」让我知道你的态度。
本文首发于公众号「sylan215」，十年测试老司机的原创干货，关注我，一起涨姿势！
这篇关于【原创】有时候，慢即是快的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
