软件工程的“政治”与“经济”

软件工程的“政治”与“经济”

吴旻

泰岩网络工作室

 

         有程序员来面试。

         我询问，他从前所在团队的期货交易系统，是怎么来处理大量用户同时交易这个并发问题的。一般说来，期货的品种都比较有限，几十个就打住了；同时在线交易的用户多数情况也会有限，在线用户数到千就很好了。所以，我没期待他能回答出个高并发出处来，他只要能说得出个大概的处理流程，有个基本的压力测试数据，我就认为可以过关。

         但他的回答还是把我吓住了。他说，他们会在一台服务器上，启动40个进程来处理并发问题，其中一个是主进程。

         我怕我听错了，连忙再问：是不是像启动40个EXE程序那样？

         这回我终于听懂了。他说，对，40个守护进程。

 

         我把他的话理解性的叙述一下，以便于描述。

         这个项目的原始框架是一个程序员从另一个公司带过来的，然后就延用至今。大家也逐渐感觉到性能上的问题，所以开发人员也增加到了10多个。项目的管理者是项目经理，而他则是后台模块的负责人，手下大约还有3~4个人。

         我问他，如果给定可以有足够的资源，重新设计一下这个交易系统，可以怎么做。很不幸，他差不多是根本没有想过，或者根本没想出一点点头绪来。

 

         缘于我们的文化传统，我相信，大多数的中国人对“政治”的敏感度远超过对“经济”的敏感度。虽然我们可能多数人都学过一些《政治经济学》，但我还更愿意相信那里面多数的内容是“政治学”，而不是“经济学”。

         多年开发经验告诉我，如何既“政治”又“经济”，是一个软件项目能否顺利的关键。过分“突出政治”，几乎就意味着陷入了“经济危机”；当然，我也不太相信没有“政治”的“经济”，因为有“经济”就一定会衍生出“政治”。

 

         提供相同服务的A、B、C三地机房，A用了22台服务器，B用了15台服务器，C用了7台服务器。除了保障级别稍有差别以后，我看不出为什么ABC之间要有这么大的差别。所以我猜测，最初这些服务器的部署仅仅是为了解决“政治”问题，比如能不能向用户提供稳定的服务等。

         随后这些部署可能就退化成了“形象工程”，“政治”远大于“经济”。没有明确的理由说明那一种部署是比较来说最“经济”的，也没有明确的数据证明为什么不能是别的方案。

 

         我们的一个合作伙伴喜欢说，最好和从前的功能保持一致，或者，最好不要动。

         我理解他的立场为，保持一致或者不动，意味着不会犯新的错误，如果原来有不足，那都是原来的问题，和现在没关系。所以结论必然是，我们是非常正确的。

我不太认同他这种以损失“经济”为代价，来换取“政治”上正确的做法。软件行业不是个养老的行业，以不变应万变，不是这个行业的指导方针。但我们也不是冒失鬼，我们一定会论证好了再实施。

 

业务水平一般，政治水平一定过硬。这是前辈们多少年的经验总结，放之四海去观察，皆很靠谱。

2005年的时候，表哥的两个同事到北京来玩，住在我的房间。我惊奇地发现，其中一个，只要是他用过的东西，一定会比原来变得更整洁；而另一个则恰恰相反，什么东西只要他用过了，一定会变得更糟更乱。随便聊聊天，前者更倾向于和我说怎么去做一件事情，如何做好事情，而后者想的则倾向于怎么样更省事，怎么样少做事情，但话里话外，都是他有很多理由，尽管在我看来明显是借口。

 

软件开发讲究“持续改进”，不过相当时候，我们在做的还是“持续不改进”或者“持续破坏”。我怀疑这还是与企业文化或者企业政治有关系，比如，有些企业明显就是奖励不出错，而且不管什么原因，只要出错，就一定受罚。照这个规则，当然是什么都不做最好了，而且还能因为零错误而受到表扬。

这对软件开发是个严重的考验。多年的软件开发经验告诉我，面对“政治借口”，必须有足够好的“政治理由”，才能达到持续改进这一目的。在企业当中，最好的“政治理由”一般是两个：一是提高效益；二是减少成本。当然最好的“政治借口”一般也是两个：一是这样最安全；二是这样最快捷、最省事，对眼下最有利。

 

软件项目管理一直在不断探索。为了“经济”，我们必须“政治”，所以有人总结出来了XP，敏捷，SCRUM。但我觉得，这些方式都试图尽可能直接达到“哲学”的高度，而没有充分讨论“政治”的深层次原因。当然，“政治”里面有相当的敏感性，导致我们不能充分并且公开地讨论，所以一切常用的手段都是尽可能的绕开，或者暗示。

用“经济分析”的方式支持“政治理由”，辅之以“哲学高度”的理想，去围剿“政治借口”，虽然速度有限，但假以时日，却一定会有功而返。