极客时间已完结课程限时免费阅读

01 | 到底应该怎样理解软件工程？

01 | 到底应该怎样理解软件工程？-极客时间

01 | 到底应该怎样理解软件工程？

2019-02-23 宝玉 来自北京
《软件工程之美》
课程介绍

讲述：宝玉

时长11:26大小10.48M

你好，我是宝玉，我今天分享的主题是：什么是软件工程？
当有人问你什么是软件工程，你会想到什么？
也许你会想到软件，会想到建筑工程，也许对此还没有什么概念。不要紧，在回答这个问题前，我们先来看看软件工程和我们的日常生活有哪些关系。
作为一个程序员，你的日常大致是这样的：早上被手机的闹钟叫醒，然后坐地铁去上班。在路上你会打开微信和朋友闲聊几句，刷刷微博，还会用 Youtube 看看视频充充电；上班的时候，你打开 Mac 电脑，用 VS Code 写程序，用 Chrome 看网页，下班后再玩几局守望先锋游戏。
你发现了没？在这一天的日常生活里面，软件无处不在。手机操作系统软件、闹钟 App、微信、微博、Youtube、Mac OS、VS Code、Chrome、守望先锋，这些都是软件，你的日常生活已经和这些软件密不可分。

软件是怎么被创造出来的？

那么你有没有想过，这些软件是怎么来的呢？
首先，它们的诞生都是有人想要造一个东西。这其中的很多故事你都耳熟能详：张小龙创造微信、乔布斯创造 iOS、暴雪想做一款不一样的射击游戏……他们首先有着这样的意图，然后，他们立项做这样的产品。
每一款软件项目背后，都有很多人在参与。你无法想象微信这样复杂的 App 靠张小龙自己可以开发出来；你也不会相信 iOS 是乔布斯一个人设计出来的；像守望先锋这种游戏的背后，有成百上千的游戏策划、美术设计、程序开发人员。
从立项到第一个版本的发布，每个成功的软件都需要有计划、有步骤地进行，什么时候发布第一个版本、第一个版本有什么样的功能、什么时候发布第二个版本、第二个版本有哪些地方要改进，这些都是研发过程中需要考虑的问题。
比如，守望先锋是在 2013 年立项，他们计划做一个基于职业的 MMO 游戏，他们先花了几个月的时间做了第一个 Demo 演示，只有四个英雄和一个张地图。
图片来源：The treasures of the Overwatch Archives panel at Blizzcon
然后，他们要在 2014 年的“暴雪嘉年华”发布这个游戏的试玩版，包含 12 个英雄和 4 张地图。
图片来源：The treasures of the Overwatch Archives panel at Blizzcon
最终这个游戏在 2016 年 5 月正式发布了。这样从立项一步步到最终发布，历时三年，中间经过了诸多环节。
类似的例子还有微信，2010 年 11 月 20 日立项，2011 年 1 月 21 日第一版上线，当时的功能还非常简陋，只能发送文本消息和照片。之后才是一个个版本的迭代，直到你现在看到的微信。
像这种有人参与、有计划、有步骤地造一件产品，我们通常称为“工程”。
所有工程的本质，就是要做出有用的产品，比如造房子的建筑工程、造火箭的航天工程。像网红“手工耿”一样专搞无用发明的情况，我们是不能称为“工程”的。
在软件领域，对应的就是“软件工程”，这些我们日常使用的软件背后，都是基于软件工程的方法在开发、运行和维护的。

如何摆脱“软件危机”？

