让我们重新思考造轮子的问题

去年国庆前的两周，开发者社区都被xcode ghost 刷屏了，我就不讲xcodeghost的产生的原因和危害了，因为已经很多了。做为号称资深的iOS工程师,我想讲的是比xcode ghost更严重的问题是，现在软件行业各种轮子大行其道，而缺乏相应的安全评估机制。

大概4年前，我们曾经一起呼吁过不要重复造轮子，在Github等平台的流行下，这种思潮大行其道，几乎没有人觉得有什么问题,时至今日,甚至有无轮子不代码的趋势了。

真的没有问题吗？下面我们列举一些问题

一行代码吓出一身汗

在github上见过以上代码的我从此萌哒哒不起来了，世界太邪恶。

再有一段除了邪恶更有不可告人目的的代码。

滥用轮子造破车

有的开发人员为了省事，经常为了一个小小的功能引入一个全功能大轮子，或者不同的开发人员因为喜好的关系引入功能类似的轮子，造成编译出的APP包很大，而且更容易出现不容易理解的bug。

行业技术水平亟待提高

小公司，个人开发者如此也罢，很多大公司水平也不乐观。

首先是做出来的SDK尺寸奇大，搞不清楚它到底要干嘛，架构也不规范，经常在SDK里面再引用其它的SDK，造成命名冲突，而且基本都要求使用LOAD_ALL 编译开关，那就像上面那个邪恶函数一样，我怎么信任你不做恶或不被利用来做恶呢。

（那SDK该怎么做呢？这得写一大篇文章来说了，不过至少得拎出依赖包，catergory开源，不要load_all,小巧）

轮子市场管理不善

老外总是too simple，包括npm,gradle,pods等开源社区几乎没有啥安全防范机制，设置一个邮件地址就可以注册包名了，而且代码也不需要托管到github，甚至很多都不开源，包名也随便你写，只要不冲突都可以，无数的大轮子或者被仿冒的假轮子，出几个做恶的估计腥风血雨远超xcode ghost。

重新思考轮子的必要性

我们先看看一般移动前端需要的主要轮子：

网络工具类：

ASIHttp,AFNetworking,GCDSocket,等

流行UI：

下拉刷新，复杂布局等

序列化，本地化和可用性设计：

SBJSON，WebImage等

效率工具：

util等

这些其实现在系统API已经足够强大，我确实看不到必须使用轮子的情况了。

奇异设计导致的必须使用轮子的情况，我觉得开发人员需要站出来和设计complain一下，因为这不是你实现能力的问题，而是特殊的设计往往伤害了用户最终的体验。

一种想法

建立一套安全评估机制，分等级管理，比如，个人APP不限制使用各种轮子，商业APP只能使用正式开发团队开发的轮子，金融投资，支付APP则不能使用任何轮子。

还有一种想法，前端组件化，由中间层调用后端API取数据，调用前端组件渲染数据。我想参照web component的概念把他命名为app component，核心理念都差不多，就是everything is a element，independent element，而且这个element是可以被json描述的，包括它的状态，行为和数据都是json描述的。（com组件其实也是这个概念，但是时代相距太遥远，太不faction了，而且巨型com组件问题太多，这些问题引发了比设计扁平化早10年的软件扁平化浪潮，这个浪潮又促使了自由软件和开源社区的流行。我想设计思想也是各领风骚数十年吧，如果开源社区滥用导致了很大的安全隐患，那么另外一种思想必然在总结现有各种思想精华和弊端的基础上发展出一种类似“复古”的东西出来，但是这东西一定不可能是com）这个app component正是我上篇文章所写的《Native和H5的撕逼大战及 “一个被子掉在地上的梦想”》，你猜对了，我绕了一大圈又开始推我正在设计的有点“不切实际”的前端框架。你对这个框架开始有点期待，或者是有点好奇了吗？那好，本文结束了，结束了，结束了。

本文编译：：刘国平（点融黑帮），资深软件开发工程师，跨平台开发框架hero作者，是最早的一批移动开发者， 同时对android，H5，NodeJS等技术比较关注。