软件的性格

吴旻

泰岩网络工作室

 

         前两天，我为我负责的项目在集团内部做推广活动。这是一个为各业务线提供证券实时行情数据接入服务的项目，目前已经有两个业务线在使用了，总体效果还不错。

 

         当做完开场白后，我猛然意识到，这个项目已经明确地带上了我的性格。我说：

1、复杂性是软件的死敌；

2、我对简洁性有偏好；

3、我对复杂性有偏见。

 

对任何一项需求，我会直觉式的判断它是不是我的核心业务。如果是，那我就安排在业务架构中；如果不是，我更倾向于不做，或者，换个地方做。

模块的职能是我一直在努力划分的事情。可做可不做的非核心功能，我倾向于不做，当然这带来了简洁性，但有时候也会带来麻烦。举个例子说，我们发现下游的数据接收和处理能力有时会达不到设计要求，这样就会导致数据堵塞的情况。本质上，所有的连接都有是缓冲区的，只不过不足以解决下游的性能问题。想到的方案有两个，一是直接“踢”掉对方，当然这样比较暴力；另一个是为对方提供更大的缓冲区，这样比较人性，但大的缓冲区要是也满了又该如何处理，也是个问题。

最初我选择了简洁性，暴力就暴力吧。达不到处理速度，那还玩什么呀！相当一段时间，这个办法还是有效的，毕竟一般的开发人员还是比较在乎效率的。直到我遇到了一个“倔头”，你把它“踢”下去，它马上就顽强地连上来，一幅满不在乎的架势。

这就不光是技术问题了。读书的时候，我们先戏称这种情况为“人不要脸鬼也愁”，然后就做出改变，以适应这一特殊形态。我的队员建议在程序里为每一个下游设一个缓冲区，缓冲满了再将对方“踢”下去，至少这样可以大量减少“踢”人的动作。我知道这意味着什么，如果真的没有其它办法了，我会考虑这么做，但目前还没到山穷水尽的地步，所以我不赞成。

我接着选择了简洁性。提供这么强大的缓冲服务，不是这个模块必须完成的。换句话说，这个缓冲服务带来了与核心功能无关的复杂性功能，对这个模块的核心功能来说，未见任何收益，但从风险控制的角度讲，损失却太大了。

我建议单独完成一个数据缓冲服务的功能模块，以应对这一变化。首先，不增加原模块的复杂性；其次，两个模块升级时，都不需要对方也同时进行编译，或者同时互相测试。至于这个缓冲模块，可以考虑自己开发，也可以考虑选择第三方工具。

 

活动结束后，有同事问我能不能提供消息“订阅”功能，就是说，他不想接收的消息，我们就不要再发给他了。应该说，这个与项目最初的设计模式有关，做个比喻，我们最初的定位就像是一份“杂志”。你去报摊买份《读者》，然后给杂志社提建议说，能不能给你出一份只带你想要的栏目的《读者》，比如不要有广告，不要有笑话。换个角度再思考一下，如果你是杂志社的编辑，你该怎么回答？

从我的角度讲，我提不提供“订阅”服务，都与核心功能无关。杂志里面有你不想看的栏目，你选择不看就是了，这也不是什么不可接受的事情。很显然，他不太赞同我的观点，他补充说，某某项目是提供的。

我明白了他的表情：他是一个“技痴”。

要不要提供订阅，在项目一开始就提出来了，而且强烈要求提供订阅服务的人，就是要使用全部消息的项目的负责人。我当时说：如果你也要订阅，那我就把这些消息都取消，因为这些消息就是给你用的！

其实他的话我听懂了，他是在告诉我：我可以不用，但你不能没有。没有这项服务，就说明你技术水平不先进。

技术先进显然是个不错的卖点。我觉得这次我面临的是个用户体验的问题，或者说，是个对项目定位的理解问题。我可以考虑提供订阅服务，但我绝不会在核心功能里附加订阅功能，这不符合简洁性原则。

 

我在思考像“缓冲”和“订阅”这样的功能该向哪个方向发展，显然保不准什么时候又会出现一个看起来很重要的非核心功能，那时候我们又该怎么办。

是该有个数据总线服务的时候了。如果有了这个数据总线，我们的数据都可以推给数据总线，像“级冲”和“订阅”等服务，数据总线完全可以做得非常强大而又专业。

 

就像 “苹果”深深地带着乔布斯的烙印一样，我相信，软件也会拥有与它的团队相似的性格。