也许有人会认为，不用软件工程，我一样可以开发软件出来。这确实没有错，因为如果一个人没有学过建筑工程，他也是可以造一个房子出来，只是造出来大概会是这个样子：
我们知道，不按照建筑工程造房子，是会出事故甚至死人的。而在软件工程的历史上，也是真的有造成过很大损失、甚至还有人为之丧命的事件存在。
OS/360 操作系统是上世纪 60 年代最复杂的软件系统之一，也是第一个超大型的软件项目，一共有 1000 名左右的程序员参与了项目的研发，花费了 5000 个人年，最终无法运行。项目负责人佛瑞德·布鲁克斯后来写了一本软件工程的经典书籍《人月神话》，承认在他管理这个项目的时候，犯了很多错误，造成了价值数百万美元的损失。
如果是说 OS/360 还只是造成了经济损失的话，Therac-25 事件就是真的导致了人员死亡。Therac-25 是加拿大原子能有限公司（AECL）所生产的放射线疗法机器，在 1985 年到 1987 年之间，在美国及加拿大，至少有六起和 Therac-25 相关的医疗事故是因为程序 bug，导致部分病患受到比正常剂量高一百倍的辐射，因而造成患者重伤甚至死亡。
发生这些惨痛的事，原因却并不难理解。
在计算机刚发明出来的时候，计算机的能力非常有限，只能接收简单的指令和运算，不需要软件工程也可以开发出简单的软件。
但是，当软件的规模越来越大，复杂度不断增加，软件项目开发维护过程中的问题就逐步暴露出来：软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加。所以在 60 年代，“软件危机”的概念被提出来。
为了摆脱软件危机，1968 年秋季，北大西洋公约组织的科技委员会召集了近 50 名一流的编程人员、计算机科学家和工业界巨头，讨论和制定对策。在那次会议上第一次提出了“软件工程”（software engineering）这个概念。
从此诞生了一门新兴的工程学科：软件工程，它是为研究和克服软件危机而生。
在这次会议上，同时也提出了“软件工程”的定义：
为了经济地获得在真实机器上可靠工作的软件而制定和使用的合理工程原则。
（Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.）
1993 年，电气电子工程师学会（IEEE）给出了一个更加综合的定义：
将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中。
（Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).）
如果你去搜索一下“软件工程定义”，你还能找到很多其他定义，这里就不一一列举。我们没必要花太多时间在这些字面解释上，关键是要抓住这些定义的本质：就是要用工程化方法去规范软件开发，让项目可以按时完成、成本可控、质量有保证。

软件工程的演化史

对比传统的工程学科，和软件工程最接近的就是建筑工程了。设想一下建一座房子：首先要先立项、设定预算，然后画设计图，再是施工，施工完成后，由专业人士进行质量检查，质检合格后入住。
开发软件本质上也是像盖房子一样，是从无到有创造的过程。工程化的方式，就是你分步骤（过程），采用科学的方法，借助工具来做产品。
于是参考建筑工程，整个软件开发过程也被分成了几个阶段：需求定义与分析、设计、实现、测试、交付和维护，这也就是我们常说的软件项目生命周期。
当然，各个阶段都会有人的参与，于是产生了软件项目里的各种角色：项目经理、产品经理、架构师、程序员、测试工程师、运维工程师。而对这整个过程的管理，我们通常称之为“项目管理”。
同时，也很自然就衍生出一套最基础的过程模型：瀑布模型。
瀑布模型的诞生，在当时是有非常重大的意义的，让软件开发从无序到有序，让大家更好的分工协作，同时每个阶段又衍生出各自的方法学和工具，例如需求分析、软件测试等等。
然而瀑布的特性决定了它只能从上往下流，而且从上到下走完整个周期很长，所以一旦出现了需求的变更，将会非常痛苦，很多事情需要重头再来。
于是基于瀑布模型，又衍生出 V 模型、原型设计、增量模型、螺旋模型等模型，试图改善瀑布模型存在的一些缺陷。这些改进模型的发展趋势上就是缩短项目周期，快速迭代。
这样到了 90 年代，各种轻量级开发方法例如 Scrum、极限编程等也不断被提出。到了 2001 年，这些轻量级开发方法一起组成了敏捷联盟，其后敏捷开发如同星星之火，逐渐形成燎原之势。
近些年，云计算、微服务这些新技术的产生，也对软件工程产生了影响。云服务让分工更细，很多企业可以将运维、服务器维护、DBA、甚至某些独立服务交给云服务商；微服务让大团队变成小团队，每个小团队可以更专注于细分领域，减少相互之间的依赖。 ​

一个公式

当你大致了解整个软件工程的演变发展史，你会发现，软件工程的知识，都是建立在软件项目的过程，或者说软件项目生命周期之上的。
基于软件过程，我们有了角色分工，有了对过程的管理和工具，对过程中每个阶段细分的方法学和工具。
现在，如果再回头看看我们的问题“什么是软件工程？”其实可以总结为：软件工程就是用工程化的方法来开发维护软件。也可以说软件工程就是用一定的过程，采用科学的方法，借助工具来开发软件。
如果用一个简单的公式表达，那就是：软件工程 = 过程 + 方法 + 工具。

总结

