项目中需要思考的问题，这往往决定项目的成败！ 01 - 开发流程的定义 02 - 平台与框架的选择 03 - 目录结构及源码管理 04 - 嵌入式产品的开发效率
01 - 开发流程的定义
啥是软件开发流程？
0.01 通过一系列步骤保证软件产品的顺利完成 0.02 软件产品在声明周期内的管理方法学
软件开发流程的本质
0.01 开发流程与具体技术无关 0.02 开发流程是开发团队必须遵守的规则
介绍团队成员之间合作的发展史...
A. 瀑布模型（Waterfall Model）
0.01 通过自上而下的步骤进程软件开发 0.02 每个开发步骤都是不可逆的
步骤： 需求分析 -> 架构设计 -> 开发实现 -> 系统测试 -> 最终发布
分析： 这是早期的模型，步骤都是不可逆的（瀑布），这个模型在早期是行之有效的（早期的用户需求低，功能单一），可是随着软件规模的增加，对软件功能需求的增加，于是前辈们发现，瀑布模型不好用了，因为只有需求分析阶段和用户打交道，后期每个阶段都是不需要和用户打交道的，导致最终产品和用户需求是有差异的。 于是提出新的模型 Incremental Model
B. 增量模型（Incremental Model）
0.01 将系统功能分解为互不重叠的子功能 0.02 每次全力实现一个子功能（使用Waterfall Model） 0.03 子功能全部结束后系统开发结束
步骤： 功能1： 分析 -> 设计 -> 开发 -> 测试 功能2： 分析 -> 设计 -> 开发 -> 测试 ****功能3： 分析 -> 设计 -> 开发 -> 测试
分析： 相对于Waterfall Model模型，最大的改进，用户参与度高，每个小功能都是用户满意的。但是到了后期发现一个问题：各个功能之间是关联的。 这时增量模型就出现了问题。。 于是提出新的模型 Spiral Model
C. 螺旋模型（Spiral Model）
0.01 采用一种迭代的方法来进行系统开发 0.02 软件项目分解成多个不同的版本完成 0.03 每个版本的开发过程都需要用户参与 0.04 根据前一个版本的反馈计划下一个版本
分析： 仍然是分解，但不是功能上的分解，而是版本上的分解。前期预先定义好这个项目分为几个阶段来完成，每个阶段会产生软件的中间版本，并且每个版本在开发的时候，都需要用户的参与。 事物总是发展的嘛，还有更好的开发模型。
D. 敏捷模型（Agile Modeling）
0.01 一切从简 0.02 拥抱变化 （TEAMS USERS: 开发团队深入到用户内部，和用户在一起开发这款软件，好处在于，用户需求改变，开发团队立即知道，提高开发效率，避免无用功） 0.03 高效工作 0.04 持续开发
总结： 0.01 每个模型的提出，都是为了更好的开发出符合用户需求的产品，做到这一点的方式是，提高用户在软件开发过程中的参与度. 0.02 瀑布模型只有需求分析的时候用户参与，而敏捷模型是时时刻刻和用户一起。 0.03 越靠近用户，开发出来的东西越符合需求。
02 - 平台与框架的选择
开发速度往往决定一个开发团队，一个公司的生死存亡。
开发平台 VS 开发框架
软件开发平台 0.01 开发平台是位于操作系统之上的软件层（封装操作系统上一些细节的实现，直接提供模块化的功能） 0.02 开发平台提供更多通用模块化的功能，简化（加速）软件开发平台
软件开发框架 0.01 开发框架是位于开发平台之上的软件层（相对于开发平台来说，抽象封装的力度更高） 0.02 开发框架是为特定应用所设计的更抽象的软件模型
总结： 开发平台提供的模块化的功能是比较通用的，而开发框架提供的模块化的功能比较定制了，只适合特定的应用。 并且框架是位于平台之上的。
平台与框架示例一： Spring / Java
--------------------
Web 应用程序 |
--------------------
Spring | 框架层
--------------------
Java | 平台
--------------------
OS |
--------------------Spring->这个框架针对轻量级的web程序而设计的，非常定制。（基于平台的，模块是定制的）
平台与框架示例二： Qt
-----------------------------
| 桌面应用程序 |
---------------------------------
|状态机框架 | 模型视图框架 | 框架层
| 动画框架 …… |
Qt -----------------------------
| Qt Core | 平台层
---------------------------------
| OS |
-----------------------------
Qt既是一个平台，又是一个框架。最好去看一下源码，设计非常简洁明了。
总结： 选择平台与框架的标准："可以加快项目的开发速度"
03 - 目录结构及源码管理
目录设计 VS 源码管理 (制定规则)
0.01 项目中每个文件的代码用一个文件夹进行管理 ----------文件夹由inc, src, makefile构成 0.02 项目中每个模块的对外函数声明统一放置同一目录中 ----------如：common.h xxxfunc.h
目录设计示例：
项目：Project
第一层：libs common module main -------# Project项目下的四个文件夹 第二层：libs : inc、lib ------# libs库下的文件存放的文件夹 第三层： inc: dlib.h slib.h lib: dlib.so slib.so
目录设计的意义：
0.01 书架功能 --------反映项目中代码的层次感和模块化 0.02 意识引导 --------引导对于新增文件功能，命名及位置的思考 0.03 增强维护性 --------加快开发人员对于项目整体架构的理解
04 - 嵌入式产品的开发效率
常规嵌入式开发的方式 01代码编写 -> 02代码修改 -> 03交叉编译 -> 04程序烧写 -> 05功能验证 -> 06判断通过？ -> 07结束战斗
备注：如果06不通过，那么回到02返回执行 02 - 06 之间的步骤。 每改动一个地方，就要在硬件上做功能验证。反复烧写是体力劳动，而且，拖慢了开发速度。
存在问题
0.01 开发工程师必须人手一台设备（项目早期可能无法满足） 0.02 每次代码改动必须到设别进程验证（效率低下） 0.03 反复多次烧写可能导致设备损坏（不稳定的早起设备）
调试问题
0.01 需要基于额外硬件（JTag）连接设备进行断点调试 0.02 常规日志只能写于文件中，无法实时查看 0.03 几乎无法进行现场调试（客户环境调试）
嵌入式基础设施的建设
0.01架构设计时，模块之间遵循强内聚，弱耦合原则 -----------模块能够基于PC环境编译，进行单元测试 0.02 开发PC环境中的设备模拟器 -----------产品代码能够在PC环境完整编译并运行PC环境 0.03 开发产品中可实时查看输出日志系统 -----------设备运行日志输出可以实时传输到PC环境，客户现场定位问题。