重复造轮子的必然性及其对策

必然性

结论：当团队的规模达到一定程度后，一定会出现重复造轮子。

有人认为，这是一个客观规律，并打了一个比喻：肉丸子达到一定体积之后，一定会散开，除非用了一个强有力的外力压着。公司规模达到一定程度，很难一直有一个强有力的外力。

还有两个因素：justifiability 和 affordability。

justifiability，可以理解为合理性。越偏底层，通用性越强，差异性越低，重复造一个越不合理。越偏上层，越容易被重复造。

affordability，可以理解为门槛。门槛越高，重复造一个越不合理。

另外，造轮子是程序员的一种成长过程，有其积极的一面。

用这个“肉丸子”、justifiability 和 affordability 模型的视角来看世界，很多“重复造轮子”的现象就解释的通了。比如，编程语言。Google要发明一个Golang，微软要发明一个.NET，Sun要发明一个Java，苹果要发明一个Swift。这些语言其实也有“重复造轮子”的嫌疑。但是，首先，对这些公司来说，发明一个语言很justifiable。因为编程语言背后是一个生态，一个开发者社区，一整套基础设施和工具配套，一个技术方向的把控力。所以，对于这些大公司来说，自己搞一个语言是justifiable的。甚至某天如果阿里巴巴或者蚂蚁自己搞一个新的programming language，我觉得也是justifable的。另外，对于这些大公司来说，搞一个新的编程语言，他们是afforable的。他们有钱，能支撑的起一个language背后的所有工具配套、社区和生态的投入、等等。

对策

1）各种轮子之间要能够兼容，有统一的API，要标准化。2）底层代码没有必要重复建设。

有10种测试框架，是一个现象，不是问题本身。这就好像说我的桌子很乱、上面堆了各种东西，这是一个现象。桌子乱本身不是问题，桌子乱导致我找不到东西，才是问题。其实，找不到东西也不是问题，找不到东西（比如，上个月的电费账单）导致我没有及时付电费，导致我家被电力局拉电了，这才是问题。我家被电力局拉电，背后的根因是桌子太乱，所以，要把桌子整理干净。其实，虽然我家被电力局拉电的背后根因是桌子太乱，但解决方案未必就是要把桌子整理干净。另一条路是：用几分钟时间在支付宝里面设置一下公共事业缴费，并且设置成自动缴费。

所以，我们首先要搞清楚有10种测试框架到底导致了什么问题。然后，看看解决这个问题的最好的解法是什么。有可能最好的解法并不是减少测试框架的数量。