今天，我和你一起追溯了一下软件工程的起源，你知道了软件工程学科的产生，就是为了解决软件危机。也见证了整个软件工程的演变历史，从瀑布模型到敏捷开发。
从 1968 年提出软件工程到现在，正好是 50 年。在 2002 年，我最开始学软件工程专业的时候，还只有瀑布模型、需求分析、系统设计等这些传统软件工程内容，但是经过十几年的发展，在软件项目中，敏捷开发、持续集成、微服务等这些新兴内容已经开始在软件项目中占据越来越重要的位置。
可以预见，未来软件工程领域还会有新的概念、新的知识诞生。但是万变不离其宗，只要你抓住软件工程的本质，无论将来如何变化，你总能很快掌握新的知识内容。
而软件工程的核心，就是围绕软件项目开发，对开发过程的组织，对方法的运用，对工具的使用。

课后思考

当然，每个人对于软件工程的理解也是不同的，你理解的软件工程是什么样子的呢？欢迎在留言区留言讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 23

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
学习攻略 | 怎样学好软件工程？
下一篇
02 | 工程思维：把每件事都当作一个项目来推进
 写留言

精选留言(57)

  • javaadu
    2019-02-23
    软件过程不是搞科研，不是搞艺术，而是解决多人合作将一个想法落地的学科，其中包括严谨的过程步骤、规范，用于提高效率或防范风险的工具。 软件工程的主体是工程，这就要求我们具备基本的工程思维：模块化思维、抽象思维；具备一些关键的意识：质量意识、风险意识、交付意识。

    作者回复: 这个总结很赞👍 建议也可以分享到微博或者博客

    共 2 条评论
    94
  • hua168
    2019-02-25
    老师，像我们中小公司，开发人员流失严重，如果像工厂流水线那样，即使核心开发人员全部走了，新招的开发在没有人带的情况下，能继续接上开发…… 出了制定规范，开发文档之外还有那些措施？ 我见过核心开发有威胁老板加工资的情况，不加就辞职，要是核心开发都走了，新招的开发都不敢动整个网站，盈利性的，都怕出错。

    作者回复: 软件开发，核心就是人，如果没有人，规范和文档都没意义的。要留住人，一个么得舍得给钱，另一个得有个好的环境，还有就是要有梯队，能把新人培养上去。 饭店里只有一个大厨，大厨当然敢乱提要求，如果大厨多几个，就不担心了。还是得要舍得下本钱招优秀的人。

    共 2 条评论
    26
  • alva_xu
    2019-02-23
    对于大型系统的建设，可否用敏捷方法来实现，一直是个问题。敏捷方法，适合于小团队（比如两个披萨团队）、小架构。对于大型单体应用的开发，至少在架构设计上是不适合用敏捷迭代方式的。为了解决大型系统建设的迭代开发、快速交付问题，业内不断在探索。随着微服务架构的提出，以及容器技术的成熟，和cicd的实现，单体巨石应用被拆解成分布式的微服务应用，此时，敏捷方法也就开始真正大行其到了。所以，微服务、容器、devops这三剑客和敏捷方法一起，互为依存、互相促进，成为了软件工程中最有生命力的技术工具和流程，使软件开发在质量和效率上得到极大提升。
    展开

    作者回复: 总结的赞👍 这些技术得以流行，还有大公司近些年越来越多的实施敏捷，就是因为能帮助把大团队拆分成小团队，大服务变微小服务

    共 2 条评论
    25
  • 行者无疆
    2019-02-23
    关于传统的瀑布模型和现代的敏捷模型如何取舍和运用我一直有个疑问：传统瀑布模型前期进行了完整的需求评估，在技术选型，系统架构，实施路径上可以做好全面的规划，虽然周期长，不必要的反复工作会少很多，目标也更容易控制。那敏捷模型的迭代方式并不会把需求都考虑全面，未来的迭代可能会造成前面的技术架构或者实施细节等都不能满足新需求的要求。所有工作都要重来的问题，会存在大量的重复工作和资源浪费。 敏捷模型是如何有效地规避这些问题的呢？
    展开

    作者回复: 你说的问题确实存在，导致常说的技术债务问题，所以需要定期去重构，改进这些问题。 迭代过程中的重复工作确实存在，但是软件开发中的浪费其实主要不是在于迭代过程中的重复工作，而是在于需求不明确和需求变更导致的返工或失败。敏捷开发持续发布稳定版本的理念还是利大于弊。 有一些项目其实是瀑布模型和敏捷开发的结合，需求分析和系统设计的时候用瀑布模型，开发和测试阶段用敏捷，也是个不错的选择。

    16
  • 分清云淡
    2019-02-23
    现在已经进入云计算时代，基本上大中小企业都在上云，复杂逻辑都在云端处理，真的还需要软件工程里讲的开发要搞这么多流程么？

    作者回复: 是的，云计算的兴起可以减少很多劳动，但不代表你就什么都不用做了，还是要做需求分析，再去做架构设计，做完架构设计你才能清楚哪些可以用云计算，那些需要自己去实现。最后编码完了，一样还要测试的。

    14
  • 谭鹏
    2019-02-25
    开发就是在堆功能 ，领导就觉得软件开发就是工作量的问题 多加班 一周工作六天 一天工作15个小时 就能很快出结果 就是计件工作，结果计划半个月的工作 4个月还完不成 领导就觉的是开发人员有问题

    作者回复: 是的，最初大家都以为软件是靠人数堆出来的，以为加人就能减少开发时间，所以后来有了《人月神话》。 不过这个问题，我建议你还是客观分析一下，为什么4个月完不成？是工作量估算问题？还是实现的方法不当？ 如果你能帮助找出来原因，并有可以改进的优化方案，对你学习理解《软件工程》是有极大帮助的。 有具体问题欢迎留言。

    共 2 条评论
    7
  • 老张
    2019-02-24
    在今天没有不可替代的硬件，却有无数不可替代的软件。硬件早已不是共享的壁垒，而曾经被认为有很强可塑性的却已经是最硬的壁垒。 一台服务器、一块磁盘、一根内存以及交换机、防火墙等网络设备，更遑论鼠标、键盘、显示器，在冗余、复用、虚拟化等等技术之下，更换、替代、扩容如此之方便，经过简单培训的工人就可以轻松完成。 可是即便是美国国会图书馆，依然认为纸质是保存资料最好的方式，因为大量资料电子化后存放在不同介质，需要当时定制的软件才能读取这些格式。 今天的软件就是这么硬。也许有一天，有人会写写如何开发真正的软件。
    展开

    作者回复: 👍

    6
  • 一年
    2019-02-23
    软件工程在小团队时候没有重视，追求速度，当团队扩大了，需求越来越多了，功能迭代一个接一个的时候，发现项目已经堆积得足够的大了，这个时候如何用软件工程的思维来维护开发质量呢？

    作者回复: 你说的这种是常见的现象，在团队扩大后，需要注意几件事： - 对已有项目要考虑偿还技术债务，进行重构。《23| 技术债务：是继续修修补补凑合着用，还是推翻重来？》 - 要考虑逐步规范项目流程，例如要有代码审查、单元测试等规范，不能一味追求速度走捷径绕过这些好的实践《11 | 流程和规范：红绿灯不是约束，而是用来提高效率》 - 可以使用敏捷开发或者借助敏捷开发的一些好的实践，用固定的周期、用持续交付的思路，持续稳定的交付需求。 可以先从这几个角度思考一下。

    7
  • Sam_Deep_Thinking
    2019-10-21
    过程其实是将工程分解成各个环节，有了环节自然就有角色，有了角色，就有了沟通。 老师，能再单独的从各个角色出发，说一下各个角色在各个环节中的作用吗？最好把公司经营者也说进去。

    作者回复: 这个话题有点大，我建议你可以结合《03 | 瀑布模型：像工厂流水线一样把软件开发分层化》这篇文章阅读。 这里我简单介绍一下： 一个项目立项后，首先要有负责人，组织和推进整个项目的进行，一般这个角色就是项目经理。《10 | 如果你想技术转管理，先来试试管好一个项目》 在项目开始的时候，也就是瀑布模型的需求分析阶段，需要有人去确认需求，根据确定好的需求去设计产品，这个角色就是产品经理。《19 | 作为程序员，你应该有产品意识》 在需求确定后，需要有人设计架构，对需求进行抽象，对模块进行设计和合理组合，这样的角色就是架构师。《23 | 架构师：不想当架构师的程序员不是好程序员》 在架构设计有了后，就可以开始基于需求和架构设计进行编码了，这个角色大家都比较熟悉，就是程序员。《27 | 软件工程师的核心竞争力是什么？（上）》 在编码完成后，需要有人对完成的结果进行校验，以确认满足需求，这样的角色就是测试工程师。《32 | 软件测试：什么样的公司需要专职测试？》 在测试验收通过后，就需要有人将完成的产品发布部署到生产环境，并且对生产环境的运行进行监控，这样的角色就是运维。《36 | DevOps工程师到底要做什么事情？》

    6
  • 贤蛋蛋
    2019-02-26
    如果你看过Winston Royce提出瀑布模型的那篇论文会发现，瀑布模型也是迭代式的，只不过被美国军方误用进而导致业界的误解。

    作者回复: 👍确实如此，《构建之法》中也有提及。 我们现在所实践的瀑布模型，和论文中提出的模型还是有些差别。

    5
  • 王子瑞Aliloke有事电...
    2019-02-25
    土木工程专业转行程序员，好巧，原专业是建在实实在在的土建工程，现在是在虚拟世界建造数字工程。

    作者回复: 早期软件工程很多借鉴建筑工程的，相信可以帮助你更好的理解👍

    5
  • YT
    2019-02-24
    很多时候领导想要做的项目都是拍脑袋的想法，需求很模糊，不明确。如何才能做好需求分析？

    作者回复: 需求需要反复沟通确认的，是一个从粗到细的过程。 最开始可以画草图，找相似产品对比，确认大方向。 然后把你的理解制作成原型，用原型去确认，根据反馈再反复修改。 最终确认了后再去开发。

    4
  • williamcai
    2019-02-23
    软件工程是为应对软件复杂，需求多变而产生的理论，方法，工具的集合。

    作者回复: 👍 还需要注意软件工程的目标是构建高质量的软件。

    4
  • Know-nothing的Duckl...
    2019-03-10
    如果说软件工程=过程+方法+工具，其中过程是否就是具体指软件的生命周期？方法是指选用的生命周期模型，比如瀑布、螺旋、迭代、敏捷？

    作者回复: 我认为过程应该包含过程模型采用的方法。而方法是指基于过程模型之下的方法。 因为过程模型决定了软件开发过程是什么样的，进而决定了采用什么开发方法。 比如你选择了瀑布模型，整个软件开发过程就是按照瀑布模型的分阶段来进行，对应的方法就是瀑布模型中的方法，例如需求分析、架构设计；如果你选择了敏捷开发，则整个开发过程就是一种敏捷迭代方式，后面的方法对应的就是敏捷开发的一套方法体系，例如Scrum、用户故事、持续集成等。

    3
  • Sudouble
    2019-03-02
    为致力于产生更高质量产品，软件开发以单一的编码，向着分工更明确，工作效率更高的方向前进。

    作者回复: 赞👍 总结的很好，后面可以再看看软件工程是怎么去达到这个目标的。

    3
  • 起而行
    2019-03-01
    软件是程序+数据结构+文档。 软件工程，是可用性与开发难度之间平衡的技术，是效率提高与成本增加之间的博弈

    作者回复: 赞 在《构建之法》里面，也有另一种定义： 软件=程序+软件工程

    3
  • 村长@极客时间
    2019-02-28
    我刚去百度了一下手工耿，简直要笑死了。这个专栏的老师和编辑真时髦，啥都知道

    编辑回复: 你的求知精神，也是很赞呢😁😄

    3
  • 一路向北
    2019-02-25
    软件工程和建筑工程这个类比很到位，能够比较直观的理解做好软件工程的重要性。软件工程过程中的每一步，其实和建筑工程类似，早期的房子比较简单，整个房子的模型很容易想象出来，而房子和内部的装修越来越复杂，靠几个人几乎不可能完成，软件也是类似。 但是在实际开发软件的过程中发现，如何内化这种软件工程的思维，还是有很大困难，因为对于一个新项目，往往最终的需求都不是很明确，很难去规划最终要把软件做成什么样？这里还应该和做软件设计的工程师的经验，知识架构，业务理解程度有关系。
    展开

    作者回复: 是的，还是需要经验的积累，学习不是一蹴而就的事。还是有些方法可以帮助你做的更好。比如说需求不明确，可以尝试原型设计；可以尝试快速迭代，早确认需求。

    3
  • 纯洁的憎恶
    2019-02-23
    我理解工程就是在现实中，协调各种资源，完成复杂工作，解决具体问题的一系列标准、规程、方法，软件工程则是针对于软件开发领域的工程策略集。

    作者回复: 👍

    3
  • zhxilin℃+
    2019-02-23
    本科专业就是软件工程，重新拾起来非常亲切。时代在进步，许多知识也需要不断翻新。软件工程就是一艘帆船的舵，决定了工程的航向。btw，老师声音不错哇

    作者回复: 我本科也是软件工程的🤝，这些年软件工程的知识也还是一直在更新迭代中，其过程+方法+工具的本质并没有变，无非是各种方法和工具的推陈出新。 谢谢

    3