选择的背后

前段时间，在构建一个基于开源项目的大文件分发解决方案，跟同事的交流过程中，几次听到这么一个观点。

这个软件已经好久不更新了，会不会存在我们解决不了的问题，我们还是别用这个了，选一个开发维护更活跃的替代品吧。

当时打心底对其不屑一顾，嗤之以鼻。但是静心想想，自己也说过类似的言论。

18年1月初，当时需要汇总各个审批系统审批流程状态。其中一个系统是Kafka + HTTP 实现 摘要 + 详情的模式来给其他开发业务方提供服务。当时对 Kafka一码黑，感觉甚是棘手。

对 Kafka 这个工具本身需要先有个感觉，了解其使用的心理模型自不必说。涉及到具体选用那个实现很是被同事“刁难”了一番。

当时心理已经打定主意要选用微博广告中心开源的实现客户端。当时用以回应的理由大概如下

纯PHP实现无外部扩展依赖，源码易读，维护人员开发比较活跃。了解到其他业务方使用c实现的客户端也发现了有卡死的现象，感觉稳定性也不怎么地。

先搁置主观认定、先入为主这块不提，所说理由虽然看上去还说的通，但一直对这个理由感觉很是心虚，总感觉不对这并不是一个正常的逻辑。感觉有点答非所问，论述的逻辑感觉不甚清楚。

最近在关于saltstacks ocs的两次项目评审会上部门领导说的一段论述启发了我对这两个问题的一个新的看法。大意如下:

我们选定一个工具不是看其他大公司是不是用过，别人的环境、问题跟我们一模一样吗？我们面临的环境、问题是什么？工具本身的概念有哪些，这个工具是怎么对这个问题领域是怎么建模型的？然后才能对比两个工具那个好那个坏。

当时给我的启发是，首先要对要解决的问题自己要能分析出面临的问题，针对这些问题做了那些基础的定义，而后建立出来怎样的一个认知模型，其次对比两个工具不能单纯的从工具能干什么角度出发，而是应该从工具本身所代表的理念，建模思维，设计思路出发去比对两个思想的好坏。不能单纯的止于表面。

认识到这两点后我感觉上面的两个问题已是不言自明了。但我这页纸的空白处还是够用的，用此法分析上面的两个问题并简要的记录下自己看法。

首先我们对我们解决的问题都很清楚，主要问题是出在了没有对问题领域建立共同认可的模型，进而论述如何去选择一个工具。

影响一个工具选择的因素有很多，跟当时内心的诉求有很大关系，比如上面两个例子当时从稳定性，社区活跃性，工具项目本身的可参与度，面向的使用用户来分析。从逻辑上就能比较合理地解释清楚，或许也就没有那么多的不愉快沟通交流。

首先说下稳定性与社区活跃度，一个同事说过很有意思的一段话是，当天提需求，当天开发，当天上线，当天回滚，当天修bug，当然这是针对不怎么靠谱的人来说的。这里只是想说活跃跟稳定或许一点因果关系都没有。如果面向用户如果是全然不懂开发的，那么社区活跃度就会很容易成为最重要的选择项，活跃的社区更容易获取到帮助。

其次稳定性跟可参与程度，如果无法参与到项目的开发修改中，或者所需成本过高，最终可能导致需严重依赖他人，犹如被人卡住了脖子。这是很需要慎重选择的方案。