什么是工程方法？
有目的、有计划、有步骤地解决问题的方法就是工程方法。工程方法不是软件工程独有的，几乎所有工程类别都可能会应用，例如建筑工程、电子工程等，只不过步骤可能略有不同
工程方法通常会分成六个阶段：想法、概念、计划、设计、开发和发布。
- 想法：想法阶段通常是想要解决问题。最开始问题通常是模糊的，所以需要清晰地定义好问题，研究其可行性，检查是否有可行的解决方案。
- 概念：概念阶段就是用图纸、草图、模型等方式，提出一些概念性的解决方案。这些方案可能有多个，最终会确定一个解决方案。
- 计划：计划阶段是关于如何实施的计划，通常会包含人员、任务、任务持续时间、任务的依赖关系，以及完成项目所需要的预算。
- 设计：设计阶段就是要针对产品需求，将解决方案进一步细化，设计整体架构和划分功能模块，作为分工合作和开发实施的一个依据和参考。
- 开发：开发阶段就是根据设计方案，将解决方案构建实施。开发阶段通常是一个迭代的过程，这个阶段通常会有构建、测试、调试和重新设计的迭代。
- 发布：将最终结果包括文档发布。
如果你用这六个或者其中几个阶段对照日常工作和生活中遇到的问题，会发现绝大部分问题都可以看成一个项目，并且拆分成几个阶段，按照计划一步步完成。
站在整体而非局部去看问题
可能会有人说：“我不用这种工程方法去做事，一样可以做成呀，并没有什么区别。”确实，做一件事有很多种方式，但用工程方法去处理事情，有两点好处：
- 有一个被有效论证过的方法论指导你，可以帮助你提高成功概率，也可以提高效率。
- 当你用工程方法去思考的时候，你会更多的站在整体而非局部去思考，更有大局观。
我们在日常处理事务时，天然地会选择自己感兴趣的、擅长的那部分，而容易无视整体和其他部分。所以问题的核心并不在于是不是用工程方法，而是有没有把这件事当作一个项目，是不是能看到这件事的全貌，而不是只看到局部。
工程思维，本质上是一种思考问题的方式，在解决日常遇到的问题时，尝试从一个项目的角度去看待问题、尝试用工程方法去解决问题、站在一个整体而不是局部的角度去看问题。
总结
学习本章之后的收获主要有两点：
- 无论是日常生活还是工作，都应该应用工程思维，将一个事情分成几个阶段，然后指定相应的计划
- 站在整体而非局部去看待问题，更多的关注项目的质量，进度，成本等大方向，对项目有利，对自己也有利
实际场景:
以下这些工作场景，估计你不会陌生。
- 产品经理提出一些天马行空、不切实际的需求，而技术上不可行或者实现成本很高，导致最后返工，造成资源浪费和进度延迟；
- 架构师为了满足开发上的成就感，更愿意自己“造轮子”，而不愿意采用现有开源程序或者购买合适的组件；
- 开发工程师喜欢在代码中使用各种设计模式或者最新技术，导致项目进度延迟，代码难以维护；
- 测试工程师不愿意学习自动化测试技术，导致测试周期较长，且容易出现疏漏；除非产品经理特别注明，开发工程师和测试工程师不会注意用户体验上的细节。
这样的场景问题还有很多，为什么会出现这种情况呢？事实上，这在很大程度上都归因于大家只是站在自己岗位的角度来看问题，没有站在项目的整体角度来看。
如果能站在项目整体来看问题，你就会去关注项目的质量、项目的进度、项目的成本、项目的最终用户，那么上面这些场景将变成：
- 为了项目整体的效率和避免返工浪费，产品经理会及早和开发人员确认技术可行性，并对产品设计先行验证；
- 为了节约项目开发成本，提高开发效率，架构师选择成熟的架构，合理购买商业组件和使用开源程序；
- 为了提升开发效率，不影响项目开发进度，开发工程师尽可能采用成熟的技术，高效简洁地落实项目；
- 为了项目质量和效率，测试工程师学习自动化测试技术，将大部分测试变成自动化运行，极大地提高了测试效率和质量；
- 为了让用户有好的体验，不仅产品经理，每个人都会仔细体验用户界面，对于不合理的地方提出改进意见。
有人参与、有计划、有步骤地造一件产品，我们通常称为“工程”。
所有工程的本质，就是要做出有用的产品，比如造房子的建筑工程、造火箭的航天工程。像网红“手工耿”一样专搞无用发明的情况，我们是不能称为“工程”的。在软件领域，对应的就是“软件工程”，这些我们日常使用的软件背后，都是基于软件工程的方法在开发、运行和维护的。
一、什么是软件危机？
也许有人会认为，不用软件工程，我一样可以开发软件出来。这确实没有错，因为如果一个人没有学过建筑工程，他也是可以造一个房子出来，只是造出来大概会是这个样子：
我们知道，不按照建筑工程造房子，是会出事故甚至死人的。
而在软件工程的历史上，也是真的有造成过很大损失、甚至还有人为之丧命的事件存在。OS/360 操作系统是上世纪 60 年代最复杂的软件系统之一，也是第一个超大型的软件项目，一共有 1000 名左右的程序员参与了项目的研发，花费了 5000 个人年，最终无法运行。项目负责人佛瑞德·布鲁克斯后来写了一本软件工程的经典书籍《人月神话》，承认在他管理这个项目的时候，犯了很多错误，造成了价值数百万美元的损失。如果是说 OS/360 还只是造成了经济损失的话，Therac-25 事件就是真的导致了人员死亡。Therac-25 是加拿大原子能有限公司（AECL）所生产的放射线疗法机器，在 1985 年到 1987 年之间，在美国及加拿大，至少有六起和 Therac-25 相关的医疗事故是因为程序 bug，导致部分病患受到比正常剂量高一百倍的辐射，因而造成患者重伤甚至死亡。
发生这些惨痛的事，原因却并不难理解。
在计算机刚发明出来的时候，计算机的能力非常有限，只能接收简单的指令和运算，不需要软件工程也可以开发出简单的软件。但是，当软件的规模越来越大，复杂度不断增加，软件项目开发维护过程中的问题就逐步暴露出来：软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加。所以在 60 年代，“软件危机”的概念被提出来。
二、应对软件危机的办法—软件工程的概念被提出
为了解决“软件危机”，1968年北大西洋公约组织提出了“软件工程”这个概念。软件工程，它是为研究和克服软件危机而生。软件工程，就是要用工程化方法去规范软件开发，让项目可以按时完成、成本可控、质量有保证。
三、软件工程的演化史
对比传统的工程学科，和软件工程最接近的就是建筑工程了。设想一下建一座房子：首先要先立项、设定预算，然后画设计图，再是施工，施工完成后，由专业人士进行质量检查，质检合格后入住。开发软件本质上也是像盖房子一样，是从无到有创造的过程。工程化的方式，就是你分步骤（过程），采用科学的方法，借助工具来做产品。于是参考建筑工程，整个软件开发过程也被分成了几个阶段：需求定义与分析、设计、实现、测试、交付和维护，这也就是我们常说的软件项目生命周期。
当然，各个阶段都会有人的参与，于是产生了软件项目里的各种角色：项目经理、产品经理、架构师、程序员、测试工程师、运维工程师。
而对这整个过程的管理，我们通常称之为“项目管理”。同时，也很自然就衍生出一套最基础的过程模型：瀑布模型。
瀑布模型：
瀑布模型的详解：
用瀑布模型做项目就像古代匠雕刻玉石，先有完整的设计图，然后按部就班往前推进，中间不能出一点差错，追求的是“一次成型”。
这就是瀑布模型，最基本也最常用的一种项目管理模型，又称线性模型。
采用瀑布模型的项目依照该模型选定的阶段顺序进行，每一个阶段的工作产品都是下一个阶段工作的输入，每一个阶段只有在上一个阶段通过检查，确认完成后才开始新的阶段工作。
▲ 瀑布模型的思想示意图
瀑布模型的突出特征是文档驱动。从需求分析到系统维护，每一项活动的工作成果就是此项活动所产生的工作文档，以及在此基础上形成的产品。
瀑布模型最大的优点有两个：
1、每个阶段的开发质量都有保证，减少了返工。2、是文档细致，降低了沟通成本，有利于及早发现问题。
这就是开头说的雕刻玉石的步骤，有精细的设计图纸，每一步都不可行差踏错，因为一旦雕坏了，就得摔了玉重来。
这也正是瀑布模型的缺点：周期长，不易变更。
用户直到项目开发晚期才能了解产品的真实面貌和质量。这时候提出变更，成本会非常大。
适合采用瀑布模型的项目类型，通常是对用户需求非常明确的项目。同时还要求项目预算充足，人员齐备。
链接：https://zhuanlan.zhihu.com/p/116754890
瀑布模型的作用：
瀑布模型的诞生，在当时是有非常重大的意义的，让软件开发从无序到有序，让大家更好的分工协作，同时每个阶段又衍生出各自的方法学和工具，例如需求分析、软件测试等等。
瀑布模型的缺陷：
然而瀑布的特性决定了它只能从上往下流，而且从上到下走完整个周期很长，所以一旦出现了需求的变更，将会非常痛苦，很多事情需要重头再来。
瀑布模型的衍生：
于是基于瀑布模型，又衍生出 V 模型、原型设计、增量模型、螺旋模型等模型，试图改善瀑布模型存在的一些缺陷。这些改进模型的发展趋势上就是缩短项目周期，快速迭代。
敏捷联盟的出现：
这样到了 90 年代，各种轻量级开发方法例如 Scrum、极限编程等也不断被提出。到了 2001 年，这些轻量级开发方法一起组成了敏捷联盟，其后敏捷开发如同星星之火，逐渐形成燎原之势。
近些年，云计算、微服务这些新技术的产生，也对软件工程产生了影响。云服务让分工更细，很多企业可以将运维、服务器维护、DBA、甚至某些独立服务交给云服务商；微服务让大团队变成小团队，每个小团队可以更专注于细分领域，减少相互之间的依赖。
一个公式
当你大致了解整个软件工程的演变发展史，你会发现，软件工程的知识，都是建立在软件项目的过程，或者说软件项目生命周期之上的。基于软件过程，我们有了角色分工，有了对过程的管理和工具，对过程中每个阶段细分的方法学和工具。
现在，如果再回头看看我们的问题“什么是软件工程？”其实可以总结为：软件工程就是用工程化的方法来开发维护软件。
也可以说软件工程就是用一定的过程，采用科学的方法，借助工具来开发软件。如果用一个简单的公式表达，那就是：软件工程 = 过程 + 方法 + 工具。
软件工程知识架构全景图（三要素）
首先你要明确，当我们谈软件工程学时，究竟在讲些什么呢？
在《软件工程——实践者的研究方法》这本经典软件工程教材中，作者 Roger S.Pressman 画了一张图，高度概括了整个软件工程的核心知识。
由图可见，“质量焦点”在最底层，这不难理解软件工程是为了应对软件危机诞生的学科，其目标就是为了要聚焦于质量，构建和维护高质量的软件。可以说，聚焦于质量就是软件工程的基石。
那“过程”指的是什么呢？
要构建高质量软件，则要解决软件过程中的混乱，将软件开发过程中的沟通、计划、建模、构建和部署等活动有效地组织起来。而软件过程，就是在软件项目的生命周期内，也就是软件从诞生到结束这期间，在开发与构建系统时要遵循的步骤。有两种过程框架你一定经常听到，那就是瀑布模型和敏捷开发。这是在软件工程多年的发展中，逐步形成的两种主流的软件过程指导框架。
那么，何为“方法”？
方法是指在整个过程中，如何构建系统的方法学。比如说，如何分析用户需求；如何对产品进行测试验收；如何进行系统架构设计等。
知道了过程，掌握了方法，那么具体落到操作层面，就会涉及到工具的使用。
我们需要工具来辅助方法的执行，提高效率。通过工具，可以把一些手动的工作自动化，比如自动化测试工具，自动构建部署工具；通过工具，可以帮助把一些流程规范起来，比如 Bug 跟踪、源代码管理；还可以通过工具，帮助提高编码效率，比如各种编辑器 IDE、各种高级语言。
如果现在再回头总结一下，软件工程的核心知识点，就是围绕软件开发过程，产生的方法学和工具。
你可以用一个简单的公式来理解软件工程，那就是：软件工程 = 工具 + 方法 + 过程。
根据这个公式，我将软件工程的知识结构做成了思维导图，方便你对知识点有更好地理解，高效学习。
如何学习软件工程？
我给了你软件工程学的公式，也对软件工程有了更为全面的了解，看起来软件工程学很简单，但这些内容一下子要吃透也不容易。在开篇词中，我介绍了会从“道、术和器”三个维度去讲这个专栏，这其实对应了学习软件工程的四重境界。
学习软件工程的四重境界
第一重：用器
“器”就是工具，工具规则简单，上手就可以用，也很快就能看到效果。比如，原型设计工具可以帮助你确定需求，持续集成工具可以帮助你简化测试和部署的流程。对工具的学习是最为简单的，也是最基础的。
第二重：学术
“术”就是方法，学会方法，你就能应用方法去完成一个任务，例如用需求分析的方法，你去搞清楚用户想要什么，用 Scrum 去组织项目开发过程。掌握了术，甚至是可以脱离器的，例如你没用原型设计工具，你用纸和笔，用白板，一样可以去沟通确认需求。
第三重：悟道
“道”就是本源，软件工程知识的核心思想和本质规律。就像敏捷开发，本身并不是一种方法，而是一套价值观和原则，领悟了这个道，就可以成为你在处理项目过程中各种问题决策的依据。道是可以产生术的，你掌握了敏捷开发的道，你就可以领悟出 Scrum、极限编程这样的术。
第四重： 传道当你能把复杂的知识通过浅显易懂的方式传授给别人，那就说明你对知识的领悟已经到了更高的境界。同时，教学也是最好的学习方式，通过传授别人知识，可以让你对知识本身有更深入的理解。
做中学和教中学
你可能会问，怎样学，才能到达以上这四重境界？我在做技术管理的工作中，经常要做一些培训的工作，在这过程中我总结了两套行之有效的方法：“做中学”和“教中学”。
“做中学”，是一种自下而上的学习方法，通过实践，从使用工具到学习方法，再从方法中提炼出道。
在学习本专栏的时候，你可以采用“做中学”的方式，把专栏中的知识应用起来，在实践的过程中去巩固你学到的知识，去思考背后的道。把已经积累的项目经验和软件工程的知识点关联起来，这样才能加深你的理解，学以致用，把经验和知识转化为能力。
“教中学”，是一种自上而下的学习方法，通过教学，去进一步深入领会别人总结出来的道，去模仿推导方法，去学习如何使用工具。比如，你学习完一篇专栏文章后，把学到的知识进行输出，写成微博或博客分享出去；在公司内部讲给你的同事们听等。在教学分享的过程中，去进一步深化吸收知识内容，构建你的知识体系。
“做中学”和“教中学”，这两种方法你可以配合起来使用。
总结
软件工程知识架构为：以工具，方法，过程三要素，力求构建出高质量的软件。
三要素的关系可以概括为：软件过程，就是在软件项目的生命周期内，也就是软件从诞生到结束这期间，在开发与构建系统时要遵循的步骤，有了步骤就要有方法去实现，方法是指在整个过程中，如何构建系统的方法学，而工具就是为了提高方法的实现效率的工具。
学习软件工程的四部曲：
- 掌握工具的使用（比如使用栈类，队列类）
- 脱离工具也可以达到目的（比如不用现成的，自己实现一个栈，队列）
- 思考软件开发过程的本源（比如创建一个新的数据结构）
- 传授给别人。
也就是说 先设计出过程—>再得出实现过程的方法—>构建工具实现方法
引言
按理论上来说，我已经系统的 学习过软件工程这门课了。
但实际上，我一点也不理解 软件工程 这个标题的含义，甚至无法准确的描述软件，或者是工程的含义；我相信很多的同学跟我一样，仍然犯迷糊，因此我试图通过分享学习宝玉前辈的《软件工程之美》的一点心得，来帮助所有看到本篇文章的朋友。（或者是自己学习用，因为我只是个小菜鸡）
一、没有学习软件工程而出现的问题
花费较多的时间去学习各种技术栈，我称之为 下沉；
在下沉的过程中，我们不断点亮新的技能点，这是一个很愉快的过程，但同时也是很危险的，正如潜水员不断下潜，也在离海平面越来越远，离海平面越远，就越容易失去对方向和计划的把握。
学习是为工作而服务，点亮新的技能点也是为了解决所接手的开发任务，那为什么，我们在工作的时候，会产生 明明我很努力，很认真，很有激情的，花200%的心血去完成开发任务，却收效甚微，或者频频出错，从而导致自己加班加点，信心受挫，给公司造成损失 的情况？
我们在实际工作中，常常遇到很多问题，比如：
- 开发时没有分析没有设计，上手就写，后期难维护，加班熬夜去填“坑”；（开发前不分析思考）
- 缺少理论指导，遇到新项目不能举一反三，工作很平庸；（开发时不能融会贯通）
- 遇到需求变更这种事，除了抱怨两句客户，只能闷头做，无力反抗；（无法良好的应对需求变更）
- 做项目没计划性，想到哪做到哪，总是延期，比其他同事做的慢；（无计划，无组织，无效率）
- 不知道如何与团队协作，职业发展遇到瓶颈，无法得到晋升。（职业生涯上升遭遇阻塞）
那么，科班出身的程序员是否与我有同样问题？像微软、阿里等这些大厂的程序员，他们又是怎样协调完成好那么庞大的项目？我这个“野路子”程序员面临的问题，他们又是怎么分工协作解决的？
软件工程可以解开这些困惑。
二、软件工程
软件工程：软件项目的开发其实是一个工程，整个开发过程是可以有效组织起来的；对于开发过程的各个阶段，已经有很多解决问题的最佳实践，有很多方法来帮助我们高效完成任务；我们还可以借助工具来协助管理，提升开发效率。
于我而言，学习软件工程，使我区分出了 术 与 道 的概念。
- 术：各种技术栈；
- 道：站在工程，项目的角度去思考问题的出现，解决，本源。
软件工程将应用于软件开发的整个历史。（即以前，现在，未来都需要软件工程）。
你会发现，无论你是什么岗位，只要你从事软件开发相关领域，都绕不开“软件工程”，因为现代软件项目开发，多多少少都离不开软件工程知识的应用。想象下在日常工作中，不管你用什么开发语言，不管是前端和后端：
- 你接到一个开发任务，如果想开发出客户想要的功能，你是不是先要做需求分析；
- 你接手一个复杂的、大的功能模块，是不是先要做设计，才能把复杂的拆成简单的，才能让大家一起分工去开发；
- 你完成一个功能模块，如果要保证质量，是不是需要写一些测试代码，还要做一些功能测试；
- 还有日常用的那些工具，像源代码管理、Bug 跟踪。
而这些内容，都是软件工程相关的知识，和你用什么语言无关。
换言之，这就是经典的价值，为什么说我们要学经典，因为经典就是这个行业最为本质的东西。你顺着这个逻辑想，就知道为什么大学的计算机专业要设计数据结构、算法、操作系统、软件工程这样的课程了。
技术更新迭代速度确实很快，难以把握，更难以预测，但是软件开发背后的逻辑却万变不离其宗。你只有掌握了这些逻辑，才能步步为营，不被快速发展的软件开发行业所淘汰。因为你脑袋里装有软件开发的战略，相对于赤手空拳、盲打莽撞的人来说，你更能在未来获得先机。