1445420687756760.jpg

  我刚刚工作的时候,面试官曾经跟我说:好好干两年,可以迅速从程序员成长为工程师。当时我觉得太诧异了,从很多招聘启事来看,“程序员”不就等于“工程师”吗,只是“工程师”更好听一些而已。等我工作久了,才知道“程序员”和“工程师”真的是不一样的——程序员只写程序,工程师写能在现实世界中创造价值的程序。
  可惜,很多软件开发人员未必清楚两者的差别,甚至做了很久也只算程序员而不算严格意义上的工程师。所以我就自己的观察和经验,谈谈程序员和工程师的差别。

  第一、工程师不写黑箱程序

  “程序=数据结构+算法”,这个著名的公式大家都知道,不幸的是,它不适合描述工程领域或者现实世界的程序。有很多程序,数据结构和算法都写得很棒,功能足够强大,系统足够复杂,但是——它很难调试,一跑起来就无法停止,而且谁也不知道程序现在到底在干什么,里面发生了什么。
  别觉得好笑,我遇到过很多工作三四年甚至五六年的开发人员,仍然不停地生产黑箱程序:出现问题的第一反应是直接杀掉进程重启(天哪你们的程序不能安全关闭吗)。当然还有更生猛的,直接用开发机连上生产数据库(防火墙上开个洞)去调试。
  你说他们技术不好吗?明明各种技术问题也能搞定。你说他们没有系统意识?做过的程序也不简单。但是,他们做的充其量只能叫“程序”,而不是工程上成熟的“系统”。
  怎样的程序不是黑箱?你需要考虑它的层次划分,你需要考虑哪些(功能之外的)运行信息必须暴露和记录,以什么方式暴露记录,你甚至还需要考虑这些暴露和记录对性能的影响,以及程序需要对外提供什么操纵接口……当你把这一切都考虑清楚,写出能够让运行细节“尽在掌握中”的程序的时候,你的一条腿就迈进了“工程”的大门。
  这方面,互联网和软件开发的大厂会更加关注一些,但也不是说个人就毫无追求的空间了。网络爬虫大家都会写,大家也都知道如果要数据抓得准,调试起来很麻烦。我有个朋友在某大厂写过一套“可视化”的爬虫,可以用逐步操纵语句的执行,迅速定位问题所在。这种水平的工程师,属于可遇而不可求的类型,每次说起来大家仍然啧啧称赞。

  第二、工程师注意实现和接口分离

  Java面试的一道经典问题是:请描述抽象类和接口的区别。通常,大家都会知道“接口”和“实现”要分离。不幸的是,很多人理解的“接口”,只是狭义的特定语言提供的Interface,而没有考虑“接口”真正的含义。
  接口的真正含义是什么?计算机最擅长处理的是信息,它可以让信息脱离现实的障碍高速流动起来。如果说“实现”是干脏活累活,“接口”就是发出干脏活累活指令的窗口。脏活累活干一遍就足够了,但发指令的窗口却可以有千千万万。
  更具体一点说,完成功能的是程序员,完成功能并且设想它会在什么情况下使用,并且让人方便使用的,是工程师。我见过不少这样的程序:登录会话一开始放在本地内存里没问题,到了要切换到数据库里方便会话转移就得大兴土木,虽然要做的其实仍然只是存取而已;程序自动加载的数据出了问题,就根本不能手动加载;以前手动加载的数据,改成自动加载就要推倒重来……
  有没有接口意识,能不能真正区分接口和实现,这是区分程序员和工程师的一大标识。

  第三、工程师注重功能的逻辑联系

  很多系统都在不断的变化和改进过程中,程序员看到的是功能点,工程师看到的是功能点之上的逻辑。
  任何系统当然都是由若干功能构成的。但在功能点之上,还需要一张有逻辑意义的大网,才能把功能点组合起来,把复杂度降低,成为大家能理解的对象。最简单的“登录”,就包含数据输入、数据验证、登录信息记录等等功能,“登录”是这些功能的逻辑集合,也是理解这些功能的基础。
  随着时间的推移,业务的增长,新功能可能越来越多,比如用户数据的加载,对好友的通知,广告的推送准备等等。这些功能实现起来当然都容易(因为很具体),但功能堆积的后果是复杂度急剧上升,因为功能之间的逻辑联系被切断了。所以,工程师必然需要思考,这些功能应该怎么组合,放到哪些具有逻辑意义的动作——比如“登录”里去?正是经过这样持续不断的思考,系统的复杂度才能够被一直维持在较低的水平,容易让大家理解。
  这个例子看起来很简单,但做起来却没那么容易。我有时看到复杂的系统操作手册,简直让人哭笑不得:1) 点这里;2) 点那里;3) 输这个…… 这些操作对应的逻辑意义那么准确,分明就该是一次性自动完成的啊,把它们割裂开来的后果大大提高了系统的复杂度,既不方便维护,也不方便操作。最后来擦屁股的,只能是开发人员自己。
  我经常反思自己接受的教育,在学校里写程序,和工作了写程序,有那么一点相同,但又好像完全两回事,到底有什么不同,只有亲自体会、思考了才能明白,所以我想把自己的所见所感写出来。悟性好的有机会接受很好训练的同学,估计不需要了解这些。但对于没有这样条件的同学,但愿我的这点念叨能给你们一点帮助。