做得好 vs 做得快？

今天聊一个有意思的话题，假如老板让你做个新的系统，你是选择先把功能做起来至于扩展性和可靠性以后再考虑，还是设计一个非常牛逼的系统架构，可以满足未来很多年的发展。前一段时间，某个CSDN技术交流群里有个小伙伴问用户系统怎么设计，然后就有另外的小伙伴上来就给了很高大上的建议，什么用户、角色、权限、分库分表…… 都给考虑了，算算人力，没几个月做不出来。

然后我以半开玩笑的口吻说：别搞那么复杂，先用一个用户表，再加上权限和角色字段区分就可以了，先快速把系统搭建起来，没有什么问题是加一个字段解决不了的，如果有就再加一个字段。如果开始设计那么复杂，万一运气好系统黄了的话不就白做了嘛！那万一运气不好，系统起飞了怎么办？那更简单了，系统都起飞了，还怕老板不给你人做优化！

这个故事中涉及两个选择，花时间做个高质量系统和快速做个低质却堪用的系统，简单点就是好和快之间选一个。通常我们提到好和快的时候还会提到成本，好、快、便宜三者就像CAP理论一样，只能同时选择其中的两种，无法三者都选择。质量、速度和成本三者之间似乎有着不可调和的矛盾。我们这里先去掉一个条件——成本（因为大部分情况下时间才是最大的成本），来单独谈谈好和快之间的关系，说一下我对这两者关系的看法，希望对大家日常工作和学习有所帮助。

现实中如果工作中老板给你安排了一个任务，这时候你有两种选择：1.保质保量做完，但可能会花很长时间。 2.花很短的时间做完，但质量可能有问题。很显然质量和速度是冲突的，做得快大概率做不好，做得好大概率做不快。这时候你会怎么选？

选了你就上当了，在现实情况中，你拿到的不仅仅是1或者2两种选项，可能还有花较少的时间做到较好的质量这种中间选项。我们换个问题，你倾向于快还倾向于好？ 我可以先告诉你我倾向于好，我为什么选快而不选择好？我有如下几点理由：

能用更短的时间得到反馈：

快速将事情做完，获取到结果，才能拿到别人的反馈。众所周知反馈在任何一个人成长的道路上必不可缺，获得的反馈越多，成长的也越快。如果你用短时间完成的任务质量比较低，质量低其实也是一种反馈，你还有大把的时间去改进。总比你花了大量时间做出来一个低质的东西，还没有时间改进强的多。

减少风险：

时间才是人生最大的财富，如果你在某件事上投入了过多的时间，但最后被证明这件事没有任何意义的情况下，也就意味着你会损失大量的时间。快速做完，即便突然发现这件事没有任何意义你损失的也不多。我们在工作中可能经常听到一个词快速试错，试错总是和快速结合在一起，我相信你肯定从来没听过慢速试错吧，快速意味着即便失败，损失也是可以接受的。

快即是多：

如果你想掌握一门技能，不断的练习是你唯一的方式。你重复的次数越多，这门技能你就越熟练，你单次练习的速度越快，单位时间内你能练习的次数也就越多。做一件事也是如此，当然做的次数多了，愈发熟练之后，做这件事的成本对你来说也就越来越低，从而你有更多的时间精力去做更多的事，接触和学习到的东西也会更多，逐渐就会形成一个增长的正循环。

这里需要强调下，做任何事儿也不是一味追求快，而完全忽略了好，毕竟太差的结果就是完全在浪费时间。举个例子，用原本30%的时间拿到50分的结果这不叫快，这叫浪费了30%的时间。真正的快是用原本50%的时间将结果做到80分，而要想做到好（90分+）你可能需要花费120%的时间。真正的快其实是奥卡姆剃刀式的高效。这里我又想起了高德纳的一句话过早优化是万恶之源，很多时候的慢其实因为提前考虑了太多不需要的东西。

你可能也已经看出来了，我这篇文章有点反完美主义，我承认我确实不是完美主义者，但我也不否认时间上很多优秀的作品确实是完美主义者创造的，科学和艺术可能需要完美主义者，但站在工程和实践的视角，其实就是各种利与弊的权衡，这也是绝大多数程序猿所面对的(那些完美主义的程序猿可能因为产出比较慢，早早毕业了[狗头])。做后端的同学可能也听过一句话架构其实是权衡的艺术，这便是最好的诠释。

今天的文章就到这了，这是我在CSDN上的第301篇原创文章，如果你觉得我的文章写的还可以，可以留个赞，如果喜欢我的文章也可以关注下，我是xindoo，一个即将奔三的程序猿。