如何判断一个技术(中间件/库/工具)的靠谱程度

前段时间周末闲来无事，写了几段小程序。在第三方库上兜了个圈子(悲催地挨个折腾了 pybitcointools, bitcore, libbitcoin, cbitcoin, 挣扎了半天最后又回到pybitcointools)，回想起以前看过的 《Game Engine Gems I》的第一篇就是关于这个主题的（“评估和集成中间件的时候应该考虑什么”，”What to Look for When Evaluating Middleware for Integration”），赶紧拿起来翻了翻，顺便总结一下自己的教训，形成文字长点记性。

主观因素

首先说明的是，不管承不承认，个人品味对选择的影响非常大。即使是同一个程序员，随着视野的开阔和水平的提高，也会不断地推翻自己以前的品味。例子就不举了，这种非常主观的因素不宜多说，知道有这个重要因素在影响着判断，并随时去提醒自己，在技术和工具的选择上不要有过分的成见，傲慢与偏见，俺认为就可以了。

其次，比普通程序员更爱折腾的文艺程序员，往往还有一个困扰——究竟是该用现成的库，还是自己造轮子呢。如果是自己的 pet project，当然无需多言，怎么折腾都行，甚至换个姿势多来几次都无所谓。但是对于稍微大一点的需要多人协作或控制进度的项目来讲，这个问题就难下定论了。项目类型，成员能力分布，成员熟悉程度，对代码的掌控力，对排期的影响，都是不那么直观的软性待考察因素。

第三点，很多时候也是最靠谱的一点——朋友的推荐。很多时候我们用一个东西，不是说这个东西有多好，而是那些我们觉得非常靠谱的人(或组织)在用这个东西。这种“安全感”说白了就是一种对他人的经验和判断力的信赖。对创业团队这一点尤其重要，因为跟大公司里按部就班的正规军相比，他们的生存环境要残酷得多，试错机会要少得多。如果不能很好地借力，什么都自己去尝试，风险就会难以控制。

客观因素

说完了这些模糊的，难以度量的主观因素，终于可以说些明确的客观指标了，这也是那篇文章的重点。这里我择要简单说一下，括号里是我加的备注，见谅。

集成复杂度。好的中间件的特点是高度模块化（就是说不随便暴露无关的接口），最小侵入（普通的使用不需要你使用继承之类的强耦合关系），容易集成到完全不同类型的代码库（比如尽可能地使用可移植代码而不是直接调用平台API），对外部环境有极少的假定，极力与其他系统的实现细节解耦。设计良好的第三方库应尽可能地具有有效的默认行为，需要最小量的配置就可以工作起来。集成的代码接触面积应该最小化（这个接触面积越大越深入，评估周期和维护工作量就会成倍增长）。如果一个中等水平的程序员做了两天还没让集成能初步跑起来，集成复杂度就值得怀疑了。（需要两天以上时间去集成的库，通常需要n个两天去维护）

内存管理。关心两点：a. 内存占用是否有不合理的开销 b. 内存所有权和分配释放的职责是否清楚。理论上，库的作者应该是对库的内存使用情况最了解的人，他应该定制明确的分配和管理策略。当超出预算时，应该能明确地通知使用者，从而有机会去处理这类事件，而不是任由自己想分多少就分配多少。（更好的设计是把内存使用设计为可伸缩的，这样调用方有机会在运行时根据需要动态去指定内存用量）

对大量 I/O 访问的处理。硬盘/光盘/网络都是有延迟的，所以访问的策略非常重要。一个第三方库永远不应该直接调用系统API去访问外部资源（如声音文件等），调用方应该有机会去捕获文件和数据的请求，提供定制的方案，从定制的数据源（如已经缓存到内存中的打包数据）读取。最灵活的方式是库完全不提供任何文件或流的读取，只访问给定的内存块，把资源如何获取完全交给调用方开发者处理。最糟糕的中间件，总是假定 POSIX 文件系统在目标平台是有效的，直接依赖C语言运行时的 FILE 和 fopen() 之类的东东。

日志系统。设计优良的库能够一致地处理运行时的消息，警告和错误，也很容易集成到你已有的日志系统。更好的设计给你一个选项能从高到低（从完全静默到最少量的关键错误到完全的调试信息）逐级开启各类信息。当开启静默的选项时，编译期就能把这些额外的调试输出字符串干掉，以避免额外的开销。当开启 ‘Noisy verbosity’之类的选项时，系统的各项指标都不断地被输出，通过某段给定的输出，基本能够了解系统当时运行的上下文细节，一些不当的使用也能被及时捕获。

错误处理，稳定性，性能开销，工具。通常评估一个技术，这些都是必须考察的指标，俺就不一一赘述了。

