工具：开发者使用，企业埋单

我喜欢写一些小工具来简化我的工作，通常是一些小组件。利用这些小工具我可以提高自己代码的可读性，同时维持我的 DRY (Don't Repeat Yourself) 洁癖。工具对我来说很重要，因为时间对我来说很宝贵。能够用工具自动化完成的事情绝对不手工反复操作，能够用工具避免人为错误的地方一定让工具来确保质量。使用工具节省下来的时间用于玩游戏的话，绝对是值得的！

过去我主要做工具给自己用，或者是给自己所在的团队使用，所以觉得自己就是用户，自己设计产品给自己用肯定是没问题的。然而做工具给更多人用呢？看起来就不那么容易了。之前在百度经历过 Tangram 的需求分析与设计阶段，每个产品线都派出了前端工程师代表参与需求评审，通过多轮的辩论来决定哪些需求是要覆盖到的，哪些需求是可以忽略的。最后做出来的产品？只获得了一部分产品线的认可。推广也得不到公司层面的支持。

工具的需求难道不是来自使用者吗？使用者就是坐在自己隔壁并且做在同一领域开发的团队，这样都可能出现需求理解偏差吗？这个问题我一直没有想明白。

后来我到了 Yahoo，在对 YUI 表示恶心一端时间后，我开始理解到恶心背后的原因。无论是 Yahoo YUI 还是 Google Closure，目的都是一样的——通过工程性来保证，就算工程师素质很低，产出的代码质量很差，项目也能交付。我当时只是觉得大公司为了交付而造出一些压制工程师创意的工具是很恶心的事情，而没有考虑到这是否跟我要思考的问题相关。

到了豌豆实验室后，我开始着手构建一些前端工具，这一次我终于明白到需求源自于哪里了。工具确实是给开发者使用的，而需求来源于企业。企业在不同时期可能有不同的需求。企业刚刚成立时，肯定希望尽快把产品概念做出来，所以要求工具能够快速实现产品原型。等到产品成功发布后，企业又希望能够拓宽产品的市场，于是要求工具能保证产品复杂度增加的同时维护成本可控。随后企业会同时开发多个产品，这时候就会要求工具能够帮助降低产品共有的成本。

在文化相对开放的企业，工具的选择看起来是由开发者决定的。开发者爱用什么工具就用什么工具，企业不干预。实际上，企业不是因为文化相对开放而不干预，而是缺乏干预的动机。如果提供足够的动机，例如使用某种工具能够使得利润翻倍，任何企业都会愿意为之而干预。不干预的企业，往往只是没看清楚工具能给它的成本造成什么影响而已。

此外，在企业决定干预开发者使用什么工具时，企业肯定不会在乎工具使用起来爽不爽。开发者不爽是一种成本，但把这项成本计算在内后，如果特定的工具还是能降低企业成本，企业还是会选择这种工具。至于开发者不爽的成本，是将来可以通过优化工具来避免的。

回顾之前百度 Tangram 推广不利的问题，答案就显而易见了。为什么 Tangram 缺乏百度自顶而下的支持？为什么作为同类产品的 YUI 却能得到 Jerry Yang 的支持并在整个 Yahoo 得到推广？因为 Tangram 覆盖了开发者的需求，但没有很好地考虑到百度作为企业的需求，尤其是没有考虑到这种需求在百度成长中的变化。

Tangram 在设计初期，考虑的是如网页搜索这样的产品线的需求，要求 JavaScript 尽可能优化，少占用带宽。于是 Tangram 设计为支持函数级别的依赖项。然而等 Tangram 做出来时，贴吧则决定直接使用 jQuery。这是因为网页搜索和贴吧的成长进入了两个不同的阶段，网页搜索要求在细节上继续优化，而贴吧要求通过快速迭代尝试不同的产品概念。需求差异如此之大，一个工具又怎么可能都覆盖到？既然 Tangram 没办法在多个产品线证明它能有效降低成本，百度又如何下决心为它埋单？

这同时解释了一个问题：为什么企业内部工具应该由架构师来主导。（YUI 及后来的 Cocktails 都是由架构师主导的。）因为架构师的职位能让他更好地解企业的需求，同时他的位置也更靠近老板。此外，架构师在一家企业内的资历也会对此有帮助。跟随这家企业成长的经历能让他更好地看到这家企业将来的需求。因此，企业内部工具不是随随便便挑一个技术足够好的人来主导就行的，他的职位会影响到他是否胜任此项工作。

对此我可以补充一点信息。我见过 Tangram 推广所用的幻灯片，里面堆满了对开发者有用的信息——Tangram 在 gzip 前后跟其他库的体积比较、能够覆盖到多少功能点、在百度产品线的代码覆盖率能够达到多少。（代码覆盖率还曾经是 Tangram 的执行目标。）然而里面缺乏对老板有用的信息——使用 Tangram 能够省多少钱。由于位置的缘故，做 Tangram 的团队确实缺乏获取相关信息的途径，也更没办法获取到老板对不同产品线的长远规划。

再来看看 Yahoo 架构师 Bruno 是怎么介绍 Cocktails 项目的。幻灯片里面没有一点开发者关心的信息，前半部分说的都是 Yahoo 接下来的战略——必须同时抢占桌面、平板、移动 3 个平台，后半部分讲的是如果为这 3 个平台独立开发应有成本有多高，而使用 Cocktails 的话能够缩减多少成本。我听 Bruno 讲完后，就立即明白到这其实是用来向老板要钱的幻灯片，只是顺带再讲一遍以便让开发者知道公司战略而已。

老板实际上不明白也不在乎开发者对工具的需求是什么，幻灯片上他能看懂的就是那一堆 $ 后面跟着的数字。如果你给不出这堆数字，老板对工具的态度就会是既不支持也不反对。因此，找一个足够了解公司现有数字同时知道如何利用技术去改变这些数字的人，对内部工具项目来说尤其重要。这个人往往就是个架构师。