产品研发记录04：关于开源组件选择与技术方案选择的总结

在<a href="http://muchstudy.com/2017/01/02/%E4%BA%A7%E5%93%81%E7%A0%94%E5%8F%91%E8%AE%B0%E5%BD%9501%EF%BC%9A%E4%B8%BA%E4%BB%80%E4%B9%88%E9%9C%80%E8%A6%81%E5%9F%BA%E7%A1%80%E5%BC%80%E5%8F%91%E6%A1%86%E6%9E%B6%E4%BA%A7%E5%93%81/">基础开发框架产品</a>构建当中，由于人力成本等其它原因，无法做到所有的代码都自己实现。所以，在技术部分就包含开源组件选择与选择合适的技术方案自己实现两部分。

一、开源组件选择

对于开源组件的选择应当考虑如下几个方面：

• 是否已经经过了时间的考验。例如Jquery之类组件。
• 是否有完善的生态环境。如果一款开源组件长时间没人管，没人用，圈子不活跃，建议不要选择。
• 如果是小团队，还需要考虑团队人员的技术栈。大团队，需考虑新组件的推广成本。例如React、Angular、Vue。
• 文档是否完善。

二、技术方案选择

• 首先筛选出做一件事都有哪些技术方案能实现。
• 通过Demo样例来判断每种方案的实现难易程度，判断每条路走下去分别会有哪些坑。
• 市面上是否已有成熟的、已用于真实环境的技术解决方案。
• 预估业务增长的速度，是否能支撑起增长变化后的需求。
• 性能考量，实现复杂度考量。

三、其它

• 不管什么组件，什么技术方案，首要需考虑的是是否能够很好的契合目前需要解决的问题。
• 如果所选的会使用在核心部分，那么需考虑在3-5年后是否会过时。
• 做好对比分析，最好仔细列出优缺点，折衷考虑。
• 拿不定主意，不好评估的可先行小范围试用。如果不行，可快速切换；如果不错，再推广开。
• 新组件，新技术未经过充分验证不可推进太快，就跟车速太快不好调头一个道理。

总的来说，随着时间的推移与业务的变更，技术也应当随之改变。不管是开源组件的选择还是技术方案的选择，只能保证在那么一段时间内是最优的选择。技术人员必须时刻保持敏锐的嗅觉，跟上技术的步伐。如果一直停止不前，不管是对于一款产品也好，对于产品的研发人员也好，迎面而来的只有被淘汰的命运。

在本文的最后，还想多说两句。所有的东西都不可能是一成不变的。产品没有随着新技术的提升与业务的变更而跟着做相应的调整，几年过后，就会变得越来越难用；技术人员安于呆在温水中，个人能力没有随着工作年限的增加而增加，几年之后会觉得越来越尴尬；

在知乎上有这么一个问题："<a href="https://www.zhihu.com/question/41167695">有哪些一开始觉得离自己很遥远的事，真的发生在自己身上时措手不及？</a>"。其中有一个简短而有力的答案，这个答案是：“平凡”。

上一篇：<a href="http://muchstudy.com/2017/01/07/%E4%BA%A7%E5%93%81%E7%A0%94%E5%8F%91%E8%AE%B0%E5%BD%9503%EF%BC%9A%E5%85%B3%E4%BA%8E%E6%8A%80%E6%9C%AF%E5%80%BA%E5%8A%A1%E7%9A%84%E6%80%9D%E8%80%83/">产品研发记录03：关于技术债务的思考</a>