快速成长的必备软技能25————轻易不要造轮子
我们有些兄弟，对技术和解决问题有极大的热情，但又会有个小问题，有事就容易上头，总想自己去造轮子。
我之前经历过一个项目，做移动互联网挂号的，甲方是一个超级大三家。
为了应对流量冲击，设计的时候势必要引入消息队列，去削峰填谷。
当时整个团队都很有极客精神，技术水平也不错，感觉MQ中间件比较笨重，就花了半天，借用Redis揉了一个。
结果上线不久，消息一扩散，大家都来抢号源，没几天系统就崩了。
于是在这个基础上，越走越远，调优，抗住，崩了，再调优。
甲方的人也坐不住了，用户叫骂声一片，毕竟看着有号但挂不上，过一会儿系统恢复又没了，能不急么。
痛定思痛，用了MQ，好了。。。
复盘时，大家还是七个不服八个不愤，认为自己可以继续调优。
这时候，项目负责人问了一句，这个MQ中间件，别人优化了N年。你们凭啥觉得自己一两周的赶工，能干过别人N年的努力呢？
其实，在业界，如果现有技术如果能满足要求，成本最低的方法，往往是使用现有技术。
当现有技术无法满足要求时，大家会想办法去调优。
如果调优也无法满足时，才会去造轮子。而且造轮子，并不是一般的人和团队能承担的起的。
那些头一热就要造轮子的人，一般都是在开着汽车换轮胎的紧急时候，才会去想造轮子的。
几乎没有时间测试、调优、写文档，只追求能用就行。
但请注意，生娃不养娃，罪过甚于不生娃。
这个轮子造了，为了让轮子活下去，你要不断去完善功能，完善代码，甚至不断的回应社区。
这样，100个轮子，才可能有1个活下来。
否则，就是给后来维护的人，挖了一个巨大的焦油坑，不断造成无尽的浪费。
对了，还有类似的行为，大家可能都遇到过：
这个服务/功能，咱们用XXX语言再写一遍吧
最近XXX技术很火，咱们把YYY换了吧
这个项目，我们可是没有用XXX框架，而是自己从头实现的哦
遇到这种情况，先别上头，先考虑一下三个问题：
1、必要性：确实不造轮子不能解决问题吗
2、投产：公司、团队、个人能得到什么
3、轮子能活下去吗？你和团队能有多少热情，能投入多少资源