软件开发的“三重门”

标签: 杂项资源 职场生涯 Programmer 程序员 | 发表时间:2012-01-30 11:00 | 作者:陈皓
出处:http://coolshell.cn

自从上次写了“ 程序员技术练级攻略” 以来,就觉得似乎还有很多东西没有谈到,但当时没有继续思考了。而春节前有人问我,是做底层技术,还是做业务。这问题让我思考了很多,不由自主地回顾了一 下我这十多年的软件开发经历,并顺着整理分类了一下自己解决过的若干问题,还发散想了很多,经过了一个春节假期的发酵,产生了下面这篇文章。

前言

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

第一阶段:我 刚毕业时在家乡的某银行工作,做些银行的业务系统,还搞些网络,电子邮件系统,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要畅 销了,得多进货了。还可能需要监控新闻评论,比如某权威人士推荐了某个商品,那么我得赶快进货了。等等。这完全就是一门科学。
  • 还有一个例子是配送问题。我有一辆卡车要处理我仓库和配送站间的物流问题,我需要找到一条最经济的路线来在有限的时间内处理最多的物流。这个不是最短路径问题,这是个计划统筹学的东西。也是一门科学。

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

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

后记

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

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

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

:本来这篇文章的标题想取成“ 程序员要解决的三种问题”, 但是因为过年都在关注 “方韩之争”,所以,干脆取成了这个名字。你可以认为我比较调皮,也可以认为我爱ZB,还可以认为我标题党,反正,请随意理解。(这篇文章是我的自己写 的,没有代笔,因为你一定会在这篇文章中看到属于我的用五笔打出来的错别字,当然,我无法自证,哈哈)

转载时请注明作者和出处,请勿用于商业用途

您可能也喜欢:

漫画:程序员的一生

惹恼程序员的十件事

C++ 程序员自信心曲线图

我是怎么招聘程序员的

别的程序员是怎么读你的简历的
无觅

相关文章

相关 [软件开发 三重门] 推荐:

软件开发的“三重门”

- - 酷壳 - CoolShell.cn
自从上次写了“ 程序员技术练级攻略” 以来,就觉得似乎还有很多东西没有谈到,但当时没有继续思考了. 而春节前有人问我,是做底层技术,还是做业务. 这问题让我思考了很多,不由自主地回顾了一 下我这十多年的软件开发经历,并顺着整理分类了一下自己解决过的若干问题,还发散想了很多,经过了一个春节假期的发酵,产生了下面这篇文章.

软件开发的核心

- - 博客园_知识库
  「我们一直这样做开发,时间做久了,便忘了当初的本意.   有关软件系统开发,我们谈些什么.   我们谈过程,编码规范、开发流程、同行评审、结对编程、持续集成,从瀑布到敏捷再到极限编程.   我们谈架构,企业级、J2EE、容器化、SOA(面向服务架构)、Microservices(微服务化).   我们谈规模,大容量、高并发、大数据.

软件开发的人文关怀

- - 博客园_知识库
  几年前,我从温伯格的《技术领导之路》中学到一点:技术人员往往更喜欢和机器打交道,因为他们“认为”自己更适合和机器打交道;但是,优秀的技术人员必须(也必然)具备好的沟通能力. 所以,温伯格鼓励各位技术人员多加练习和其他人打交道的能力. 温伯格的这个观点我是非常赞成的,好的技术人员一定需要“勇敢”面对他人,不能被“自实现的预言”局限在机器的世界里.

软件吞噬软件开发

- - PingWest中文网
软件蚕食世界,自互联网特别是移动互联网连接线上线下服务后,已成为不可逆的趋势. 每一项实用的服务可以由小团队来完成. 以WhatsApp为例,这款被高调收购的IM应用,拥有4.5亿月活跃用户,70%的日活跃率,至今还保持每天新增用户1000万的速度. 但这些服务居然由32名工程师支撑下来了,所以有了业界八卦“每位员工价值20亿”的说法.

软件开发中的两种态度

- - 外刊IT评论网
一种态度认为,应该对程序员在软件开发中的行为进行约束( DirectingAttitude). 持这种态度的人认为大部分的程序员水平都不高(谣传说有50%的人低于平均水平),所以应该对他们所做的事情进行管教约束. 要防止他们做一些可能会给他们正在开发的系统带来危害的事情. 通常,这种态度体现在一些系统设计和工具中时,你会发现它们会试图阻止程序员去做某些事情,限制程序员的一些做法,以此避免他们陷入过于复杂的境况.

软件开发的人文关怀

- - 极客公园-GeekPark
我是极客公园黑板报认证值日生. [核心提示]软件可以没有活力,而软件开发却不能没有活力;程序可以像机器一样,程序员却不能像机器一样. 要改变这种状态,就应当增添更多的人文关怀,把开发人员当成活生生的人,而不是视为程序或者工具. 编辑注记:本文来自余晟的博客 乱象,印记. 作者从自己的经验出发,提出了一些给软件开发人员提供人文关怀的可行措施.

软件开发模型综述

- - CSDN博客推荐文章
                     软件开发模型概述. 最早出现的软件开发模型是1970年W·Royce提出的瀑布模型. 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架. 软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段.

防火长城内的软件开发

- - Solidot
对于软件开发者来说,防火长城不只是屏蔽网站过滤流量这么简单——它是痛苦之源,尤其是如果你想开发针对中国市场之外的软件或想利用广泛使用的服务和软件库的话. 上海聊天机器人创业公司Rikai Labs的创始人DC Collier认为,中国的软件开发者写代码的时候一只手是绑在背后的. 防火长城的屏蔽范围日益扩大,这意味着越来越多的服务被永久性或不定期的屏蔽.

自上而下的软件开发和自下而上软件开发

- - 外刊IT评论网
自上而下(Top Down)开发模式是指从一个应用的最高点开始开发. 从最高点逐步往下层编码,直到开发完所有的任务. 一旦写完了最下层的代码,开发任务就完成了. 使用这种方式,你需要设计、编写出所有你需要的但还没有实现模拟接口、服务、伪代码. 自下而上(Bottom up)开发模式是指从一个应用的最底层开始开发.

软件开发团队主管易犯的十个错误

- Frank Cai - 36氪
本文是Roy Osherove在Skills Matter的一次发言,他介绍了团队领导经常会犯的十个错误,并提出了一些解决方案. Roy首先提出几个团队领袖可能遇到的一些问题:. 我如何说服的我团队做某件事情. 我该拿团队里的那个专门搞事的家伙怎么办?. 我们为什么无法远离无谓的争吵呢?. 他说这些问题其实缠绕他多年,接下来他也逐一做出解答.