软件开发的 “三重门”(转，好文)

注：本文转载自 酷壳，文中作者根据自己十多年的软件开发经历，总结出软件开发的三个阶段——功能、性能和智能（作者称之为软件开发“三重门”）。

以下为原文：

 

这篇文章必然是通过我的个人经历来写的。所以，我先说说个人经历吧。我的经历基本分成三个阶段。

第一阶段：我刚毕业时在家乡的某银行工作，做些银行的业务系统，还搞些网络、电子邮件系统、OA什么的，因为大四的时候在老师的公司里实习，银行里的人际关系太复杂，而且技术都包给了产商，所以在银行的每一天都觉得不能适应里面的工作环境。两年后离职，单位分的房也不要了，直接去了上海，在上海呆了两年，本来想做互联网的，但是泡沫来了，最终去了一家做系统集成的国企公司还是继续做银行业务。这四年来，主要解决的都是一些业务上的问题，银行里的会计业务、OA业务、国际业务、中间对公业务都非常地复杂，而且因为当时的软件开发相当的不规模，所以基本上是在一种比较混乱的状态下度过的，而银行方面又很强势，所以，这段时间主要是做业务。C+/Java、Windows编程、Unix编程、网络编程主要是这段时间学的，看了太多的书（我大学课程里没有C++和Java，也没有Windows/Unix和网络编程，所以，只能拼命地看书和自学）。

第二阶段：然后，我来到了北京，在一家做分布式计算系统的公司，整天和一个高性能、高可用性的企业级的集群式的软件产品打交道（这家公司去年被IBM收购了），在这家公司把Windows/Unix和网络编程有了更深入的了解，对我长进比较大的是明白了怎么做一个性能高、可用性高的集群式的系统，天天和底层打交道，干了4年多。然后去了一家金融信息公司，这家金融公司主要做全球的金融信息数据处理，而我主要还是做核心数据发布系统的性能调优的项目，金融数据的实时性要求的高，数据量非常地大，高可用性要求得高，得想尽一切办法省网络带宽，增加系统性能，还要保持高可用性、不宕机、不丢包。又干了4年多，去的时候从国外接过来两个系统，其性能单机每秒可处理 120K message，我走的时候，我和团队把其优化到了每秒1.4M messages 的吞吐，另一个系统，从接手时的100k message/s优化到了500k message/s。这八年多的时候，全是在和这些高计算高性能的项目打交量，几乎没有什么业务，都是纯技术，积累到了很多和性能有关的高并发、高计算系统架构级的知识。

第三阶段：两年前来到了现在的做电子商务的互联网公司Amazon，还是在做一个数据处理量很大的业务系统，因为要干的是要把电子商务全球化的东西。但是，因为电子商务的特殊性，必须要去兼顾业务的特点，而且在Amazon，耳濡目染了很多有趣的业务难题，比如，库存计划、配送优化，等等。虽然很多东西还不明白，但发现，用技术来解决业务难题真是太有意思了。

我的这三个阶段，第一个阶段花了4年，第二个阶段花了8年，第三阶段刚刚开始2年不到，有时候我也去别的公司讲课，所以，我很有幸经历了中国软件开发的进化过程。我的经历就是中国软件行业进程的一个缩影，而我把这三个阶段称为——软件开发的三重门。它们分别是：

• 业务功能
• 业务性能
• 业务智能

之所以加上“业务”二字，是因为我以为计算机是一个工具，其用来解决实际问题，所以，什么都离不开业务，就算是性能优化也一样，通过之前那篇“12306.cn的性能优化”中的“业务分析”段落，我们可以知道业务的不同，系统的难度和解决方法就可以不同。所以，我们总是用技术在解决业务问题。业务的形态对软件的开发有决定性的作用。

下面让我具体描述一下。

一重门：业务功能

这是软件开发的第一重门，也就是掌握可以实现业务功能的技术。通常分成三块：语言、系统、数据处理。在这个阶段，主要是掌握各种技术，比如：开发用的各种工具（如：IDE、XUnit、Debugger等），各种代码库和框架（如：C++的STL、ACE、Boost等，Java的Spring、Hibernate等），各种系统知识（如：Windows API、Unix/Linux API、TCP/IP、Socket、多线程多进程间的同步和互斥、并发安全，还包括Web平台和移动平台，等等），还需要掌握数据处理的知识（如：数据结构、基本算法、数据库设计、数据库引擎、SQL等）。

这个阶段主要是把这些不同的技术组织成可以实现业务功能的解决方案。重点是能掌握和使用技术。很多流程和方法论的东西基本上就在这一重门里。这重门主要解决的是实现问题。

二重门：业务性能

业务的功能搞定了以后，就是业务的性能问题了。搞定功能并不难，搞定性能是有点技术含量的事。有句话不是那么说的吗——每个人都可以搞一个网站出来，但不是每个人都能搞出能支持百万级访问量的网站。但是，我看到很多技术团队或是工程师脱离了业务，只单纯地搞性能，比如：单台服务器支持10万个TCP链接的并发，等等。这些东西虽然在技术上有点意思，但是没有业务的环境，也只能是自娱自乐了。