客户支持，维护工作量，可移植性等等，这些属于延伸的需求，都很直观，也就略去不提。

最后说一下这里面一条俺认为比较重要的，也是当年带队的MMO项目里，被我列为头条编程规范的原则：绝对，绝对，绝对不要使用没有100%提供源码的第三方技术。这是一条红线，不管这个技术有多强大，都绝对木有例外。程序猿们或多或少都有感触，在编程的世界里，CPU时序的不确定，存储IO的阻塞，其他进程对CPU/内存资源占用造成的扰动，后台进程如杀毒软件偶尔的锁定文件访问，公网路由的拥塞，都为运行着的程序施加了太多不可预知，不可控制的因素。而在这些不可控制的因素里面，允许在自己进程的地址空间内运行一些无法得知其本来面目的代码，是其中最危险也是最容易失控的那一类。反面例子太多，俺就不举了，也免得触物伤怀，影响心境。

基本上主观和客观待考察因素就是这些了，能坚持看到这里，说明您对这个话题确实是感兴趣。为了对得起您的这份耐心，俺特地准备了一点不干不湿的杂货，还请笑纳。

“望，闻，问，切”

在平常的开发活动中，俺总结（山寨）出了“望，闻，问，切”的四字真言，可以用来在一个相对较短的时间里，判断一个技术的适用性。注意，俺说的这些方法，用来鉴别好坏倒还在其次，重点是辨别其是否适用于当下的需求。

“望”

跟传统医学里的驻足远观对方的体态、神态、步态不同，“望”咱们这里取声望口碑之意，也就是间接的评价。上面提过，这里不再细说。总之一句话可以作为底线：“大家都说好的，不一定真的好；大家都说不好的，那基本上好不了。”前半句不解释，后半句是说如果别人都掉到过坑里，那就不要再主动往下跳了。这方面惨痛事例很多，俺也就不举了。

通常这个步骤是不需要花费时间的，一般来源于平日的认识和积累。

“闻”

“闻”可以看作是对其的“第一印象”。正如合格的侦探一眼扫过目标人物就能获取大量的相关信息，训练有素的程序员，从首次了解到某个库的名字和简介，和网站主页面上大致一过，已经可以有一个清晰明确的第一印象了。

俺对一个技术的第一印象通常包括(但不限于):

(这个技术) 所试图解决的问题是否清晰，明确。

通过“望”和“闻”一般就可以决定，是不是需要继续深入去 “问” 和 “切” 了。

“问”

现在开发是否活跃？上一次更新是在什么时候？

“切”

拿到代码，开始庖丁解牛式地查看，可以称之为“切”。

这个部分其实完全可以独立出一篇文章了——”How to effectively read code”，也有一些书是讲这个的，比如 “Code Reading – The Open Source Perspective”之类的，感兴趣的同学可以去翻翻。

题目太大，俺就不展开细说了，只说一个实践之中俺摸索出来的窍门吧：找到这个库最重要的暴露给外部的接口文件（通常是以那个库命名的头文件，如 lua.h，zlib.h 等等），就像读文档一样从头到尾（注意，这个顺序很重要）通读一下。看看自己是否能在没什么阻滞的情况下，基本了解这个库的大部分行为。

优秀的接口设计，读起来行云流水，错落有致，当缓处则缓，当急处则急，信息密度均匀，命名平易近人，符合人的直觉和思维习惯，让人读来不费脑力，心情愉悦；而不良的接口设计，读来往往乱作一团，东拉西扯，前后矛盾，概念冲突，甚至于夹三夹四，啰嗦重复，没头没脑，不知所云，或者有悖常识，命名奇葩，又或卖弄学问，哗众取宠，治经弄典，艰深晦涩，搬弄奇技淫巧，极尽冷僻深奥，令人蹙眉扼腕，基本读不下去，自不必提。

对中小规模的技术而言，上面的“望，闻，问，切”已经足以应付了。而对大型代码库/框架/引擎而言，又有一套不大一样的评估标准，另有曲径可探，咱们择日另行讨论，此处暂且按下不表。

写到这里，本文的内容已经基本完整，可以收尾了。不过结束之前，俺来透露一个小秘密吧（思维敏捷的开发者，可能已经想到了）：此文明面上为探讨“如何甄鉴一个技术”，实则另有一层涵义——对于程序库的开发者，这其实也是一份可供参考的对照——如果能对上面的视角，方法和手段了然于心，就可以设计出更好，更易用，更为使用者考虑的系统。

=====================================================

本微信静态数据存储由七牛云存储提供！七牛专为移动时代开发者提供数据安全托管、双向传输加速以及图片、音视频等数据处理的一站式服务。