软件工程之美¶
在《软件工程 —— 实践者的研究方法》这本经典软件工程教材中，作者 Roger S.Pressman 画了一张图，高度概括了整个软件工程的核心知识。¶
“质量焦点” 在最底层，这不难理解软件工程是为了应对软件危机诞生的学科，其目标就是为了要聚焦于质量，构建和维护高质量的软件。可以说，聚焦于质量就是软件工程的基石。
“过程”：要构建高质量软件，则要解决软件过程中的混乱，将软件开发过程中的沟通、计划、建模、构建和部署等活动有效地组织起来。而软件过程，就是在软件项目的生命周期内，也就是软件从诞生到结束这期间，在开发与构建系统时要遵循的步骤。（瀑布模型和敏捷开发——两种主流的软件过程指导框架）
方法是指在整个过程中，如何构建系统的方法学。比如说，如何分析用户需求；如何对产品进行测试验收；如何进行系统架构设计等。
工具用来辅助方法的执行，提高效率。通过工具，可以把一些手动的工作自动化，比如自动化测试工具，自动构建部署工具；通过工具，可以帮助把一些流程规范起来，比如 Bug 跟踪、源代码管理；还可以通过工具，帮助提高编码效率，比如各种编辑器 IDE、各种高级语言。
备注
软件工程的核心知识点，就是围绕软件开发过程，产生的方法学和工具。软件工程 = 工具 + 方法 + 过程。
软件工程的知识结构¶
基础理论 (9 讲)¶
01 | 到底应该怎样理解软件工程¶
瀑布模型：最基础的过程模型¶
02 | 工程思维: 把每件事都当作一个项目来推进¶
03 | 瀑布模型: 像工厂流水线一样把软件开发分层化¶
瀑布模型把整个项目过程分成了六个主要阶段¶
04 | 瀑布模型之外还有哪些开发模型¶
增量模型¶
备注
按模块分批次交付
增量模型将整个系统进行模块化处理，所以你可以分批次交付软件产品，使用户及时了解软件项目进展¶
迭代模型¶
备注
每次迭代都有一个可用的版本
在一个迭代中都会包括需求分析、设计、实现和测试，类似于一个小瀑布模型。迭代结束时要完成一个可以运行的交付版本。¶
05 | 敏捷开发到底是想解决什么问题¶
敏捷宣言¶
06-07 | 大厂都在用哪些敏捷方法¶
所谓的看板，就是把白板分成几个栏，每一栏为一类，分别写着“To Do（待选取）”、“In Progress（进行中）”、“Done（完成）”等，再把工作任务变成一个个五颜六色的即时贴，根据状态贴在不同的栏下面。慢慢的物理的看板变成了电子看板，通过各种项目管理软件来管理跟踪这些任务，即时贴也变成了 Ticket（也有叫 Issue 的）¶
备注
Ticket 和敏捷开发中的 Backlog（任务清单）正好结合起来，通过 Ticket 可以收集管理整个项目的 Backlog 和当前 Sprint（迭代）的 Backlog。
08 | 怎样平衡软件质量与时间成本范围的关系¶
做产品想“多、快、好、省”都占着，是不可能的，最多只能选两样。想要便宜和质量好，就要花时间等；想要快还要质量好，那就得多花钱；想要又便宜又快，那就得接受难用、质量差。¶
著名的项目管理金三角（以下简称“金三角”）：在软件项目中，也有一个类似的平衡关系，就是软件质量（产品的质量，客户的满意度）与范围（需要实现多少功能）、时间（多久可以完成）、成本（花多少钱）四个要素之间的平衡。¶
瀑布模型的范围是固定的，其他两条边时间和成本是变量；在敏捷开发中，时间和成本两条边是固定，就只有范围这条边是变量。¶
① 到 ⑦ 的需求组合会导致什么样的软件， 会出现什么样的问题——邹欣老师《构建之法》¶
09 | 为什么软件工程项目普遍不重视可行性分析¶
对于软件项目的可行性研究，主要从以下几个方面入手:
1. 经济可行性
2. 技术可行性
3. 社会可行性
10 | 如果你想技术转管理, 先来试试管好一个项目¶
11 | 项目计划: 代码未动,计划先行¶
这个计划其实不是第一版，可能也不是最后一版，因为制定计划本身是一个反复迭代的过程，尤其是一开始在需求并不够明确的时候，只能比较粗粒度的分解任务和估算，在项目推进的过程中再逐步细化和完善。¶
“留言飞语”项目按照 WBS 拆分的结果¶
12 | 流程和规范: 红绿灯不是约束,而是用来提高效率¶
13 | 白天开会, 加班写代码的节奏怎么破¶
14 | 项目管理工具: 一切管理问题,都应思考能否通过工具解决¶
阿波罗登月项目巨型计划图¶
MS Project官网¶
15 | 风险管理: 不能盲目乐观,凡事都应该有 B 计划¶
针对风险，主要分成这几个策略。¶
项目风险管理过程¶
16 | 怎样才能写好项目文档¶
需求分析篇¶
17 _ 需求分析到底要分析什么/怎么分析¶
18 _ 原型设计: 如何用最小的代价完成产品特性¶
参考工程方法，我们可以将每次原型设计过程分成四个部分：分析、设计、实施和验证。¶
19 | 作为程序员, 你应该有产品意识¶
20 | 如何应对让人头疼的需求变更问题¶
“一问一答”第2期 _ 30个软件开发常见问题解决策略¶
扑克牌估算工作量方法: http://www.scrumcn.com/agile/scrum/4523.html
系统设计篇¶
21 _ 架构设计: 普通程序员也能实现复杂系统¶
22 | 如何为项目做好技术选型¶
23 _ 架构师: 不想当架构师的程序员不是好程序员¶
要成为好的架构师，有架构师思维、懂业务需求、有丰富的编码经验、良好的沟通能力¶
24 _ 技术债务: 是继续修修补补凑合着用,还是推翻重来¶
《重构》一书的作者 Martin Fowler 把技术债务产生的原因分成了两个维度：1. 轻率（reckless）还是谨慎（prudent）；2. 有意（deliberate）还是无意（inadvertent）。¶
Martin Fowler 画过一张图，来形象的描述了设计、时间和开发速度的关系。¶
开发编码篇 (7 讲)¶
25 | 有哪些方法可以提高开发效率¶
26 | 持续交付: 如何做到随时发布新版本到生产环境¶
27,28 | 软件工程师的核心竞争力是什么¶
29 | 自动化测试：如何把 Bug 杀死在摇篮里¶
Google 针对这几种测试类型列了一张表，根据数据给出了明确区分¶
测试金字塔，图片来源： TestPyramid¶
图片来源：Microservice Testing: Unit Tests¶