平台化不是造轮子

昨天我发了一篇日记《最近的一些想法》，提到算法工作应该平台化，很荣幸引发了热烈讨论，我的被关注数也一下涨了不少，上次发生这样的盛况还是我把昵称改成现在这个骚情样的时候。
很多反对的意见认为我是主张“造轮子”，这是一种误解，恰恰相反，我的观点是：如无必要，勿造轮子。平台化本身就是为了避免反复造质量参差不齐的轮子，那样既低效，又error-prone。还有观点认为平台化是大公司的专利，这里是误解了我所提“平台化”的含义，我在原文评论中回复，这里的平台是指工具、流程和服务。我认为这是现代工程的精华，在这一点上来讲，我不同意它只有大公司才值得拥有。
不同规模的团队有不同的做法，对于占比多数的中小团队，开源社区的生态圈是很好的选择，因为研发资源有限，更需要专注于业务，我认为这正是平台体现重要价值的时刻。可以让你省去很多基础工作，出了问题也有大腿可抱。这当然是一种取舍，很少有方案会完美适配你的需求，但在这样的基础上进行二次开发，不失为一种上好的选择。当有一天你发现，你的业务再怎么适配，也融入不了这个系统了，那可能要恭喜你，说明你的业务有了长足的发展。那时，相信你的团队也会更容易争取到更多的资源，来修缮或者重构这个系统让它为你所用。如果你足够幸运，最后会是一副什么场景呢？我想可以从Google、BAT身上找到答案。
以我现在的工作为例，我所在的团队在未来相当长一段时间里，都将只有我一个算法人员，而我个人水平又实在不敢恭维，自然不敢托大，而算法工作本身涉及到的问题又很多，事无巨细地解决恐怕是不可能完成的任务。在同事的帮助下，我目前走的方向是，涉及模型的需求，全部依赖mahout做二次开发（公司有现成的hadoop集群）；content-based的任务，全部在solr的框架下用IR的方式来解决；而统计分析的工作，都围绕hive展开。目前还没有（准）实时需求，如果未来需要，那自然而然，第一选择是hadoop和它的streaming小伙伴。这就是我给出的“解决方案”。我想，即便有一天我要离开，这套东西也可以以最小的代价被接管。
回到豆瓣的情况，我的体验是，既没有重复利用好开源社区生态圈带来的便利，又没能孕育出适合自身需求的平台。Dpark和libdoubanm其实解决的都是计算的问题，mfs解决了分布式存储的问题，但在这之上，应用层面的配套是极度缺失的，这在我工作期间为我带来了很多困扰，也阻碍了团队内部的交流和技术积累。
至于“老板就是要快糙猛”之类的论调，我是很不以为然的，效率的浪费才是巨大的成本。当然这跟这里讨论的其实不是一个问题。
“平台化”只是上述观点的笼统称谓，共军说“现代化”，国军说“美械化”，或者叫“专业化”，都无所谓。
欢迎来到2014。