程序员和软件工程师的区别
关于软件工程师和程序员的区别，大家都知道吗?今天小编就带大家了解一下 软件工程师和程序员的区别 ， 软件工程师是程序员吗 。
软件工程师和程序员的区别
其实懂IT的朋友应该知道，程序员和软件工程师之间有着很大的区别，软件工程师是对于软件开发相关工作的人员的一个统称。软件工程师是IT行业中需求量最大的一个职位，稳居IT行业职位需求TOP10第一位。软件工程师的技术要求比较全面的，除了最基础的编程语言(C语言/C++/JAVA等)、数据库技术(SQL/ORACLE/DB2等)、.NET平台技术、C#、C/S B/S程序开发，还要掌握诸如JAVA SCRIPT、AJAX、HIBERNATE、SPRING、J2EE、WEB SERVICE、STRUCTS等的前沿技术。除此之外，还要涉猎于网络工程和软件测试的其他技术，以便于操控全局。软件工程师可以说是一个项目开发的掌舵者。一名优秀的软件工程师应该具有较强的逻辑思维能力，对于技术的发展有着敏锐的嗅觉。虽然要求技术全面，但无须偏执于门门技术都精通，任何软件工程师都有自己的技术特长和偏向，对于自己手中的技术，可有精通-掌握-熟悉-了解之分，根据工作需要和职业发展的具体情况来划分。 程序员是专职从事程序开发、维护的专业人员。
按照标准来看：一个软件工程师的工作程序是需求分析、总体设计、详细设计、测试设计、软件开发编程。与此软件开发流程管理相适应，软件企业也要有合理的人力资源结构。在这一结构中每一个人都必须按照分工协作的原则来进行流水线作业，其中数量最多的要数从事软件开发编程等基础工作的人员，也就是我们所说的程序员。所以，程序员和软件工程师之间的区别就像盖楼的分工一样，程序员永远是扮演工人的角色，而软件工程师是这座大楼的设计人员。这也是程序员和软件工程师的最大区别。
软件工程师是程序员吗
应该说一个软件工程师首先应该是一个合格的程序员，但程序员只能是成为软件工程师的第一步。一个软件工程师来说，在掌握了基本的编程技能后，开发软件所需要的各种除了编码之外的其它知识会更为重要，比如如何从组织工程与项目的角度来看待软件开发的问题，如何为软件搭建合理准确的架构，什么样的软件会更易于维护与更新。故而软件工程师的级别要大于程序员。
程序员和工程师有什么不一样
第一、工程师不写黑箱程序
“程序=数据结构+算法”，这个著名的公式大家都知道，不幸的是，它不适合描述工程领域或者现实世界的程序。有很多程序，数据结构和算法都写得很棒，功能足够强大，系统足够复杂，但是——它很难调试，一跑起来就无法停止，而且谁也不知道程序现在到底在干什么，里面发生了什么。
别觉得好笑，我遇到过很多工作三四年甚至五六年的开发人员，仍然不停地生产黑箱程序：出现问题的第一反应是直接杀掉进程重启(天哪你们的程序不能安全关闭吗)。当然还有更生猛的，直接用开发机连上生产数据库(防火墙上开个洞)去调试。
你说他们技术不好吗?明明各种技术问题也能搞定。你说他们没有系统意识?做过的程序也不简单。但是，他们做的充其量只能叫“程序”，而不是工程上成熟的“系统”。
怎样的程序不是黑箱?你需要考虑它的层次划分，你需要考虑哪些(功能之外的)运行信息必须暴露和记录，以什么方式暴露记录，你甚至还需要考虑这些暴露和记录对性能的影响，以及程序需要对外提供什么操纵接口……当你把这一切都考虑清楚，写出能够让运行细节“尽在掌握中”的程序的时候，你的一条腿就迈进了“工程”的大门。
这方面，互联网和软件开发的大厂会更加关注一些，但也不是说个人就毫无追求的空间了。网络爬虫大家都会写，大家也都知道如果要数据抓得准，调试起来很麻烦。我有个朋友在某大厂写过一套“可视化”的爬虫，可以用逐步操纵语句的执行，迅速定位问题所在。这种水平的工程师，属于可遇而不可求的类型，每次说起来大家仍然啧啧称赞。
第二、工程师注意实现和接口分离
Java面试的一道经典问题是：请描述抽象类和接口的区别。通常，大家都会知道“接口”和“实现”要分离。不幸的是，很多人理解的“接口”，只是狭义的特定语言提供的Interface，而没有考虑“接口”真正的含义。
接口的真正含义是什么?计算机最擅长处理的是信息，它可以让信息脱离现实的障碍高速流动起来。如果说“实现”是干脏活累活，“接口”就是发出干脏活累活指令的窗口。脏活累活干一遍就足够了，但发指令的窗口却可以有千千万万。
更具体一点说，完成功能的是程序员，完成功能并且设想它会在什么情况下使用，并且让人方便使用的，是工程师。我见过不少这样的程序：登录会话一开始放在本地内存里没问题，到了要切换到数据库里方便会话转移就得大兴土木，虽然要做的其实仍然只是存取而已;程序自动加载的数据出了问题，就根本不能手动加载;以前手动加载的数据，改成自动加载就要推倒重来……
有没有接口意识，能不能真正区分接口和实现，这是区分程序员和工程师的一大标识。
第三、工程师注重功能的逻辑联系
很多系统都在不断的变化和改进过程中，程序员看到的是功能点，工程师看到的是功能点之上的逻辑。
任何系统当然都是由若干功能构成的。但在功能点之上，还需要一张有逻辑意义的大网，才能把功能点组合起来，把复杂度降低，成为大家能理解的对象。最简单的“登录”，就包含数据输入、数据验证、登录信息记录等等功能，“登录”是这些功能的逻辑集合，也是理解这些功能的基础。
随着时间的推移，业务的增长，新功能可能越来越多，比如用户数据的加载，对好友的通知，广告的推送准备等等。这些功能实现起来当然都容易(因为很具体)，但功能堆积的后果是复杂度急剧上升，因为功能之间的逻辑联系被切断了。所以，工程师必然需要思考，这些功能应该怎么组合，放到哪些具有逻辑意义的动作——比如“登录”里去?正是经过这样持续不断的思考，系统的复杂度才能够被一直维持在较低的水平，容易让大家理解。
这个例子看起来很简单，但做起来却没那么容易。我有时看到复杂的系统操作手册，简直让人哭笑不得：1) 点这里;2) 点那里;3) 输这个…… 这些操作对应的逻辑意义那么准确，分明就该是一次性自动完成的啊，把它们割裂开来的后果大大提高了系统的复杂度，既不方便维护，也不方便操作。最后来擦屁股的，只能是开发人员自己。
我经常反思自己接受的教育，在学校里写程序，和工作了写程序，有那么一点相同，但又好像完全两回事，到底有什么不同，只有亲自体会、思考了才能明白，所以我想把自己的所见所感写出来。悟性好的有机会接受很好训练的同学，估计不需要了解这些。但对于没有这样条件的同学，但愿我的这点念叨能给你们一点帮助。
猜你喜欢