我们可以看到一些企业开始注重这个问题了，性能问题也是最近被大家讨论得最多的问题，京东商场的性能问题，12306的性能问题，等等。

当然，所谓性能不并单单指系统的吞吐力，还指系统运行时的总体性能，比如，系统安全性能、系统的Accessbility的性能、系统的扩展性性能，等等，就像是前些天中“Web开发中需要注意的问题”一文中谈到的那些事一样。这表明着你对系统的全面和深入的了解。

在这个阶段，需要对业务模型、数据流、业务流、系统架构、算法和各种技术有深入的了解，要了解到本质上来。比如：在第一重门中，我们只需同要知道，Java有同步关键字，在这一重门中，我们还要知道同步或互斥对性能的巨大伤害性；在第一重门中，我们只需要知道STL中的智能指针或是STL的用法，这一重门中，我们还要知道智能指针中的refcnt的同步加锁对性能的损害，还需要知道STL中容器的size()方法在某些时候是性能很差的；在第一重门中，我们需要知道hash表的效率，在这一重门中，我们还需要知道hash表的碰撞问题。

最重要的是，在这重门重点是软件的设计问题。你需要有足够多的经验能比较不同设计方案的优缺点，比如TCP和UDP、同步和异步、epoll和select、push和pull、水平扩展的各种方案等。还记得本站的那篇“程序员的谎谬之言还是至理名言”，广度是你深度的副产品。所以，这重门是看你的技术视野有多深有多广。

三重门：业务智能

这重门可能是最难的一重门了，如果你能进到这重门里，你应该是科学家级的程序员了。让你有智能的业务，这可能是顶级的技术难题了。第一和第二重门都不算难，这重门是最难的。参看Amazon的个性化推荐系统，或是Google搜索引擎的结果个性化推荐等等（比如我输入“黑天鹅”关键字，你怎么知道我要找的是动物、电影还是本书？怎么让搜索出来的结果排名即公正又可行？），你就知道，用技术来解决这种类似的问题难度可想而知，不然就不会出现如 Hadoop之类的技术了。

我再举两个这重门里的业务方面的例子。

一个例子是关于库存计划的，需要像天气预报一样预测未来的销售量从而决定库存，所以，最简单的做法是，监测各个商品的销售统计，然后看一下最近的销售趋势，还要看一下往年的销售趋势（因为某些节假日会是一个高峰期），还要分析一下大众的喜好变化，比如，在某影评网站上的某电影的热度其会告诉我哪个电影的DVD要滞销了，得打折卖，哪个电影的DVD要畅销了，得多进货了。还可能需要监控新闻评论，比如某权威人士推荐了某个商品，那么我得赶快进货了，等等。这完全就是一门科学。

还有一个例子是配送问题。我有一辆卡车要处理我仓库和配送站间的物流问题，我需要找到一条最经济的路线来在有限的时间内处理最多的物流。这个不是最短路径问题，这是个计划统筹学的东西。也是一门科学。

还有近期“方韩之争”里有很多人来分析文章相似度的技术，这些东西都属于三重门里的东西。

到了这重门里，重要的可能不是技术，而是数学模型。这重门里主要是业务模型、数据模型和算法问题。这些东西和你的业务模型密切相关。能解决这样的问题，是真正的大牛。对于我来说，可能是高山仰止了。

后记

通过上面的说明，我们可以看到下面这些东西，

• 我的那篇“程序员技术练级攻略”里的东西只能让我们最多达到1.1 到 1.2重门。
• 一重门像是开垦荒地，二重门像是扩大生产，三重门像是精耕细作。
• 一重门（业务实现）里聚集着大量的劳动密集型的企业，劳动密集型的企业通常都需要流程和方法论。敏捷过程改进这类的东西只在一重门里。
• 二重门和三重门里只有少数不多的技术型的公司，这类的公司通常非常注重技术，并且企业文化是工程师的文化。
• 三重门里可以产生创新和那些可以用来改变世界的技术。
• 国内现在的情况是：一重门优化阶段 + 二重门的学习阶段。三重门里似乎还没有什么见术。不过，我看到一些公司已在尝试三重门的东西了。
• 作为技术人员的你，如果你想跟上时代，让自己有价值的话，你至少要达到二重门。
• 国内的技术环境等不良因素，导致大量的程序员在一重门的时候就已经失去信心，或被大浪淘沙淘掉了，所以，二重门里的程序员比较少了，但是随着年轻的一代 和技术的日趋成熟，也会慢慢多起来的，我现在已经看到这个趋势了。而三重门里的程序员成了稀缺的大熊猫。因为大量的二重门程序员干到那个时候都转管理了。

最后，我的这些言论不一定对，但希望能让大家有启发，有所思考。

作者注：本来这篇文章的标题想取成“程序员要解决的三种问题”， 但是因为过年都在关注 “方韩之争”，所以，干脆取成了这个名字。