软件领域的Reinvent

苹果经常喜欢用“Reinvent”这个词，用在硬件领域确实高大上。但在软件领域Reinvent大多时候是个贬义词，软件领域上下游结合及 相互依赖非常紧密，没有哪个团队甚至公司能封闭的完成所有事情。因此重新发明这件事情在软件领域并不吃香，一个新的体系在小的团队通常会自生自灭（尽管途 中可以获得一些荣誉），剩下那些硬撑的项目则会让参与人员痛苦不堪。

比如各厂定制的各种百花齐放的框架，运作几年之后，核心系统越来越臃肿，随着人员的更替能深入了解内部的人也越来越少，改进的动作非常迟钝。但 大量的上下游业务服务又需要依赖这些系统，新来的人需要较高的成本熟悉整套系统。问题丛生，但是离开又需要付出极大代价，于是就成了一个鸡肋。如果使用方 牵涉到多个部门，更不会有人站起来说将这些定制系统废弃或迁移。

但这个现象在计算机语言领域则是一个例外。一门新的语言，不喜欢的人可以不用，而且大部分开发团队是随大流，不会选用小众语言，所以新语言领域 已经在搭建的哪些不成熟的系统也不会给业界带来麻烦及痛苦。少量情况下，极客会心爱的小众语言搭建的一些系统，但根据观察，这些系统通常会随着极客的离职 马上会被用主流语言重写替换。因此在新语言领域，可以用更轻松的心态去重新发明各种组件。

一门语言出来之后，复用另外一种语言的模块与组件不是最佳方案，理想情况会选择构建自己的函数库，框架，开发工具，测试工具，代码工具，性能调优工具等。在新的语言出来的早期，这些领域一片空白，踏入这片领域的人会有新大陆淘金的感觉，随便写点东西，很快可以找到市场。

在一个新的语言重写一些别的语言已经完成的项目，尽管这不是什么伟大的发明创造，但参与的人往往更快的取得了成绩并且赢得了尊敬（相对于在“主 流”语言拼搏那些人）。我也曾经思考过这个现象。技术人的价值观虽然很多元化，但是有两点却几乎是共通的，一是工程师动手创造带来的成就感，二是感受创造 的东西给所在环境以及业界带来使用价值的成就感，不管这些创造是原创的还是山寨。因此在很多领域如搜索、广告以及更基础层面OS、Database、 Language总是有乐此不疲工程师重新去建设，因此在语言层面的重新建设就变得容易理解了。

更深层次的来看，在语言层面的基础上，重新去构建一个生态圈，从社区的角度，不只是重新克隆一个新的版本，工程师会考虑以往的经验及教训，重新 设计重要的单元，以带来性能上的提升及使用方式上的改进。比如这几天写一个Go语言的小程序，看到Go的社区在配置文件方面的思考及重新选择。配置管理在 Java领域大多是XML一统天下，尽管其可维护性较差，但由于历史原因，工程师很难去领取炉灶。

当然在新OS领域重新创造的机会就更多，但是这种情况较少发生，一个新的OS生命周期会延续10年或更久。一些大公司的开发平台生态圈也有类似的这样的机会，不过大部分情况下格局会小很多，也会存在更大的不确定性。