关于不要重复造轮子的二三事

看到此文,是否觉得体内洪荒之力爆发,饥渴难耐想吐槽
本文为转载文章,若有侵权或违规行为,请联系我,会及时处理相关内容。

支付宝微  信

“不要重复造轮子 Stop Trying to Reinvent the Wheel”, 可能是每个程序员入行被告知的第一条准则。我自己也会对新人反复灌输这个概念,写程序其实是一个最能“偷懒”的工作:你现在费力实现的每一个功能,可能早已经有极好的解决方法贡献在开源社区,如果可以直接用现成的,那节省下来的时间是不是可以用来偷懒呢?极端的说法,哪怕是那位把所有开发外包给沈阳一家公司的哥们,如果撇开道德以及商业安全,只要能贡献优质的代码和健壮的功能,对于一个项目来说,这样做其实没任何问题。

找轮子存在的问题

虽然不要重复造轮子的准则被反复提到,但是以我个人的经验,这个准则实践起来其实很有难度,因为:

  1. “不要重复造轮子”意味着首先需要找到一个可以用的轮子,而且我们一般希望是能最好的轮子才可以一劳永逸。这就对个人的信息检索能力有非常高的要求。
  2. 找到了一个轮子,但这个轮子好不好用,需要时间来论证。能一眼判断一个项目的质量以及易用性,这其实需要大量项目经验的积累。
  3. 好轮子不是你想用,想用就能用的。要想将一个开源项目整合到自己的项目中,需要对这个项目有比较深的了解。开源项目的文档质量参差不齐,当使用轮子时,只看文档往往是不够的,还需要阅读源代码甚至深度修改定制。更不要说大部分开源项目根本没有中文文档。

所以现实情况往往是:新人不懂得检索方法,找不到轮子;好不容易找到一个轮子,学了半天不会用;好不容易能运行,很多地方与需求不一致,但是又不会改;一来二去,最后还是变成自己写轮子,同时还得出一个结论:别人的轮子都不好用,还是要坚持自己造轮子。

这种情况的最佳体现,就是曾经有一段时间遍地开花的PHP框架。每一个写框架的人都认为自己写的框架才是最好的轮子,甚至是很多PHP新人,对几个成熟框架浅尝辄止后,也纷纷投身写框架的行列。成品大部分看过去却是大同小异,只是语法层面更符合作者本人的习惯,而缺乏大量的测试以及文档社区,最终的结果就是一个