程序员和工程师有什么不一样？

我刚刚工作的时候，面试官曾经跟我说：好好干两年，可以迅速从程序员成长为工程师。当时我觉得太诧异了，从很多招聘启示来看，“程序员”不就等于“工程师”吗，只是“工程师”更好听一些而已。等我工作久了，才知道“程序员”和“工程师”真的是不一样的——程序员只写程序，工程师写能在现实世界中创造价值的程序。

可惜，很多软件开发人员未必清楚两者的差别，甚至做了很久也只算程序员而不算严格意义上的工程师。所以我就自己的观察和经验，谈谈程序员和工程师的差别。

第一，工程师不写黑箱程序。

“程序=数据结构+算法”，这个著名的公式大家都知道，不幸的是，它不适合描述工程领域或者现实世界的程序。有很多程序，数据结构和算法都写得很棒，功能足够强大，系统足够复杂，但是——它很难调试，一跑起来就无法停止，而且谁也不知道程序现在到底在干什么，里面发生了什么。

别觉得好笑，我遇到过很多工作三四年甚至五六年的开发人员，仍然不停地生产黑箱程序：出现问题的第一反应是直接杀掉进程重启（天哪你们的程序不能安全关闭的吗？）。当然还有更生猛的，直接用开发机连上生产数据库（防火墙上开个洞）去调试。

你说他们技术不好吗？明明各种技术问题也能搞定。你说他们没有系统意识？做过的程序也不简单。但是，他们做的充其量只能叫“程序”，而不是工程上成熟的“系统”。

怎样的程序不是黑箱？你需要考虑它的层次划分，你需要考虑哪些（功能之外的）运行信息必须暴露和记录，以什么方式暴露记录，你甚至还需要考虑这些暴露和记录对性能的影响，以及程序需要对外提供什么操纵接口……当你把这一切都考虑清楚，写出能够让运行细节“尽在掌握中”的程序的时候，你的一条腿就迈进了“工程”的大门。

这方面，互联网和软件开发的大厂会更加关注一些，但也不是说个人就毫无追求的空间了。网络爬虫大家都会写，大家也都知道如果要数据抓得准，调试起来很麻烦。我有个朋友在某大厂写过一套“可视化”的爬虫，可以用逐步操纵语句的执行，迅速定位问题所在。这种水平的工程师，属于可遇而不可求的类型，每次说起来大家仍然啧啧称赞。

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

Java 面试的一道经典问题是：请描述抽象类和接口的区别。通常，大家都会知道“接口”和“实现”要分离。不幸的是，很多人理解的“接口”，只是侠义的特定语言提供的 interface，而没有考虑“接口”真正的含义。

接口的真正含义是什么？计算机最擅长处理额是信息，它可以让信息脱离现实的障碍高速流动起来。如果说“实现”是干脏活累活，“接口”就是发出干脏活累活指令的窗口。脏活累活干一遍就足够了，但发指令的窗口却可以有千千万万。

更具体一点说，完成功能的是程序员，完成功能并且设想它会在什么情况下使用，并且让人方便使用的，是工程师。我见过不少这样的程序：登录会话一开始放在本地内存里没问题，到了要切换到数据库里方便会话转移就得大兴土木，虽然要做的其实仍然只是存取而已；程序自动加载的数据出了问题，就根本不能手动加载；以前手动加载的数据，改成自动加载就要推倒重来……

有没有接口意识，能不能真正区分接口和实现，这是区分程序员和工程师的一大标识。

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

很多系统都在不断的变化和改进过程中，程序员看到的是功能点，工程师看到的是功能点之上的逻辑。

任何系统当然都是由若干功能构成的。但在功能点之上，还需要一张有逻辑意义的大网，才能把功能点组合起来，把复杂度降低，成为大家能理解的对象。最简单的“登录”，就包含数据输入、数据验证、登录信息记录等等功能，“登录”是这些功能的逻辑集合，也是理解这些功能的基础。

随着时间的推移，业务的增长，新功能可能越来越多，比如用户数据的加载，对好友的通知，广告的推送准备等等。这些功能实现起来当然都容易（因为很具体），但功能堆积的后果是复杂度急剧上升，因为功能之间的逻辑联系被切断了。所以，工程师必然需要思考，这些功能应该怎么组合，放到哪些具有逻辑意义的动作——比如“登录”里去？正是经过这样持续不断的思考，系统的复杂度才能够被一直维持在较低的水平，容易让大家理解。

这个例子看起来很简单，但做起来却没那么容易。我有时看到复杂的系统操作手册，简直让人哭笑不得：1) 点这里；2) 点那里；3) 输这个…… 这些操作对应的逻辑意义那么准确，分明就该是一次性自动完成的啊，把它们割裂开来的后果大大提高了系统的复杂度，既不方便维护，也不方便操作。最后来擦屁股的，只能是开发人员自己。

我经常反思自己接受的教育，在学校里写程序，和工作了写程序，有那么一点相同，但又好像完全两回事，到底有什么不同，只有亲自体会、思考了才能明白，所以我想把自己的所见所感写出来。悟性好的有机会接受很好训练的同学，估计不需要了解这些。但对于没有这样条件的同学，但愿我的这点念叨能给你们一点帮助。