今天聊一个有意思的话题,假如老板让你做个新的系统,你是选择先把功能做起来至于扩展性和可靠性以后再考虑,还是设计一个非常牛逼的系统架构,可以满足未来很多年的发展。 前一段时间,某个CSDN技术交流群里有个小伙伴问用户系统怎么设计,然后就有另外的小伙伴上来就给了很高大上的建议,什么用户、角色、权限、分库分表…… 都给考虑了,算算人力,没几个月做不出来。
然后我以半开玩笑的口吻说:别搞那么复杂,先用一个用户表,再加上权限和角色字段区分就可以了,先快速把系统搭建起来,没有什么问题是加一个字段解决不了的,如果有就再加一个字段。如果开始设计那么复杂,万一运气好系统黄了的话不就白做了嘛! 那万一运气不好,系统起飞了怎么办?那更简单了,系统都起飞了,还怕老板不给你人做优化!
这个故事中涉及两个选择,花时间做个高质量系统和快速做个低质却堪用的系统,简单点就是好和快之间选一个。通常我们提到好和快的时候还会提到成本,好、快、便宜 三者就像CAP理论一样,只能同时选择其中的两种,无法三者都选择。质量、速度和成本三者之间似乎有着不可调和的矛盾。我们这里先去掉一个条件——成本(因为大部分情况下时间才是最大的成本),来单独谈谈好和快之间的关系,说一下我对这两者关系的看法,希望对大家日常工作和学习有所帮助。
现实中如果工作中老板给你安排了一个任务,这时候你有两种选择:1.保质保量做完,但可能会花很长时间。 2.花很短的时间做完,但质量可能有问题。 很显然质量和速度是冲突的,做得快大概率做不好,做得好大概率做不快。 这时候你会怎么选?
选了你就上当了,在现实情况中,你拿到的不仅仅是1或者2两种选项,可能还有花较少的时间做到较好的质量这种中间选项。我们换个问题,你倾向于快还倾向于好?我可以先告诉你我倾向于好,我为什么选快而不选择好?我有如下几点理由:
能用更短的时间得到反馈:
快速将事情做完,获取到结果,才能拿到别人的反馈。众所周知反馈在任何一个人成长的道路上必不可缺,获得的反馈越多,成长的也越快。 如果你用短时间完成的任务质量比较低,质量低其实也是一种反馈,你还有大把的时间去改进。总比你花了大量时间做出来一个低质的东西,还没有时间改进强的多。
减少风险:
时间才是人生最大的财富,如果你在某件事上投入了过多的时间,但最后被证明这件事没有任何意义的情况下,也就意味着你会损失大量的时间。快速做完,即便突然发现这件事没有任何意义你损失的也不多。 我们在工作中可能经常听到一个词快速试错,试错总是和快速结合在一起,我相信你肯定从来没听过慢速试错吧,快速意味着即便失败,损失也是可以接受的。
快即是多:
如果你想掌握一门技能,不断的练习是你唯一的方式。你重复的次数越多,这门技能你就越熟练,你单次练习的速度越快,单位时间内你能练习的次数也就越多。做一件事也是如此,当然做的次数多了,愈发熟练之后,做这件事的成本对你来说也就越来越低,从而你有更多的时间精力去做更多的事,接触和学习到的东西也会更多,逐渐就会形成一个增长的正循环。
这里需要强调下,做任何事儿也不是一味追求快,而完全忽略了好,毕竟太差的结果就是完全在浪费时间。举个例子,用原本30%的时间拿到50分的结果这不叫快,这叫浪费了30%的时间。真正的快是用原本50%的时间将结果做到80分,而要想做到好(90分+)你可能需要花费120%的时间。 真正的快其实是奥卡姆剃刀式的高效。 这里我又想起了高德纳的一句话过早优化是万恶之源,很多时候的慢其实因为提前考虑了太多不需要的东西。
你可能也已经看出来了,我这篇文章有点反完美主义,我承认我确实不是完美主义者,但我也不否认时间上很多优秀的作品确实是完美主义者创造的,科学和艺术可能需要完美主义者,但站在工程和实践的视角,其实就是各种利与弊的权衡,这也是绝大多数程序猿所面对的(那些完美主义的程序猿可能因为产出比较慢,早早毕业了[狗头])。做后端的同学可能也听过一句话架构其实是权衡的艺术,这便是最好的诠释。
今天的文章就到这了,这是我在CSDN上的第301篇原创文章,如果你觉得我的文章写的还可以,可以留个赞,如果喜欢我的文章也可以关注下,我是xindoo,一个即将奔三的程序猿。
如果觉得《做得好 vs 做得快?》对你有帮助,请点赞、收藏,并留下你的观点哦!